Choosing and Deploying Compute: Compute Engine, GKE, and Cloud Run

Choose by asking two questions in order: is the workload containerized, and who should manage the infrastructure? If you need OS access, custom kernels, GPUs attached to a specific machine shape, or you are migrating an existing VM as-is, use Compute Engine. If you run many containers that need orchestration — service discovery, rolling updates, stateful workloads, fine-grained scheduling — use Google Kubernetes Engine (GKE). If you have a stateless container that serves requests or processes events and you never want to think about nodes, use Cloud Run. If you have a single-purpose snippet of code that reacts to an event or an HTTP call, use Cloud Run functions. For deploying and hosting AI agents, Google Cloud also offers Agent Runtime on the Gemini Enterprise Agent Platform — the exam expects you to recognize it as the managed home for agent workloads, not to configure it deeply.

The exam rewards elimination. A question that mentions lift and shift, custom OS, or sole-tenant licensing points at Compute Engine. Mentions of Kubernetes, Pods, or multi-container microservices with complex networking point at GKE. Mentions of scale to zero, pay only while handling requests, or stateless HTTP container point at Cloud Run. Mentions of respond to a file upload or run code when a message arrives point at Cloud Run functions.

Scenario: a retailer migrates a legacy inventory server that needs a specific Linux kernel module (Compute Engine), refactors its storefront into a dozen microservices its platform team already runs on Kubernetes on-premises (GKE), exposes a stateless recommendation API that spikes on weekends (Cloud Run), and generates a thumbnail whenever a product image lands in a bucket (Cloud Run functions). One system, four correct answers — the exam builds questions exactly like this.

You launch an instance with gcloud compute instances create, and the two settings the exam singles out are the availability policy and SSH key handling. The availability policy controls what happens during host maintenance and after a crash. --maintenance-policy=MIGRATE (the default for most machine types) live-migrates the VM to another host during maintenance with no downtime; --maintenance-policy=TERMINATE stops it instead, which is required for some GPU-attached instances and acceptable for interruptible batch work. Pair this with --restart-on-failure (default) or --no-restart-on-failure to control automatic restart after a crash or termination.

gcloud compute instances create web-1 --zone=us-central1-a --machine-type=e2-medium --maintenance-policy=MIGRATE --restart-on-failure

For SSH, you have three layers. Project-wide SSH keys in project metadata reach every VM in the project; instance-level keys in instance metadata reach one VM, and you can set --metadata=block-project-ssh-keys=TRUE on a sensitive instance so project-wide keys do not apply to it. The simplest path is gcloud compute ssh web-1 --zone=us-central1-a, which generates and propagates a key for you. The recommended layer for teams, though, is OS Login, covered next — know that metadata-based keys and OS Login are mutually exclusive per instance, and enabling OS Login disables metadata SSH keys on that VM.

A gotcha worth remembering: availability policy is mutable. You can change maintenance behavior on a running instance with gcloud compute instances set-scheduling, so a wrong choice at launch is not permanent.

OS Login ties SSH access to IAM identities instead of scattered metadata keys, which is why Google recommends it and why the exam favors it. Enable it by setting the metadata key enable-oslogin=TRUE at the project level (all VMs) or per instance: gcloud compute project-info add-metadata --metadata=enable-oslogin=TRUE. Access is then granted with IAM roles: roles/compute.osLogin for a standard user and roles/compute.osAdminLogin for sudo access. Revoking a person's access becomes an IAM change, not a hunt through metadata on dozens of VMs — that centralized-revocation story is the exam's favorite justification. OS Login also supports two-step verification and posture-aware policies through the user's Google identity.

VM Manager is the fleet-management suite for Compute Engine, built on the OS Config agent that ships in Google-provided images. It has three capabilities you should map to their jobs: OS patch management runs on-demand or scheduled patch jobs across the fleet and reports compliance; OS inventory management collects installed-package and OS-version data from each VM; and OS policies declaratively ensure a package, agent, or configuration is present (or absent) on matching VMs. Enable it by setting the enable-osconfig=TRUE metadata key and ensuring the agent and required APIs are active.

Choose the tool by the verb in the question: grant or revoke SSH via IAM is OS Login; patch, inventory, or enforce configuration across many VMs is VM Manager. They complement each other — one governs who gets in, the other governs what runs on the machine.

Choose block storage by durability scope and performance model. A zonal Persistent Disk lives in one zone and is the default choice for boot disks and general data. A regional Persistent Disk synchronously replicates every write across two zones in the same region, so if the VM's zone fails you can force-attach the disk to a standby VM in the other zone — it exists for high-availability failover, at higher cost and slightly higher write latency. Hyperdisk is the newest generation: performance (IOPS and throughput) is provisioned independently of capacity, so you no longer buy a bigger disk just to get more IOPS. The newest machine series support only Hyperdisk, so expect it to appear as the correct modern answer.

Within Persistent Disk, know the types by workload: pd-standard (HDD-backed, cheap, sequential and backup workloads), pd-balanced (SSD, the general-purpose default), pd-ssd (higher IOPS for databases), and pd-extreme (provisioned-IOPS for the most demanding databases on supported machine types). Hyperdisk variants follow the same logic: Hyperdisk Balanced for general use, Hyperdisk Extreme for maximum IOPS, Hyperdisk Throughput for streaming and analytics-style sequential reads, and Hyperdisk ML for feeding read-heavy machine-learning workloads. Local SSD is the outlier: physically attached, extremely fast, but ephemeral — data does not survive instance stop or termination, so it is only correct for caches and scratch space.

gcloud compute disks create data-disk --zone=us-central1-a --type=pd-ssd --size=200GB

gcloud compute disks create ha-disk --region=us-central1 --replica-zones=us-central1-a,us-central1-b --type=pd-ssd --size=200GB

Exam cue mapping: survive a zonal outage without restoring from backup means regional PD; tune IOPS separately from size means Hyperdisk; lowest latency scratch data you can afford to lose means Local SSD; everything else defaults to zonal pd-balanced.

A managed instance group (MIG) keeps a set of identical VMs healthy and at the size you ask for, and it is built from an instance template — an immutable definition of machine type, image, disks, network, and startup script. Immutability matters: to change the fleet you create a new template and update the group (rolling updates are the Section 3 follow-on), you never edit a template in place. Create the pieces like this:

gcloud compute instance-templates create web-template --machine-type=e2-small --image-family=debian-12 --image-project=debian-cloud --tags=http-server

gcloud compute instance-groups managed create web-mig --template=web-template --size=3 --region=us-central1

gcloud compute instance-groups managed set-autoscaling web-mig --region=us-central1 --min-num-replicas=3 --max-num-replicas=12 --target-cpu-utilization=0.65 --cool-down-period=90

Autoscaling can key on CPU utilization, load-balancer serving capacity, or Cloud Monitoring metrics. A regional MIG spreads instances across multiple zones, which is the standard high-availability answer for VM-based web tiers; add an autohealing health check so the MIG recreates instances that fail application-level checks, not just crashed VMs.

Two cost levers finish this picture. Spot VMs (--provisioning-model=SPOT on the template or instance) run at a deep discount but can be preempted whenever Compute Engine needs the capacity, so they fit fault-tolerant batch and CI workloads — never a database or anything that cannot checkpoint. Spot capacity is not guaranteed and carries no availability SLA. Custom machine types let you specify exact vCPU and memory (for example --custom-cpu=6 --custom-memory=24GB on supported families) when predefined shapes waste money — the classic scenario is a memory-heavy app that would otherwise force you two sizes up a predefined ladder just for the RAM.

GKE offers two modes and several shapes, and the exam wants you to pick the combination from requirements. Autopilot is the default and recommended mode: Google manages nodes, node pools, and node-level security entirely, you pay per Pod resource request, and you cannot SSH into nodes. Standard mode gives you node pools to configure and pay for yourself — the right answer only when the question demands node-level control (custom node images, specific machine shapes, DaemonSet-level tuning). Shape-wise, a zonal cluster has its control plane in one zone; a regional cluster replicates the control plane and (in Standard) the nodes across multiple zones, so the Kubernetes API survives a zonal outage — the availability answer. A private cluster gives nodes only internal IP addresses; they reach the internet through Cloud NAT, and access to the control-plane endpoint is restricted with authorized networks.

gcloud container clusters create-auto prod-cluster --region=us-central1

gcloud container clusters create std-cluster --region=us-central1 --num-nodes=1 --enable-private-nodes --enable-ip-alias --master-ipv4-cidr=172.16.0.0/28

Note that Autopilot clusters are always regional, and --num-nodes on a regional Standard cluster is per zone — three zones with --num-nodes=1 is three nodes total, a classic trick detail.

To work with any cluster you need kubectl, installed as a gcloud component: gcloud components install kubectl, plus the GKE auth plugin (gcloud components install gke-gcloud-auth-plugin) that lets kubectl authenticate with your Google credentials. Then fetch credentials, which writes the cluster into your kubeconfig: gcloud container clusters get-credentials prod-cluster --region=us-central1. If a question shows kubectl failing with no credentials or pointing at the wrong cluster, get-credentials is nearly always the fix.

Deployment to GKE follows one pipeline: build an image, push it to Artifact Registry, create a Kubernetes Deployment that references the image, and expose it with a Service. The exam expects the imperative commands and their declarative equivalents:

gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/apps/web:v1

kubectl create deployment web --image=us-central1-docker.pkg.dev/my-project/apps/web:v1

kubectl scale deployment web --replicas=3

kubectl expose deployment web --type=LoadBalancer --port=80 --target-port=8080

A Service of type LoadBalancer provisions a Google Cloud passthrough load balancer with an external IP; type ClusterIP keeps a service internal to the cluster; and an Ingress (or the Gateway API) provisions an application load balancer for HTTP routing across services. In production you express all of this declaratively — a Deployment manifest with resource requests and a Service manifest — applied with kubectl apply -f deployment.yaml, which also makes changes repeatable and reviewable.

Two gotchas the exam likes: first, on Autopilot every container should declare resource requests, because requests are what you are billed for and what scheduling is based on; second, if Pods stick in ImagePullBackOff, the usual causes are a typo in the image path or missing permission for the node service account to read Artifact Registry. Checking with kubectl get pods and kubectl describe pod is the expected first move.

Cloud Run deploys a container image as an autoscaling HTTPS service in one command: gcloud run deploy api --image=us-central1-docker.pkg.dev/my-project/apps/api:v1 --region=us-central1 --allow-unauthenticated. Omit --allow-unauthenticated and callers must present IAM credentials (roles/run.invoker). Cloud Run functions layer a function-as-a-service developer experience on the same infrastructure: you deploy source code with an entry point and a trigger, and Google builds and runs the container for you — for example gcloud functions deploy resize-image --runtime=python312 --trigger-bucket=uploads-bucket --entry-point=handler runs on every object change in that bucket.

Event processing has three patterns to keep straight. Pub/Sub: a push subscription delivers each message as an HTTP POST to a Cloud Run service, or a function uses --trigger-topic directly — the standard answer for decoupled, at-least-once message processing. Cloud Storage notifications: object finalize, delete, and archive events trigger a function or, via Eventarc, a Cloud Run service — the answer for react-to-upload scenarios. Eventarc is the general routing layer: it delivers events from Google sources (including Cloud Audit Logs events from dozens of services) to Cloud Run and other destinations in CloudEvents format, for example gcloud eventarc triggers create new-file --destination-run-service=processor --event-filters=type=google.cloud.storage.object.v1.finalized --event-filters=bucket=uploads-bucket --location=us-central1 --service-account=eventarc-sa@my-project.iam.gserviceaccount.com. When a question asks how to route an arbitrary Google Cloud event to a container, Eventarc is the answer.

Finally, accelerators. GPUs are the general-purpose choice: attach them to Compute Engine VMs, GKE nodes, and supported serverless workloads for graphics, transcoding, and training or serving a broad range of ML frameworks. TPUs are Google's custom ASICs built specifically for large-scale tensor mathematics — the right answer when the question names very large model training or massive matrix workloads, typically on frameworks like JAX, TensorFlow, or PyTorch built for TPU. Rule of thumb for the exam: mixed or moderate ML plus any non-ML acceleration means GPU; enormous, purpose-built model training means TPU.