What digital transformation means here

Digital transformation is using technology (especially cloud, data and AI) to change how an organisation operates and delivers value to customers - not just 'moving servers to the cloud'. Google Cloud frames it around three drivers: innovation speed, operational efficiency, and delivering better customer experiences.

Google Cloud's three transformation themes

• Smart analytics - turning raw data into decisions using tools like BigQuery, Looker and Vertex AI.
• Open infrastructure - avoiding vendor lock-in via open source (Kubernetes, Anthos) and hybrid/multi-cloud support.
• Collaboration and productivity - Google Workspace enabling real-time collaboration from anywhere.

Why organisations move to the cloud

• Reduce capital expenditure (CapEx) by shifting to operational expenditure (OpEx) - pay only for what you use.
• Scale resources up or down on demand rather than over-provisioning hardware.
• Improve business agility - launch new products faster.
• Increase reliability and security via a hyperscale provider's global infrastructure.
• Free up staff from managing physical data centres to focus on higher-value work.

The shared fate model

Google Cloud talks about 'shared fate', not just the older 'shared responsibility' model. Shared responsibility splits duties (Google secures the infrastructure, customer secures their data/access). Shared fate goes further - Google actively helps customers adopt best practices, secure landing zones and insurance-backed risk protection, rather than leaving customers alone once the split is defined.

Common transformation approaches

• Lift and shift (rehosting) - move workloads as-is to the cloud, fastest but least optimised.
• Improve and move (replatforming) - some optimisation during migration.
• Move and improve / rebuild (refactoring or rearchitecting) - redesign for cloud-native benefits like containers and serverless.
• Replace - swap for a SaaS solution entirely.

Common exam mistakes

• Confusing 'digital transformation' with simple 'infrastructure migration' - transformation is about business outcomes, not just tech relocation.
• Thinking CapEx is preferred in cloud economics - the exam wants you to know cloud favours OpEx (pay-as-you-go).
• Forgetting that shared fate includes Google proactively assisting customers, unlike pure shared responsibility.
• Mixing up the four migration strategies (rehost, replatform, refactor, replace) and their trade-offs between speed and optimisation.

Key takeaway

Digital transformation with Google Cloud is about combining data, open infrastructure and collaboration tools to change business outcomes, underpinned by a partnership (shared fate) approach to security and reliability rather than customers going it alone.

Why modernise infrastructure?

Many organisations start with on-premises data centres they own and run themselves.

This means buying servers, paying for power and cooling, and hiring staff to maintain everything.

Cloud modernisation moves some or all of this workload to Google Cloud, trading capital expense (CapEx) for operational expense (OpEx).

The exam expects you to know the migration paths and where each application type fits.

The main migration strategies

• Lift and shift (rehost): move a VM as-is into Compute Engine with minimal changes. Fastest route, least benefit gained.
• Improve and move (replatform): make small optimisations during the move, such as switching to a managed database.
• Move and improve (refactor): re-architect the app to use cloud-native services, for example containerising it for Google Kubernetes Engine (GKE).
• Rip and replace (rebuild): drop the old app and build a new cloud-native one, often serverless.
• Remove (retire): decommission apps nobody uses any more, a quick win most companies skip.

Matching workloads to compute options

• Compute Engine: full control of virtual machines, best for lift-and-shift and legacy workloads.
• Google Kubernetes Engine (GKE): managed Kubernetes for containerised, portable, microservices-based apps.
• Cloud Run: fully managed serverless containers, scales to zero, ideal for stateless HTTP workloads and modern app development.
• App Engine: fully managed platform-as-a-service (PaaS) for deploying code with no infrastructure management, standard (sandboxed) or flexible (custom containers) environments.
• Cloud Functions: event-driven, single-purpose functions, the smallest unit of serverless compute (Functions-as-a-Service).

Migration tools to know

• Migrate to Virtual Machines (formerly Migrate for Compute Engine): migrates on-prem or other-cloud VMs into Compute Engine.
• Database Migration Service (DMS): migrates MySQL, PostgreSQL and SQL Server into Cloud SQL with minimal downtime.
• Transfer Appliance and Storage Transfer Service: move large volumes of data into Cloud Storage, physically or over the network.
• BigQuery Data Transfer Service: automates moving data into BigQuery from SaaS apps and other warehouses.

Application modernisation concepts

• Containers package an app with its dependencies so it runs consistently anywhere; this is the core enabler of app modernisation.
• Microservices break a monolithic app into small, independently deployable services, improving scalability and release speed.
• APIs (managed via Apigee) let modernised services talk to legacy systems during a phased migration.
• Anthos extends Google Cloud management to on-premises and multi-cloud environments, supporting hybrid strategies.

Common mistakes

• Confusing rehost (lift and shift) with refactor (move and improve) — rehost changes nothing about the app itself.
• Assuming all legacy apps must be rebuilt; retiring unused apps is a valid and often overlooked strategy.
• Forgetting Cloud Run scales to zero and charges only when handling requests, unlike Compute Engine.
• Mixing up App Engine (PaaS, deploy code) with GKE (you manage containers and orchestration yourself).

Data and machine learning on Google Cloud

This topic covers how Google Cloud stores, processes and learns from data. The Digital Leader exam wants you to match a business need to the right managed service, not to write code.

The data lifecycle

• Ingest: Pub/Sub for real-time streaming messages, Storage Transfer Service and Transfer Appliance for bulk moves.
• Store: pick a database by shape and access pattern, not habit.
• Process/analyse: Dataflow (stream and batch), Dataproc (managed Hadoop/Spark), BigQuery.
• Visualise: Looker and Looker Studio turn query results into dashboards.
• Activate with AI: Vertex AI and pre-trained APIs.

Choosing a database - the exam loves this

• Cloud SQL: regional relational database, MySQL, PostgreSQL or SQL Server; good for smaller transactional apps.
• Spanner: globally distributed relational database with strong consistency and near-unlimited scale; use when you need SQL AND horizontal scale across regions.
• Firestore: NoSQL document database for mobile and web apps needing real-time sync.
• Bigtable: NoSQL wide-column database for huge volumes of fast-changing analytical or IoT/time-series data, low millisecond latency.
• BigQuery: serverless data warehouse for petabyte-scale SQL analytics, not for transactional apps.
• Memorystore: managed in-memory store (Redis/Memcached) for caching.

BigQuery essentials

• Fully serverless: no infrastructure to manage, storage and compute scale and bill separately.
• Pricing has two models: on-demand (pay per byte scanned per query) or capacity-based (flat-rate slots).
• BigQuery ML lets you build and run ML models using plain SQL, no need to move data out.
• BI Engine speeds up dashboard queries with in-memory analysis.

Machine learning options - match the skill level

• Pre-trained APIs (Vision AI, Natural Language AI, Speech-to-Text, Translation AI): zero ML knowledge needed, call an API for common tasks.
• Vertex AI: Google's unified ML platform covering the whole pipeline - AutoML (train custom models with minimal code) through to custom training with your own code and frameworks (TensorFlow, PyTorch).
• Generative AI on Vertex AI (via Model Garden) gives access to foundation models such as Gemini for text, chat, image and code generation.
• The AI/ML spectrum runs: pre-trained API to AutoML to custom training - increasing control but increasing effort and skill required.

Common mistakes to avoid

• Do not confuse Bigtable (NoSQL, operational, huge scale) with BigQuery (SQL, analytical, data warehouse) - similar names, very different jobs.
• Do not pick Cloud SQL when the requirement says 'global scale with strong consistency' - that is Spanner.
• Remember Dataflow and Dataproc are BOTH data processing tools: Dataflow is serverless and built on Apache Beam; Dataproc is for teams already using Hadoop/Spark and wanting a managed cluster.
• AutoML is for people with limited ML expertise wanting a custom model; it is not the same as using a pre-trained API.

Google Cloud's shared responsibility model

Security is split between Google and the customer.

Google secures the physical infrastructure, network, and hypervisor - this is called security 'of' the cloud.

You secure your data, identity and access management (IAM) settings, and how you configure your workloads - this is security 'in' the cloud.

The split shifts depending on the service model: for Compute Engine (IaaS) you manage more, for App Engine (PaaS) less, and for fully managed services like BigQuery even less.

A common exam trap is assuming Google handles everything - it never does.

Identity and Access Management (IAM)

IAM controls who (identity) can do what (role) on which resource.

The golden rule is least privilege - give the minimum permissions needed, nothing more.

Roles come in three types: basic (Owner, Editor, Viewer - broad, avoid in production), predefined (granular, service-specific), and custom (built by you).

Policies can be applied at organisation, folder, project, or resource level, and permissions inherit downward.

Resource Manager hierarchy

Resources sit in a hierarchy: Organisation > Folders > Projects > Resources.

This lets policies (IAM, budgets) cascade down automatically, which keeps large enterprises consistent without manual repetition.

Key security tools to know

• Cloud Identity - manages users and groups, the foundation for IAM.
• Security Command Center - a centralised dashboard for threat and vulnerability detection across your Google Cloud assets.
• Cloud IAM - access control, covered above.
• VPC Service Controls - creates a security perimeter around resources to prevent data exfiltration.
• Cloud Key Management Service (KMS) - lets you manage and rotate your own encryption keys.
• Data Loss Prevention (DLP) API - discovers, classifies, and redacts sensitive data like credit card numbers.

Encryption

Google Cloud encrypts data at rest and in transit by default - you don't have to switch this on.

For extra control, use Customer-Managed Encryption Keys (CMEK) via Cloud KMS, or Customer-Supplied Encryption Keys (CSEK) if you want to hold the keys yourself.

Operations - monitoring and logging

Google Cloud's operations suite (formerly Stackdriver) is the umbrella for observability.

• Cloud Monitoring - collects metrics, sets alerts, and builds dashboards.
• Cloud Logging - collects, stores, and analyses logs from all services.
• Cloud Trace - tracks latency across distributed services.
• Cloud Profiler - analyses CPU and memory usage of running code.
• Error Reporting - aggregates and surfaces application errors automatically.

Common mistakes

Don't confuse Security Command Center (a dashboard/detector) with IAM (the access control system) - they work together but do different jobs.

Don't assume basic roles are fine for production - predefined or custom roles are best practice.

Remember encryption at rest and in transit is automatic and does not need to be manually enabled.

Google Cloud products overview

Google Cloud Platform (GCP) organises its services into families: compute, storage, databases, networking, big data/analytics, AI/ML, and operations. For the Digital Leader exam you need to know what each product does and when to pick it, not deep configuration detail.

Compute options

• Compute Engine: infrastructure-as-a-service (IaaS) virtual machines. Full control over OS and configuration, most management overhead.
• Google Kubernetes Engine (GKE): managed container orchestration for Docker-style workloads at scale.
• App Engine: platform-as-a-service (PaaS) for deploying code without managing servers; two environments (standard and flexible).
• Cloud Run: fully managed serverless platform for stateless containers; scales to zero, pay only when handling requests.
• Cloud Functions: serverless, event-driven functions-as-a-service (FaaS) for small pieces of code triggered by events.
• The general rule: Compute Engine gives most control/most management; Cloud Functions gives least control/least management. Digital Leader loves this control-vs-management trade-off question.

Storage and databases

• Cloud Storage: object storage for unstructured data (images, backups, video); four storage classes — Standard, Nearline (access <1x/month), Coldline (access <1x/quarter), Archive (access <1x/year) — priced by access frequency, not just capacity.
• Cloud SQL: managed relational database (MySQL, PostgreSQL, SQL Server) for regional, transactional workloads.
• Cloud Spanner: globally distributed, horizontally scalable relational database with strong consistency — for mission-critical global apps.
• Firestore: NoSQL document database for mobile/web apps needing real-time sync.
• Bigtable: NoSQL wide-column database for huge analytical/time-series workloads (petabyte scale, low latency).
• BigQuery: serverless, highly scalable data warehouse for analytics using SQL — separates storage and compute, so you pay for queries run (or flat-rate slots).

AI/ML and common mistakes

• Vertex AI: unified platform to build, train, and deploy custom ML models.
• Pre-trained APIs (Vision AI, Natural Language AI, Speech-to-Text, Translation AI) need no ML expertise — use these when the exam scenario says 'no data scientists on staff'.
• Common mistake: confusing BigQuery (analytics warehouse) with Cloud Storage (raw object storage) — BigQuery is not for storing images or backups.
• Common mistake: picking Compute Engine when the scenario says 'minimise operational overhead' — that phrase signals serverless (Cloud Run/Functions/App Engine), not VMs.
• Common mistake: forgetting Spanner combines relational structure AND horizontal scale — most people assume relational databases can't scale globally.

Quick decision cues

• 'Lift and shift' → Compute Engine.
• 'Containers, need orchestration control' → GKE.
• 'Just deploy code, don't think about infrastructure' → Cloud Run or App Engine.
• 'Run code only when triggered by an event' → Cloud Functions.
• 'Analyse huge datasets with SQL' → BigQuery.
• 'Global relational database with consistency' → Cloud Spanner.

Why cost management matters

Google Cloud bills for what you consume, so understanding pricing models and billing tools is core exam territory. The Digital Leader exam tests whether you know WHICH tool solves WHICH cost problem, not deep technical detail.

Pricing models

• On-demand (pay-as-you-go) pricing is the default for most services.
• Sustained use discounts apply automatically to Compute Engine VMs run for a significant portion of the month - no action needed.
• Committed use discounts (CUDs) give up to 57% off (up to ~70% for some memory-optimised types) in exchange for a 1-year or 3-year commitment to a level of usage.
• Spot VMs (formerly preemptible VMs) offer steep discounts (up to 91% off) for workloads that tolerate interruption - not for critical, always-on jobs.
• Free Tier includes an Always Free tier (limited resources, never expires) plus a one-time free trial credit for new customers.

Billing structure

• A Cloud Billing account links payment details to one or more Google Cloud projects; every project must be linked to exactly one billing account to use paid services.
• Billing accounts can be self-serve (credit card, invoiced monthly to the card) or invoiced (for larger customers, via purchase order).
• Billing roles are separate from project roles - a Billing Account Administrator manages payments without needing access to project resources, supporting least-privilege.

Tools for tracking and controlling spend

• Budgets and alerts (Cloud Billing) send notifications when spend hits set thresholds (for example 50%, 90%, 100%) of a defined budget amount - they warn but do not automatically stop spending.
• Billing export sends detailed billing data to BigQuery (or Cloud Storage) for custom analysis, dashboards and chargeback reporting.
• The Pricing Calculator estimates costs before deploying resources.
• Cloud Billing reports give visual breakdowns of spend by project, service, SKU or label.
• Labels (key-value pairs on resources) let you filter and group costs, for example by team, environment or cost centre.

Support levels

Google Cloud offers four paid support tiers, ascending: Basic (free, included by default), Standard, Enhanced (formerly Gold/Silver equivalent), and Premium. Higher tiers add faster response times, technical account management and 24/7 coverage for critical issues. Support tier is chosen per billing account.

Common mistakes to avoid

• Confusing sustained use discounts (automatic) with committed use discounts (require a signed commitment).
• Thinking budget alerts stop spending automatically - they only notify; you must act, or configure separate automated actions.
• Forgetting that Spot VMs can be terminated by Google at any time with short notice, so they suit fault-tolerant batch work only.
• Assuming Basic support includes technical guidance - it covers billing and account issues only, not architecture or troubleshooting help.