Compute Options
The compute spectrum: trading control for management
Default toward the most managed option a workload allows, and step back toward control only when a constraint forces it: that one rule places almost any workload on Google Cloud's compute spectrum and answers the question the Cloud Digital Leader exam actually asks, which compute option to choose and why, never how to operate it. Picturing a server as the thing being handed off layer by layer is all the background the mental model below needs.
Google Cloud's compute products line up on a single axis: how much of the stack you manage versus how much Google manages for you. The hosting options guide[1] orders them "by degree of abstraction." Read left to right, you hand off more operational work (patching, scaling, capacity planning) and give up more low-level control:
- Compute Engine: virtual machines (VMs). A VM is a software computer you run your own operating system and software on. This is Infrastructure as a Service (IaaS): Google runs the hardware, you run everything above it, with operating-system-level control[1].
- Google Kubernetes Engine (GKE): runs and orchestrates containers. It sits in the middle ground: more managed than VMs, more controllable than serverless.
- Cloud Run: a fully managed serverless platform for containers. Serverless means Google provisions, scales, and patches the compute; you supply a container or code.
- Cloud Run functions (formerly Cloud Functions): serverless functions, the most abstracted rung: you supply a snippet of code and nothing else.
The practical rule that falls out of this ordering: default toward the most managed option a workload allows, and step back toward control only when a constraint forces it. Start at Cloud Run; move to GKE when you need container orchestration or portability; drop to a Compute Engine VM when the workload needs OS-level control or can't be re-architected. Reaching for a VM out of habit means your team runs servers Google would otherwise run for free.
Two terms recur across all four rungs and are defined once here. A container packages an application together with its libraries and dependencies so it runs identically anywhere (laptop, data center, or any cloud) which is what makes container-based apps portable. Microservices is an architecture that splits one large app into small, independently deployable services; containers are the usual unit you ship each microservice in.
What each product is and when it wins
This section walks each rung of the spectrum in turn, giving the definition and the use case the exam ties to it.
Compute Engine: virtual machines
Compute Engine provides VMs with operating-system-level control[1] and custom machine types. It does not scale to zero: a VM you start keeps running (and billing) until you stop it. It is the right choice for monolithic or legacy workloads, anything needing a specific OS or low-level tuning, and packaged software like relational databases or legacy ERP systems. It is also the natural home for a rehosted (lift-and-shift) app, because a VM most closely resembles the on-premises server the app already ran on.
Spot VMs are Compute Engine instances sold from Google's spare capacity at a steep discount (up to about 90% off[2] the standard on-demand price) with the catch that Google can reclaim them at any time after a brief, best-effort shutdown notice. They suit fault-tolerant, interruption-tolerant work such as batch processing, where a reclaimed instance just reruns; they are wrong for anything that must stay up. Spot VMs are the current generation of the older preemptible VMs[2].
GKE: managed Kubernetes for containers
Google Kubernetes Engine is a managed implementation of Kubernetes[3], the open-source container-orchestration system Google originally created. Orchestration means scheduling containers onto machines, restarting failed ones, and scaling them. GKE runs in two modes: in Autopilot mode (the recommended default) Google also manages your worker nodes[3] and you pay only for the resources your running workloads request; in Standard mode you manage the node pools yourself for cases that need that control. GKE wins when you run many containers that need orchestration, want microservices at scale, or need the same Kubernetes platform across multiple environments for portability.
Cloud Run: serverless containers
Cloud Run is a fully managed platform for running a container[4] without managing clusters or infrastructure. Its two defining behaviors: it scales to zero (if no requests arrive, even the last instance is removed[4]) and it bills per use, charging only for the CPU and memory an instance holds while serving a request. That makes it the default for HTTP services, web apps, and REST/GraphQL/gRPC APIs, and it also handles event-driven and asynchronous work.
Cloud Run functions: serverless functions
Cloud Run functions (the current name for what was Cloud Functions[5]) runs individual snippets of code in response to events: an HTTP request, a file landing in storage, a published message. It is the most abstracted rung: you supply only the function body. Choose it for small, event-driven pieces of logic rather than whole applications.
Elasticity: autoscaling and load balancing
This section explains why cloud compute is cheaper than buying for peak on-premises: capacity follows demand automatically, through two cooperating mechanisms.
Autoscaling adds compute when load rises and removes it when load falls. On Compute Engine this happens through a managed instance group (a set of identical VMs created from one template) which the autoscaler grows or shrinks based on signals[6] such as average CPU utilization or load-balancing serving capacity. Serverless products autoscale per request instead, including all the way to zero.
Load balancing distributes user traffic across multiple instances[7] of an application so no single instance is overwhelmed, which both raises availability and lets the app absorb traffic spikes.
The two work together, as the figure shows: the load balancer spreads incoming user traffic across the current instances of the managed instance group, while the autoscaler watches signals like CPU utilization and serving capacity and changes how many instances exist so the group keeps up with the traffic the balancer is sending it. The business payoff is that you pay for the capacity a workload actually uses moment to moment, instead of provisioning for the yearly peak and paying for idle hardware the rest of the time: the core cost advantage of cloud compute over a fixed on-premises fleet.
Exam-pattern recognition
This section maps the question stems you will see to the right answer and explains why the tempting distractors are wrong.
"Run a containerized web app / API with the least operational overhead"
The right answer is Cloud Run: fully managed, scales to zero, no clusters to operate. The distractor is GKE: it also runs containers, but it makes you think about orchestration and (in Standard mode) nodes, which is exactly the overhead the stem is trying to avoid. GKE is right only when the stem adds a need for fine-grained orchestration, microservices at scale, or cross-environment portability.
"Migrate a legacy / specialized application as-is"
The right answer pairs rehost (lift and shift) with Compute Engine VMs, because a VM resembles the server the app already ran on and lets it operate unchanged. The distractor is "re-architect it for serverless": that is a refactor or replatform decision, which costs effort the stem said wasn't wanted or possible.
"Cut cost on a fault-tolerant batch job"
The right answer is Spot VMs, which trade a deep discount for the risk that Google reclaims the instance after a short notice, fine for work that can simply rerun. The distractor is putting a steady, always-on production workload on Spot; that misuses reclaimable capacity for something that must stay up, where committed-use or standard on-demand capacity is correct.
"Run a small piece of code when an event happens"
The right answer is Cloud Run functions (event-driven, no servers). The distractor is standing up a VM or a GKE cluster to host one snippet of logic, far more infrastructure than the task needs.
"Need a specific OS, custom hardware, or GPUs with full control"
The right answer is Compute Engine, the only option exposing OS-level control and custom machine types. The distractor is a serverless service, which deliberately hides that layer and so can't satisfy the constraint.
Google Cloud compute options by control, management, and use case
| Dimension | Compute Engine | GKE | Cloud Run | Cloud Run functions |
|---|---|---|---|---|
| Model | IaaS (virtual machines) | Managed Kubernetes (containers) | Serverless containers | Serverless functions (FaaS) |
| You manage | OS, runtime, scaling config | Workloads + (Standard) node pools | Just your container/code | Just your function code |
| Google manages | Hardware, virtualization | Control plane (+ nodes in Autopilot) | All infrastructure + scaling | All infrastructure + scaling |
| Scale to zero | No | No (nodes keep running) | Yes | Yes |
| Best for | Legacy/specialized apps, OS-level control, rehost target | Container orchestration, portability, microservices at scale | HTTP services, web apps, APIs | Event-driven, short-lived logic |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Read the compute options as one spectrum from control to fully managed
Google Cloud's compute products line up by degree of abstraction: Compute Engine (VMs, you manage the OS) is the most controllable, then GKE (managed Kubernetes for containers), then Cloud Run (serverless containers), then Cloud Run functions (serverless functions) is the most managed. Moving toward the managed end hands more operational work (patching, scaling, capacity) to Google in exchange for less low-level control. The whole compute decision is just picking the right point on this line for a workload.
- Default to the most managed option a workload allows
Start at the serverless end and step toward control only when a constraint forces it, because the less infrastructure you manage the less undifferentiated work your team carries. In practice that means try Cloud Run first, move to GKE when you genuinely need container orchestration or portability, and drop to Compute Engine VMs only for OS-level control or apps that can't be re-architected.
Trap Reaching for a VM or a Kubernetes cluster by habit when a managed serverless service would run the workload. That leaves your team operating servers Google would otherwise run.
- Compute Engine is the choice for OS-level control and legacy apps
Compute Engine gives virtual machines with operating-system-level control and custom machine types, so pick it when a workload needs a specific OS, custom or specialized hardware, GPUs with full control, or is a monolithic/legacy app like a packaged relational database or ERP. Unlike the serverless options it does not scale to zero: a running VM keeps billing until stopped. It is also the standard landing place for a rehosted (lift-and-shift) app because a VM most resembles the server the app already ran on.
Trap Assuming a serverless service can satisfy a hard OS-level or custom-hardware requirement. Those layers are deliberately hidden by Cloud Run and Cloud Run functions.
7 questions test this
- A manufacturing firm needs to run a specialized legacy application that requires custom operating system configurations and licensed…
- An organization is migrating an on-premises application that currently runs on virtual machines. They want to move it to Google Cloud…
- An organization's cloud migration plan repeatedly refers to using a 'lift and shift' approach when moving its legacy servers onto Compute…
- An organization runs a specialized legacy application that depends on a specific operating system version and cannot be modified, yet it…
- A logistics company wants to move a specialized legacy application to the cloud as quickly as possible without rewriting any of its code,…
- An enterprise must move a legacy financial application to Google Cloud, but the application requires full control of the operating system,…
- An organization is adopting a phased hybrid migration and wants to move a legacy application to Google Cloud quickly, with minimal changes…
- Spot VMs trade reclaim risk for a deep discount
Spot VMs are Compute Engine instances sold from Google's spare capacity at a steep discount (up to roughly 90% off on-demand), but Google can reclaim them at any time after a brief, best-effort shutdown notice. They fit fault-tolerant, interruption-tolerant work such as batch processing, rendering, or CI fleets, where a reclaimed instance simply reruns. Spot VMs are the current generation of what Google previously called preemptible VMs.
Trap Putting a steady, always-on production workload on Spot VMs. Reclaimable capacity is wrong for anything that must stay up; use on-demand or committed-use capacity instead.
3 questions test this
- A media company runs batch video rendering jobs that can tolerate interruptions and needs to significantly reduce compute costs. The…
- An organization runs nightly batch processing jobs that can be safely interrupted and restarted at any time. They want to minimize the cost…
- A media company needs to run large-scale video rendering jobs that can tolerate interruptions. Cost optimization is their primary concern.…
- GKE is managed Kubernetes for container orchestration
Google Kubernetes Engine is a managed implementation of Kubernetes, the open-source container-orchestration system Google originally created, where orchestration means scheduling containers, restarting failed ones, and scaling them. Choose GKE when you run many containers needing orchestration, want microservices at scale, or need the same Kubernetes platform across multiple environments for portability. It does not scale to zero: its nodes keep running.
Trap Choosing GKE for a single stateless web service just to run a container. The orchestration and node management is overhead Cloud Run removes for that case.
- GKE Autopilot manages the nodes for you; Standard leaves them to you
In GKE Autopilot mode (the recommended default) Google also manages the worker nodes and you pay only for the resources your running workloads request; in Standard mode you manage the node pools yourself when a workload needs that level of control. The split matters at decision level: Autopilot is less operational work, Standard trades that for finer control over the underlying machines.
Trap Assuming Standard mode is the normal way to run GKE. Autopilot is the recommended default and offloads node management to Google.
- Cloud Run is the serverless default for HTTP services and APIs
Cloud Run is a fully managed platform that runs your container without you managing clusters or infrastructure, and it is the default for HTTP services, web apps, and REST/GraphQL/gRPC APIs. Its two defining behaviors are scaling to zero when idle and billing only for the CPU and memory used while serving requests. It can also handle event-driven and asynchronous workloads.
5 questions test this
- An e-commerce company is experiencing variable traffic patterns with peaks during sales events and minimal traffic overnight. They want to…
- A startup wants to deploy containerized web applications without managing servers. They need a solution that scales automatically with…
- An organization wants to deploy a containerized web application that receives variable traffic throughout the day. They want to minimize…
- A company wants to modernize their application by deploying it to Cloud Run. What type of container workload must the application be?
- A media company wants to deploy a stateless image processing service that experiences traffic spikes during marketing campaigns. They need…
- Scale-to-zero means no cost while idle but watch cold starts
Cloud Run scales to zero: if no requests arrive, even the last instance is removed, so you pay nothing while idle. The flip side is that a request arriving against zero instances incurs a cold start, and a workload needing a persistent always-running background process is a poor fit for scale-to-zero. For those, a VM or a GKE workload that keeps running is the better match.
Trap Putting a workload that must keep a long-lived process always running on a scale-to-zero serverless service. It gets torn down when idle.
- Cloud Run functions runs event-driven snippets of code
Cloud Run functions (formerly named Cloud Functions) runs an individual piece of code in response to an event such as an HTTP request, a file landing in storage, or a published message, the most abstracted compute rung, where you supply only the function body. Reach for it for small event-driven logic, not whole applications, which belong on Cloud Run, GKE, or a VM.
Trap Standing up a VM or a GKE cluster to host a single event-triggered snippet. That is far more infrastructure than the task needs.
- Containers package an app to run identically anywhere
A container bundles an application with its libraries and dependencies so it runs the same on a laptop, in a data center, or in any cloud, which is what makes container-based apps portable. This is the deployment unit GKE and Cloud Run both run, and it pairs with microservices: splitting one large application into small, independently deployable services usually shipped as separate containers.
4 questions test this
- During seasonal peaks, an online retailer normally runs its containerized application on-premises but needs to add extra capacity in a…
- A startup is building a new REST API service and wants to use any programming language and framework without managing infrastructure. They…
- An organization values open source technologies and wants its container platform to use open APIs so that workloads are not tied to a…
- An organization wants to deploy applications packaged as standard container images and avoid being locked into a single vendor, so they can…
- Autoscaling matches capacity to demand automatically
Autoscaling adds compute when load rises and removes it when load falls so you pay for what a workload actually uses instead of provisioning for peak. On Compute Engine this works through a managed instance group (identical VMs from one template) that the autoscaler grows or shrinks on signals like CPU utilization or load-balancing capacity; serverless products autoscale per request, including down to zero. This automatic elasticity is a core reason cloud compute costs less than a fixed on-premises fleet sized for the yearly peak.
4 questions test this
- An organization has refactored its monolith into containerized microservices. During holiday sales, only its payment-processing service…
- An organization wants to automatically adjust the number of virtual machines in their web application based on CPU utilization. What is a…
- A development team has containerized their application into multiple microservices and wants the cluster to automatically add and remove…
- A retailer's web application running on Compute Engine experiences unpredictable spikes in traffic during promotions and quiet periods…
- Load balancing spreads traffic across instances for availability
A load balancer distributes user traffic across multiple instances of an application so no single instance is overwhelmed, which raises availability and lets the app absorb spikes. It works hand in hand with autoscaling: the load balancer spreads requests across the current instances while autoscaling changes how many instances exist to keep up with that traffic.
- Rehost (lift and shift) onto a VM for apps you can't re-architect
Rehosting moves a workload to the cloud with little or no modification, and it is the right path when an app is legacy or specialized, when there is no business case to change it, or when you simply cannot refactor it. The natural target is a Compute Engine VM, because it most resembles the on-premises server the app already ran on, letting the app operate as-is while still gaining cloud elasticity and reliability.
Trap Choosing rehost-to-VM when the business actually wants the app modernized. That is a replatform or refactor decision, not lift and shift.
7 questions test this
- A manufacturing firm needs to run a specialized legacy application that requires custom operating system configurations and licensed…
- An organization is migrating an on-premises application that currently runs on virtual machines. They want to move it to Google Cloud…
- An organization's cloud migration plan repeatedly refers to using a 'lift and shift' approach when moving its legacy servers onto Compute…
- An organization runs a specialized legacy application that depends on a specific operating system version and cannot be modified, yet it…
- A logistics company wants to move a specialized legacy application to the cloud as quickly as possible without rewriting any of its code,…
- An enterprise must move a legacy financial application to Google Cloud, but the application requires full control of the operating system,…
- An organization is adopting a phased hybrid migration and wants to move a legacy application to Google Cloud quickly, with minimal changes…
- Cloud compute replaces buying for peak with paying for use
On-premises you buy hardware for the yearly peak and pay for it even when idle; cloud compute instead scales capacity up and down with demand and bills accordingly, turning a large fixed capital cost into a variable operating cost. That elasticity, delivered by autoscaling and the pay-per-use serverless model, is the central business value of cloud compute the exam expects you to articulate.
Also tested in
References
- https://cloud.google.com/hosting-options
- https://cloud.google.com/compute/docs/instances/spot
- https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview
- https://cloud.google.com/run/docs/overview/what-is-cloud-run
- https://cloud.google.com/functions/docs/concepts/overview
- https://cloud.google.com/compute/docs/autoscaler
- https://cloud.google.com/load-balancing/docs/load-balancing-overview