Compute Engine & Autoscaling

Assumes you're comfortable with Part 3's service account and Workload Identity model, since every Compute Engine instance runs as one. This chapter sits at the "you manage everything above the hypervisor" end of the shared-responsibility spectrum from Part 1.

Table of Contents#

1. What This Chapter Covers
2. Launching a Compute Instance: The Decisions That Matter
3. Choosing Storage: Persistent Disk vs. Hyperdisk
4. OS Login: Centralized SSH Access Without Key Sprawl
5. VM Manager: Patch, Config, and OS Policy at Fleet Scale
6. Spot VMs and Custom Machine Types
7. Managed Instance Groups and Autoscaling
8. GPUs and TPUs: Attaching Accelerators
9. Remote Access and Viewing Running Inventory
10. Snapshots and Images: Backup and Golden-Image Lifecycle
11. A Full Worked Example: Meridian's Route-Optimizer Fleet
12. Real-World Scenario: The Spot VM Reclaim During a Batch Job
13. Second Real-World Scenario: The Snapshot Schedule Nobody Tested a Restore From
14. Part 4 gcloud Cheat Sheet
15. Pre-Flight Checklist: Is This Compute Design Production-Ready?
16. Common Mistakes and Interview Traps
17. Worked Practice Problems
18. Summary and What's Next

What This Chapter Covers#

🎯 By the end of this chapter, you'll be able to launch, scale, and operate a Compute Engine fleet the way a real platform team does: the right disk type, the right machine type, centralized access, fleet-wide patching, and a tested backup story, not just a VM that boots.

Launching a Compute Instance: The Decisions That Matter#

Every gcloud compute instances create call bundles several independent decisions that the exam tests separately:

gcloud compute instances create meridian-route-optimizer-1 \
  --project=meridian-freight-prod-8f2k \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --boot-disk-type=hyperdisk-balanced \
  --boot-disk-size=50GB \
  --no-address \
  --service-account=meridian-dispatcher@meridian-freight-prod-8f2k.iam.gserviceaccount.com \
  --scopes=cloud-platform \
  --metadata=enable-oslogin=TRUE

• --no-address omits an external IP entirely, the default posture for any workload that doesn't need to be reachable from the public internet (outbound access still works through Cloud NAT, covered in Part 7).
• --service-account + --scopes=cloud-platform together mean "use this specific identity, and let IAM (not legacy OAuth scopes) be the actual permission boundary," the current recommended pattern over narrowly scoping legacy access scopes.
• --metadata=enable-oslogin=TRUE turns on OS Login for this instance specifically, covered in depth below.
• Availability policy (not shown above, defaults apply): --maintenance-policy controls whether the instance live-migrates or terminates during a host maintenance event, and --restart-on-failure controls whether Compute Engine automatically restarts it after a crash.

💡 Live migration vs. Spot preemption is a distinction worth locking in now, before the Spot VM section below. A standard on-demand VM with the default MIGRATE maintenance policy survives a host maintenance event transparently, Google moves it to different physical hardware without the guest OS or workload ever noticing an interruption. A Spot VM gets no such treatment: it can be reclaimed outright, with only a short notice window, whenever Google needs the capacity back. The two mechanisms solve unrelated problems (routine hardware maintenance vs. spare-capacity reclamation) and confusing them is a common early misunderstanding of what Spot's discount is actually trading away.

Choosing Storage: Persistent Disk vs. Hyperdisk#

Hyperdisk's key architectural difference is decoupling capacity from performance: instead of IOPS scaling automatically with disk size (Persistent Disk's model), you provision capacity, IOPS, and throughput as three independent dials.

Caption: Hyperdisk Extreme sits alone in the high-IOPS corner for latency-sensitive databases, while Hyperdisk Throughput trades IOPS for raw sequential bandwidth, exactly the profile a log-ingestion or large sequential-scan workload needs instead.

OS Login: Centralized SSH Access Without Key Sprawl#

OS Login ties SSH access to a user's actual Google identity and IAM role, instead of the older pattern of manually distributing public SSH keys into each instance's metadata. With OS Login enabled, granting or revoking someone's SSH access to an entire project is a single IAM binding change (roles/compute.osLogin or roles/compute.osAdminLogin), not a per-instance metadata edit that has to be repeated (and remembered) across every VM the person should no longer reach.

⚙️ OS Login also propagates Linux POSIX account details (UID, GID, home directory) from Cloud Identity, meaning the same user gets a consistent UID across every OS Login-enabled instance in the project, which matters for anything relying on file ownership being consistent across a fleet.

VM Manager: Patch, Config, and OS Policy at Fleet Scale#

VM Manager is Compute Engine's fleet-wide operations suite, three sub-tools under one umbrella:

VM Manager answers the exam-relevant question "how do you patch 200 VMs without SSHing into each one," and OS Policy Assignment answers "how do you guarantee every VM in this fleet has the same baseline configuration, continuously, not just at creation time."

Spot VMs and Custom Machine Types#

Spot VMs are spare Compute Engine capacity offered at a steep discount (typically 60 to 91% off on-demand pricing), reclaimable by Google with only a short notice window (currently 30 seconds) when that capacity is needed elsewhere. They're the direct GCP equivalent of AWS Spot Instances, and the exam expects you to recognize the fit: batch processing, fault-tolerant distributed computation, and CI/CD build workers, never a workload that can't tolerate an abrupt, short-notice termination.

Custom machine types let you specify an exact vCPU and memory combination instead of choosing from Google's predefined shapes (n2-standard-4, n2-highmem-8), avoiding the cost of over-provisioning memory or CPU for a workload with an unusual ratio between the two. Managed instance groups increasingly support instance flexibility, letting a single MIG span several machine type or Spot/on-demand combinations, automatically favoring whichever configuration currently has the lowest observed reclaim rate, meaningfully improving Spot workload resilience without any change to the workload itself.

Managed Instance Groups and Autoscaling#

A Managed Instance Group (MIG) creates and maintains a fleet of identical VMs from a single instance template, automatically replacing any instance that fails a health check and, when an autoscaling policy is attached, adding or removing instances based on load signals (CPU utilization, a Cloud Monitoring custom metric, or HTTP load balancer request rate).

Caption: the MIG's healing behavior (bottom path) and its scaling behavior (top path) are independent mechanisms working off the same underlying instance template, which is why editing the template alone never changes already-running instances, a rolling update has to be triggered explicitly.

⚠️ Editing an instance template does not touch instances the MIG already created. This is a frequent early-career surprise: an engineer updates the template's machine type, expecting existing VMs to reflect the change, and nothing happens until a rolling update is explicitly triggered (gcloud compute instance-groups managed rolling-action start-update), which replaces instances gradually according to a configured max-surge/max-unavailable policy.

GPUs and TPUs: Attaching Accelerators#

GPUs attach to standard Compute Engine VMs for workloads needing general-purpose parallel compute, most commonly ML training/inference and specialized rendering. TPUs (Tensor Processing Units) are Google's own custom silicon, purpose-built for large-scale ML training and inference, generally outperforming GPUs specifically on the matrix-multiplication-heavy workloads TPUs were designed around, at the cost of being a narrower fit outside that workload shape.

Choose a GPU when your framework or workload doesn't specifically target TPU-optimized paths, or you need broad compatibility. Choose a TPU when you're training or serving a large model on a framework with mature TPU support and the workload's compute pattern matches what TPUs are built for.

Remote Access and Viewing Running Inventory#

Beyond OS Login-gated SSH, gcloud compute instances list --project=PROJECT_ID (optionally --filter="status=RUNNING") is the baseline inventory command, and the Cloud Console's VM instances page provides the same view with quick links to serial console output, useful for debugging an instance that never completes boot. The serial port output (gcloud compute instances get-serial-port-output) is the tool of last resort when SSH itself isn't reachable, since it reads the VM's console output directly through the hypervisor, independent of the guest OS's network stack.

Snapshots and Images: Backup and Golden-Image Lifecycle#

Snapshots are incremental, point-in-time backups of a persistent disk's contents; images are bootable disk templates used to create new instances. The exam-relevant distinction: a snapshot restores data, an image creates new instances, and you can go from one to the other (create an image from a snapshot, or a snapshot from a disk on a running instance) but they solve different problems.

# Schedule automated, incremental snapshots
gcloud compute resource-policies create snapshot-schedule daily-backup \
  --project=meridian-freight-prod-8f2k \
  --region=us-central1 \
  --max-retention-days=30 \
  --daily-schedule="03:00"

gcloud compute disks add-resource-policies meridian-route-optimizer-1 \
  --resource-policies=daily-backup \
  --zone=us-central1-a

# Build a golden image from a configured, tested instance
gcloud compute images create meridian-golden-debian-12 \
  --source-disk=meridian-golden-source \
  --source-disk-zone=us-central1-a \
  --family=meridian-app-images

A Full Worked Example: Meridian's Route-Optimizer Fleet#

# 1. Instance template using Hyperdisk Balanced and no external IP
gcloud compute instance-templates create route-optimizer-template-v3 \
  --machine-type=n2-standard-4 \
  --boot-disk-type=hyperdisk-balanced \
  --no-address \
  --service-account=meridian-dispatcher@meridian-freight-prod-8f2k.iam.gserviceaccount.com \
  --metadata=enable-oslogin=TRUE

# 2. A MIG with instance flexibility across Spot and on-demand
gcloud compute instance-groups managed create route-optimizer-mig \
  --template=route-optimizer-template-v3 \
  --size=3 \
  --zone=us-central1-a

# 3. Autoscale on CPU, with a defined min/max
gcloud compute instance-groups managed set-autoscaling route-optimizer-mig \
  --zone=us-central1-a \
  --max-num-replicas=10 \
  --min-num-replicas=3 \
  --target-cpu-utilization=0.6

# 4. Attach the tested daily snapshot schedule from above
gcloud compute disks add-resource-policies route-optimizer-mig-disk \
  --resource-policies=daily-backup \
  --zone=us-central1-a

Real-World Scenario: The Spot VM Reclaim During a Batch Job#

Meridian's Data Science team moved their nightly route-optimization batch job onto Spot VMs to cut costs, correctly judging the workload as fault-tolerant since each optimization run was idempotent and checkpointed every five minutes. Three weeks in, a Spot reclaim hit mid-run during a particularly large batch, and the job resumed cleanly from its last checkpoint exactly as designed, adding twelve minutes to that night's run. The team's own retrospective called this a non-event, not an incident, specifically because the workload's design had matched Spot's actual failure profile (short-notice, infrequent termination) from the start, rather than being adapted to Spot after the fact.

Second Real-World Scenario: The Snapshot Schedule Nobody Tested a Restore From#

(See the "From the Trenches" callout above for the full account: this is the same incident, restated here because it's exactly the kind of end-to-end, consequence-bearing scenario worth having in view when designing any backup strategy in this chapter's pre-flight checklist below.) The lesson generalizes past disks specifically: any backup mechanism that has never been used in a real restore is an unverified assumption, not a working safety net, whether that's a Compute Engine snapshot, a database backup (Part 6), or a Terraform state backup (Part 2).

Part 4 gcloud Cheat Sheet#

Pre-Flight Checklist: Is This Compute Design Production-Ready?#

• Boot and data disks use Hyperdisk (not legacy Persistent Disk) unless a specific reason favors otherwise
• OS Login is enabled project-wide; no instance relies on manually managed SSH keys in metadata
• Every workload on Spot VMs has been deliberately assessed as fault-tolerant, not moved there purely for the discount
• Every MIG has a health check and an autoscaling policy matched to a real load signal, not just a static size
• A snapshot schedule exists, and someone has actually performed and verified a restore from it in the last quarter
• Instance service accounts are purpose-scoped per Part 3, never the legacy-permissive default Compute Engine service account

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian's platform team updates a MIG's instance template to use a larger machine type, expecting the change to take effect immediately. A week later, the existing instances are still running the old, smaller machine type. What happened, and what's the fix?

Answer: Updating an instance template only affects instances created after the update; it never modifies instances the MIG already created. The fix is to explicitly trigger a rolling update (gcloud compute instance-groups managed rolling-action start-update), which replaces existing instances gradually according to the configured max-surge/max-unavailable settings, applying the new template to the fleet in a controlled way rather than all at once.

Problem 2: A batch analytics job that takes six hours to complete, has no checkpointing, and must produce a result by a hard morning deadline is proposed for Spot VMs to save cost. Is this a good fit, and why or why not?

Answer: This is a poor fit for Spot VMs. Without checkpointing, a mid-run reclaim (which can happen with only 30 seconds notice) forces the entire six-hour job to restart from scratch, risking the hard deadline. Spot VMs are appropriate for workloads that are either short enough that a restart is cheap, or checkpointed so a reclaim only costs the time since the last checkpoint; this job satisfies neither condition, so on-demand (or a fault-tolerant redesign with checkpointing) is the right call instead.

Problem 3: After a disk corruption event, Meridian discovers their year-long "successful" daily snapshot schedule had actually been backing up an empty placeholder disk for the last five months, following an undetected machine-type migration. What single practice would have caught this months earlier?

Answer: A recurring, scheduled test restore, verified against a known checksum of the expected data, performed on some regular cadence (quarterly is a reasonable default) rather than relying solely on the snapshot job's own "completed successfully" status. A snapshot job succeeding only confirms that some data was written to the snapshot; it says nothing about whether that data is the data you actually need, which only a real restore attempt can verify.

Summary and What's Next#

This chapter covered Compute Engine as the "you manage everything" end of GCP's compute spectrum: disk choice (with Hyperdisk now the forward-looking default over Persistent Disk), OS Login and VM Manager for fleet-wide access and configuration control, Spot VMs and custom machine types for cost optimization, managed instance groups and autoscaling for resilience and elasticity, GPU/TPU accelerator selection, and a backup story that's only real once it's been tested with an actual restore.

Part 5 moves along the shared-responsibility spectrum toward "Google manages more": GKE and serverless compute, including the newest addition to this exam domain, deploying and managing agents on the Gemini Enterprise Agent Platform's Agent Runtime.