Compute Systems

The compute ladder: pick the highest rung that fits

A scenario reads "we run a stateless REST API, traffic is bursty and sometimes zero overnight, and we do not want to manage servers." That picks Cloud Run^[1] before you read another word, because Cloud Run scales to zero and charges only while serving. Most PCA compute questions are this shape: a workload's real constraints point to exactly one rung of Google Cloud's compute ladder, and the wrong answers are rungs that either give up control you actually need or keep you managing infrastructure you do not.

The four core products order by degree of abstraction^[2], from most control to most managed:

Compute Engine gives you virtual machines (infrastructure as a service). You choose the machine type, the operating system image, the disks, and the network, and you remain responsible for the OS, runtime, and scaling. It is the rung for a licensed or custom OS, a specific kernel, or anything that needs full host control.
Google Kubernetes Engine (GKE) is Google's managed Kubernetes^[3], the open-source container-orchestration system. You deploy containers in Pods and Kubernetes schedules, restarts, and scales them. It is the rung for multi-service systems that need orchestration: service meshes, complex networking, DaemonSets, or GPUs.
Cloud Run is a serverless platform for containers^[1]. You hand it a container image and it runs and autoscales it, out to many instances and back down to zero, with no cluster to manage. It is the rung for stateless, request-driven services and APIs.
Cloud Run functions (the current name for Cloud Functions^[4]) runs short, event-driven code triggered by HTTP, Cloud Storage, or Pub/Sub events, with no container build pipeline of your own.

The rule that decides questions: climb until the platform fits, then stop. Each step up the ladder hands more operational work (patching, node sizing, capacity planning) to Google, so the highest rung that still meets the workload's hard constraints is the cost- and operations-optimal answer. Standing up a GKE cluster for one stateless HTTP service is the classic over-engineering miss; dropping to raw VMs for a workload that has no OS-level requirement is the classic under-delegation miss.

Where Google Cloud VMware Engine sits

One more option sits off to the side of the native ladder. Google Cloud VMware Engine (GCVE) runs the native VMware stack (vSphere, vSAN, NSX) on dedicated bare-metal nodes inside Google Cloud. It is not a more-managed or less-managed rung; it is a parallel path for organizations that must move an existing VMware estate into the cloud while keeping their existing VMware tooling, operations, and licensing. Choose it when the requirement is to preserve the VMware operating model rather than to modernize onto native compute. When the goal is instead to land workloads as native Compute Engine VMs, the tool is Migrate to Virtual Machines^[5], which converts source VMs into Compute Engine instances rather than running VMware itself.

The Google Cloud compute ladder by abstraction, with VMware Engine as a separate lift-and-shift path. Modeled on the Google Cloud hosting-options guide.

GKE Standard vs Autopilot, and Cloud Run sizing

Once a workload lands on GKE, the next decision is the mode, and the default is Autopilot. The split is who owns the nodes. In Autopilot mode^[6] Google provisions, scales, secures, and upgrades the worker nodes, and you are billed for the CPU, memory, and ephemeral storage your running Pods request rather than for whole nodes. In Standard mode^[7] you create and size the node pools yourself, manage upgrades and bin-packing, and pay for the nodes whether or not Pods fill them.

The rule: Autopilot is the recommended default; choose Standard only for node-level control. That control means things Autopilot deliberately restricts so it can manage the nodes: privileged DaemonSets, specific machine families or sole-tenant placement, certain GPU configurations, or running workloads that need to reach into the node OS. If the question describes a standard microservices platform and asks for the least operational overhead, the answer is Autopilot; if it requires a capability that only unmanaged nodes expose, the answer is Standard.

Cloud Run scaling and concurrency

Cloud Run sits one rung up and removes nodes entirely. It autoscales on incoming requests and scales to zero^[1] when no requests arrive, so an idle service is not billed. Two levers shape its behavior and its cost:

Concurrency is how many requests one container instance handles at once. A higher concurrency packs more requests per instance and lowers cost for lightweight requests; concurrency of 1 isolates each request, which suits CPU-heavy or non-thread-safe code.
Minimum instances keeps a set number of instances warm to avoid cold-start latency on the first request; this trades the scale-to-zero saving for predictable latency.

The exam contrast to keep straight: Cloud Run is for request-driven container services and Cloud Run functions for short event-driven snippets, while GKE is for when you genuinely need Kubernetes orchestration. Reaching for a cluster when Cloud Run would do adds cluster management for no benefit.

GKE mode choice: Autopilot is the default; Standard only when node-level control is required.

Compute Engine: machine sizing, MIGs, and autoscaling

On the Compute Engine rung, three mechanics decide most questions: how you size a VM, how you make a group of VMs elastic and self-healing, and where dedicated hardware is required.

Sizing: predefined, custom, and sole-tenant

Google offers predefined machine types in families (general-purpose, compute-optimized, memory-optimized). When a workload's CPU-to-memory ratio does not match a predefined shape, custom machine types^[8] let you set vCPU and memory independently, removing the waste of rounding up to the next standard size. Custom types change sizing only, not behavior. When a software license requires dedicated physical hardware, sole-tenant nodes^[9] are physical servers that host only one project's VMs, satisfying bring-your-own-license terms for per-core or per-processor software such as Windows Server, SQL Server, or Oracle, and reporting the physical server ID so you can track license compliance.

Managed instance groups: the unit of scale and resilience

The single most-tested Compute Engine pattern is the managed instance group (MIG)^[10]. A MIG creates and maintains a set of identical VMs from an instance template, and it provides four capabilities a lone VM cannot:

Autohealing recreates a VM that fails an application-based health check^[11], so a hung instance is replaced automatically rather than serving errors.
Regional (multi-zone) deployment spreads instances across zones in a region, so a single zone failure does not take the service down.
Autoscaling adds or removes VMs to match demand.
Automated rolling updates roll a new instance template across the group with surge and disruption controls.

The MIG autoscaler^[12] scales on one of several signals: average CPU utilization, serving capacity reported by an attached load balancer, or a Cloud Monitoring metric (for example queue depth). You set a target value and minimum and maximum instance counts, and the autoscaler adjusts the group toward the target. The architecture rule: a production VM tier that must survive failure or absorb load belongs in a regional MIG behind a load balancer, never as hand-placed individual VMs.

# A MIG with CPU-target autoscaling
gcloud compute instance-groups managed create web-mig \
  --template=web-template --size=3 --zone=us-central1-a
gcloud compute instance-groups managed set-autoscaling web-mig \
  --max-num-replicas=10 --min-num-replicas=3 \
  --target-cpu-utilization=0.6 --zone=us-central1-a

A managed instance group builds VMs from a template across zones, autoscales on a signal, and autoheals failed instances.

Volatility and discounts: Spot, standard, and committed use

Compute volatility configuration is a cost-versus-availability trade, and the exam wants the line drawn precisely. Spot VMs run on Compute Engine spare capacity at up to roughly 91% off on-demand, and the catch is that Google can reclaim them at any time^[13] after a short best-effort shutdown notice. Spot VMs are the current generation of the older preemptible VMs. The same discount class is available as Spot Pods on GKE.

The rule: Spot fits fault-tolerant, restartable work and nothing else. Batch processing, big-data jobs, CI fleets, and stateless web tiers behind a MIG all tolerate a node vanishing because the work just reruns or another instance picks up. Anything that cannot survive sudden termination, a stateful job without checkpointing, a database, a single-instance service, belongs on standard capacity.

The pricing alternatives for non-interruptible work are not Spot:

Standard (on-demand) VMs carry no interruption risk and no commitment, at the highest per-hour rate.
Sustained-use discounts^[14] apply automatically, with no commitment, the longer an eligible VM runs within a billing month.
Committed-use discounts require a one- or three-year usage commitment in exchange for a lower rate; they are mutually exclusive with sustained-use discounts on the same usage and are the right tool for a steady, predictable workload you know will run.

The trap the exam plants: offering Spot as a way to cut the cost of a steady, always-on workload. Spot targets interruptible work; the cost lever for steady standard load is committed-use discounts, which keep full availability.

Patch management for the VMs you keep

For the standard VMs that remain, operating-system patching is the operational duty Compute Engine leaves with you, and the architecture answer is to centralize it. VM Manager^[15] provides OS patch management that reports patch compliance across the whole fleet and runs scheduled or on-demand patch jobs^[16] against many VMs at once, for both Linux and Windows, through the OS Config agent. SSHing into each VM to update it does not scale and drifts out of compliance. Note the contrast up the ladder: on Cloud Run and GKE Autopilot, Google patches the underlying OS, so patch management is one of the operational burdens that disappears as you climb.

Volatility and pricing: Spot for interruptible work; committed-use for steady standard load; sustained-use applies automatically.

Exam-pattern recognition

PCA compute questions are scenario stems where one decisive phrase fixes the rung of the ladder, the VM pattern, or the pricing model. Read for that phrase, map it, and most distractors fall away.

Stem signals to the right answer

The stem emphasizes...	Right answer	Why the obvious distractor is wrong
Stateless HTTP service, bursty, scale to zero, no servers	Cloud Run	GKE adds a cluster to manage for no benefit on a single service
Short code triggered by a Cloud Storage or Pub/Sub event	Cloud Run functions	A VM or container service is more than event glue needs
Multi-service system, service mesh, GPUs, fine scheduling	GKE (Autopilot default)	Cloud Run cannot do cluster-level orchestration
Least operational overhead on Kubernetes	GKE Autopilot	Standard makes you manage and pay for nodes
Need privileged DaemonSets or a specific node machine family	GKE Standard	Autopilot restricts node-level access to manage the nodes
Licensed OS or custom kernel, full host control	Compute Engine VM	Managed rungs do not expose the OS
License requires dedicated physical hardware (BYOL)	Sole-tenant nodes	Multi-tenant VMs cannot meet a dedicated-hardware license term
VM tier must survive a zone failure and absorb load	Regional MIG + load balancer + autoscaler	A single VM has no autohealing, multi-zone, or autoscaling
Hung VM keeps serving errors, replace it automatically	MIG autohealing (health check)	Scaling on CPU does not detect an unhealthy-but-running VM
CPU-to-memory ratio does not fit a predefined shape	Custom machine type	Rounding up to a standard size wastes capacity
Interruptible batch / CI at lowest cost	Spot VMs / Spot Pods	On-demand or committed use costs far more for restartable work
Cut cost of a steady, always-on workload	Committed-use discount	Spot targets interruptible work and can be reclaimed
Keep a large VM fleet patched and compliant	VM Manager OS patch management	Per-VM SSH updates do not scale and drift out of compliance
Move a VMware vSphere estate as-is, keep VMware tooling	Google Cloud VMware Engine	Migrate to VMs converts to native VMs, dropping the VMware stack

Three traps to internalize

Spot is for interruptible work only. When a stem says "steady," "always-on," or "production database" and offers Spot as the cheap option, it is wrong; the cost lever there is committed-use discounts, which keep full availability.
Climb the ladder, but not past the fit. A single stateless service does not need GKE; Cloud Run gives scale-to-zero with no cluster. Conversely, a workload needing a licensed OS or node-level control cannot live on a serverless rung. Match the rung to the hard constraint, not to the most or least managed option by reflex.
The MIG is the resilience unit, not the VM. Autohealing, multi-zone placement, and autoscaling are MIG features; a lone VM has none of them. A scenario asking for self-healing or elastic capacity points at a managed instance group behind a load balancer.

The compute ladder across the four core products

Dimension	Compute Engine	GKE	Cloud Run	Cloud Run functions
Abstraction	VMs (IaaS)	Managed Kubernetes	Serverless containers	Serverless functions
Unit you deploy	VM / instance template	Container in a Pod	Container image	A function
You manage the OS / nodes?	Yes (VM Manager to patch)	Autopilot: no; Standard: yes	No (Google manages)	No (Google manages)
Scaling	MIG autoscaler	Cluster + Pod autoscaling	Request-based, scales to zero	Event-based, scales to zero
Best fit	Licensed OS, custom kernel, host control	Multi-service orchestration, GPUs	Stateless request-driven services	Short event-driven code
Cheapest interruptible option	Spot VMs (~91% off)	Spot Pods	n/a (pay per request)	n/a (pay per invocation)

Decision tree

Cheat sheet

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.

Pick the highest compute rung that still meets the workload's hard constraints

Google Cloud's compute products order by abstraction from most control to most managed: Compute Engine (VMs), GKE (managed Kubernetes), Cloud Run (serverless containers), and Cloud Run functions (serverless functions). Each step up hands more operations (patching, node sizing, capacity) to Google, so the cost- and operations-optimal answer is the highest rung whose hard constraints you still satisfy. A real OS-level requirement pins you lower; the absence of one lets you climb.

Trap Reflexively choosing the most-managed option without checking constraints; a licensed OS or custom kernel forces Compute Engine no matter how convenient Cloud Run looks.

Use Cloud Run for stateless, request-driven container services

Cloud Run runs any container that serves requests, autoscales on incoming traffic, and scales to zero when idle so you pay only while serving. It is the default for stateless HTTP services and APIs with bursty or intermittent load, because an idle service costs nothing and there is no cluster to manage.

Trap Standing up a GKE cluster for a single stateless service just to get autoscaling; that adds cluster management Cloud Run removes.

Use Cloud Run functions for short event-driven code

Cloud Run functions (the current name for Cloud Functions) runs short snippets triggered by HTTP, Cloud Storage, or Pub/Sub events, with no server and no container build pipeline of your own. Reach for it when the workload is event glue rather than a long-running service; a full container service or VM is more than the job needs.

Use GKE only when you genuinely need Kubernetes orchestration

GKE is the rung for multi-service systems that need Kubernetes-level control: service meshes, complex networking, DaemonSets, GPUs, or fine-grained scheduling. If the workload is a single request-driven service, Cloud Run gives scale-to-zero with no cluster; reserve GKE for true orchestration needs so you do not pay the cluster-management cost for nothing.

Trap Choosing Cloud Run for a multi-service platform that needs a service mesh, DaemonSets, or fine-grained scheduling; Cloud Run runs containers but offers no cluster-level orchestration.

Default to GKE Autopilot; choose Standard only for node-level control

GKE Autopilot has Google provision, scale, secure, and upgrade the nodes, and bills only for the CPU and memory your running Pods request. Standard makes you size and manage node pools and pay per node whether or not Pods fill them. Autopilot is the recommended default for least operational overhead; pick Standard only when you need node-level control such as privileged DaemonSets, a specific machine family or sole-tenant placement, or GPU configurations Autopilot does not expose.

Trap Choosing Standard for least operational overhead; Standard hands node management and per-node billing back to you, the opposite of low-overhead.

Tune Cloud Run with concurrency and minimum instances

Concurrency sets how many requests one Cloud Run instance handles at once: higher concurrency packs more requests per instance and lowers cost for lightweight requests, while concurrency of 1 isolates each request for CPU-heavy or non-thread-safe code. Minimum instances keeps a number of instances warm to avoid cold starts, trading the scale-to-zero saving for predictable first-request latency.

8 questions test this

The managed instance group, not the VM, is the unit of scale and resilience

A managed instance group (MIG) builds identical VMs from an instance template and provides what a lone VM cannot: autohealing (recreate a VM that fails its health check), regional multi-zone placement (survive a zone failure), autoscaling, and automated rolling updates. Any production VM tier that must survive failure or absorb load belongs in a regional MIG behind a load balancer.

Trap Deploying hand-placed individual VMs for a tier that must self-heal or scale; an unmanaged VM has no autohealing, multi-zone spread, or autoscaling.

MIG autoscaling runs on CPU, load-balancer capacity, or a Monitoring metric

The MIG autoscaler scales the group toward a target on one signal: average CPU utilization, serving capacity reported by an attached load balancer, or a Cloud Monitoring metric such as queue depth. You set the target value plus minimum and maximum instance counts, and it adds or removes VMs to hold the target.

MIG autohealing replaces a VM that fails an application health check

Autohealing uses an application-based health check to detect a VM that is running but not serving correctly, and recreates it automatically. This catches a hung-but-running instance that CPU-based scaling would miss entirely, so a scenario about a VM that keeps serving errors and should be replaced automatically points at MIG autohealing, not at the autoscaler.

Trap Relying on the autoscaler to replace a hung VM; CPU-based scaling does not detect an unhealthy-but-running instance, only autohealing's health check does.

Use custom machine types when the CPU-to-memory ratio does not fit a preset

Compute Engine custom machine types let you set vCPU and memory independently rather than rounding up to the next predefined shape, removing waste when a workload's CPU-to-memory ratio does not match a standard size. They change sizing only, not workload behavior.

Trap Rounding up to a larger predefined machine type to get enough memory; that overprovisions vCPU you do not need and pays for waste a custom type avoids.

Use sole-tenant nodes when a license requires dedicated physical hardware

Sole-tenant nodes are physical Compute Engine servers that host only one project's VMs, satisfying bring-your-own-license terms for per-core or per-processor software such as Windows Server, SQL Server, or Oracle that mandate dedicated hardware. They report the physical server ID a VM runs on so you can track core and processor usage for license compliance. Standard multi-tenant VMs are cheaper but cannot meet a dedicated-hardware license requirement.

Trap Putting BYOL per-core software on standard multi-tenant VMs; the license term requiring dedicated hardware is not met, regardless of cost.

Run only interruption-tolerant work on Spot VMs

Spot VMs use Compute Engine spare capacity for up to roughly 91% off on-demand, but Google can reclaim them at any time after a short best-effort shutdown notice; they are the current generation of preemptible VMs. That fits fault-tolerant, restartable work like batch processing, big-data jobs, CI fleets, and stateless web tiers behind a MIG, where a lost node just reruns. The same discount class is available as Spot Pods on GKE.

Trap Running a stateful, non-restartable job on Spot without checkpointing; one reclaim mid-task loses the in-flight state.

1 question tests this

Your company runs a batch processing workload on GKE that is fault-tolerant and can handle interruptions. You want to reduce compute costs…

Cut the cost of steady, always-on workloads with committed-use discounts, not Spot

For a predictable workload you know will run continuously, a one- or three-year committed-use discount lowers the rate while keeping full availability. Spot targets interruptible work and can be reclaimed, so it is the wrong cost lever for steady or production load. Sustained-use discounts also apply automatically with no commitment the longer an eligible VM runs in a billing month, and they are mutually exclusive with committed-use on the same usage.

Trap Offering Spot as the way to save money on a steady, always-on or production-database workload; Spot can vanish on a reclaim, which that workload cannot absorb.

Patch a VM fleet centrally with VM Manager OS patch management

VM Manager's OS patch management reports patch compliance across the whole Compute Engine fleet and runs scheduled or on-demand patch jobs against many Linux and Windows VMs at once through the OS Config agent. The architecture answer for keeping a large fleet current is centralized patch orchestration, because SSHing into each VM to update it does not scale and drifts out of compliance.

Trap Managing patches by logging into each VM individually; it does not scale and leaves the fleet out of compliance, which is exactly what VM Manager exists to prevent.

Climbing the ladder removes OS patching as your responsibility

On Cloud Run and GKE Autopilot, Google patches the underlying operating system, so OS patch management disappears from your operational burden. This is a concrete reason to climb the compute ladder when a workload allows it: the patching duty you would carry on Compute Engine VMs is one of the operations handed to Google on the managed rungs.

Use Google Cloud VMware Engine to run an existing VMware estate as-is

Google Cloud VMware Engine (GCVE) runs the native VMware stack (vSphere, vSAN, NSX) on dedicated bare-metal nodes inside Google Cloud, so an organization can lift a vSphere estate into the cloud without re-architecting and keep its existing VMware tooling, operations, and licensing. Choose it when the requirement is to preserve the VMware operating model rather than to modernize onto native compute.

Trap Choosing GCVE when the goal is to modernize onto native managed services; it keeps the old VMware operating model instead of moving off it.

GCVE preserves VMware; Migrate to VMs converts to native Compute Engine

GCVE runs VMware itself on dedicated nodes, whereas Migrate to Virtual Machines converts source VMs into native Compute Engine instances. The choice turns on intent: preserve the VMware stack and tooling (GCVE) versus land workloads as native VMs you then manage and optimize like any other Compute Engine instance (Migrate to VMs).

Trap Picking Migrate to VMs when the requirement is to keep running the native VMware stack; it drops the VMware layer by converting to Compute Engine VMs.

Use the optimize-utilization autoscaler profile to scale GKE nodes down more aggressively

The cluster autoscaler's optimize-utilization profile removes underused nodes faster and bin-packs Pods onto already-loaded nodes, cutting cost at the price of slightly slower scheduling during spikes. The default balanced profile keeps more spare capacity for responsiveness.

Trap The profile only controls how aggressively nodes are removed; it does not protect critical Pods — annotate those separately so they are not evicted.

4 questions test this

Pods block GKE scale-down via safe-to-evict:false, restrictive PodDisruptionBudgets, or kube-system Pods without a PDB

The cluster autoscaler will not remove a node whose Pods cannot be safely drained. A node stays up if a Pod has the cluster-autoscaler.kubernetes.io/safe-to-evict: false annotation, if a PodDisruptionBudget would be violated (e.g. maxUnavailable: 0), or if it runs kube-system Pods that lack a PDB. Loosen the PDB or add one to let scale-down proceed.

Trap Low utilization alone does not trigger scale-down — an idle node sticks around until every Pod on it is evictable.

4 questions test this

The compute ladder: pick the highest rung that fits

Where Google Cloud VMware Engine sits

GKE Standard vs Autopilot, and Cloud Run sizing

Cloud Run scaling and concurrency

Compute Engine: machine sizing, MIGs, and autoscaling

Sizing: predefined, custom, and sole-tenant

Managed instance groups: the unit of scale and resilience

Volatility and discounts: Spot, standard, and committed use

Patch management for the VMs you keep

Exam-pattern recognition

Stem signals to the right answer

Three traps to internalize

The compute ladder across the four core products

Decision tree

Cheat sheet

Also tested in

References