6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies

Why This Topic Matters

The Associate Cloud Engineer (ACE) exam guide lists "Launching a compute instance (e.g., assign disks, availability policy, SSH keys)" as the very first bullet under Deploying and implementing a cloud solution, the single heaviest-weighted domain on the exam at 25%. This is not abstract theory -- ACE is a hands-on, scenario-based exam, and this bullet alone maps to several concrete gcloud compute instances create decisions you must get right: which machine type, which disk type and mode, how SSH access is granted, and what happens to the instance during a host maintenance event. Expect scenario questions that describe a workload (a stateless web tier, a batch job, a GPU training job) and ask you to pick the disk type, SSH mechanism, or availability policy that fits.

Choosing a Machine Type and Family

Every Compute Engine instance is built from a machine type, which bundles a vCPU count and a fixed amount of memory. Machine types are grouped into machine families tuned for different workloads:

E2 is the lowest-cost general-purpose family and the default recommendation for standard workloads where you do not need a specific CPU platform. When a predefined shape does not fit -- for example, a workload that needs 16 vCPUs but only 8 GB of RAM -- you can define a custom machine type, specifying the exact vCPU and memory combination so you stop paying for unused capacity. This is a recurring exam trap: predefined types are convenient, but the "cost-conscious, unusual ratio" scenario is the custom-machine-type signal.

Assigning Disks

Every instance needs a boot disk (built from a public image, a custom image, or a Marketplace image) and may attach additional persistent disks for data. Disk choice is tested along two axes: disk type (performance tier) and disk mode/scope (zonal vs. regional).

Beyond disk type, every persistent disk is either zonal (replicated within a single zone, cheaper, lower latency) or regional (synchronously replicated across two zones in the same region). A Regional Persistent Disk costs roughly double a zonal disk of the same type but survives a single zone outage without manual failover -- the correct answer whenever a scenario says "must tolerate a zone failure without data loss" for a disk that isn't already covered by application-level replication.

SSH Access: Metadata Keys vs. OS Login

Google Cloud offers two SSH access mechanisms, and precedence between them is a favorite exam trap (OS Login is covered in depth in section 6.3, but you must know the basic metadata mechanism here):

• Project-wide metadata SSH keys -- keys stored on the sshKeys project metadata field, valid for every instance in the project unless a specific instance blocks them.
• Instance-level metadata SSH keys -- keys attached only to one instance's metadata; an instance can also set block-project-ssh-keys=TRUE to ignore project-wide keys and accept only its own.
• OS Login -- ties SSH access to IAM identity instead of any metadata key (full detail in 6.3).

When you run gcloud compute ssh, the CLI automatically generates a key pair and propagates the public key for you -- useful for quick access, but in an enterprise fleet this is exactly the unaudited pattern OS Login is meant to replace.

Availability Policies

An instance's availability policy controls what happens when the underlying host needs maintenance or the instance stops responding. Two settings matter most for the exam:

• On-host maintenance: MIGRATE (default) live-migrates the running instance to another host with no reboot and no downtime; TERMINATE stops the instance instead. Certain instance types cannot live-migrate and must use TERMINATE: Spot VMs, preemptible VMs, GPU-attached instances, and instances on sole-tenant nodes with certain configurations.
• Automatic restart: if TRUE (default for standard VMs), Compute Engine restarts the instance automatically after a host failure or software crash; Spot and preemptible VMs cannot use automatic restart in the same way because Google may reclaim the capacity outright.
• Termination action (Spot VMs only): STOP (preserve the disk, restart later) or DELETE (discard the instance) when Google reclaims the capacity.

Worked Scenario

A team needs (1) a production PostgreSQL primary that must never silently disappear during host maintenance, and (2) a fleet of batch-rendering workers that only need to run when spare capacity is cheap. For (1): a standard VM, pd-ssd or Hyperdisk Balanced disk, onHostMaintenance=MIGRATE, automaticRestart=TRUE, and OS Login for auditable SSH. For (2): Spot VMs (provisioning-model=SPOT), onHostMaintenance=TERMINATE (required), terminationAction=STOP so partially completed work resumes, and pd-standard disks since raw throughput matters more than IOPS.