ExamFinch.com My Study

Study guide

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

Practice this exam

Google Cloud Associate Cloud Engineer ACE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan

2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity

2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups

3 Chapter 3: APIs, Quotas & Billing Configuration

3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts

4 Chapter 4: Planning Compute & Storage Resources

4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types

5 Chapter 5: Planning Network Resources

5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard

6 Chapter 6: Deploying Compute Engine Workloads

6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration

7 Chapter 7: Deploying Google Kubernetes Engine Workloads

7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE

8 Chapter 8: Deploying Serverless & Event-Driven Applications

8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

9 Chapter 9: Deploying Data Solutions

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud

10 Chapter 10: Deploying Networking Resources & Infrastructure as Code

10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

11 Chapter 11: Managing Compute Engine & GKE in Production

11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE

12 Chapter 12: Managing Cloud Run, Storage & Database Operations

12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)

13 Chapter 13: Networking Operations, Monitoring & Logging

13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

14 Chapter 14: IAM Policies & Role Types

14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles

15 Chapter 15: Service Accounts & Security Configuration

15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials

16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy

16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist

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

Key Takeaways Explain This Topic AI

Hyperdisk Balanced supports up to 160,000 IOPS and 2,400 MiB/s of independently provisioned throughput on a single volume

Regional Persistent Disks synchronously replicate across two zones and cost roughly double a zonal disk of the same type

Spot VMs, preemptible VMs, and GPU-attached instances cannot live-migrate and must use onHostMaintenance=TERMINATE

Instance-level metadata with block-project-ssh-keys=TRUE overrides project-wide SSH keys for that instance only

Custom machine types let you set an exact vCPU-to-memory ratio when no predefined machine type fits the workload

Last updated: July 2026

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:

  • Family Examples Best For
  • General-purpose E2, N4, N2, N2D, N1 Web servers, dev/test, most everyday workloads
  • Compute-optimized C3, C3D, C4, C4A High-performance computing, gaming servers, ad serving
  • Memory-optimized M1, M2, M3 In-memory databases (SAP HANA), large caches
  • Accelerator-optimized A2, A3, G2 ML training/inference, GPU-heavy rendering

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).

  • Disk Type Performance Profile Typical Use
  • pd-standard HDD-backed, lowest cost Infrequent access, large sequential I/O
  • pd-balanced Default SSD-backed General-purpose boot and data disks
  • pd-ssd Higher IOPS SSD Databases, latency-sensitive apps
  • pd-extreme Provisioned IOPS, no throughput cap Very high-performance databases

Hyperdisk Balanced Independently provisioned IOPS + throughput, up to 160,000 IOPS / 2,400 MiB/s Best overall price/performance for most modern workloads

  • Hyperdisk Extreme Provisioned IOPS drives throughput Mission-critical, latency-sensitive databases
  • Hyperdisk Throughput Provisioned throughput drives IOPS Big data, analytics, cost-efficient bulk I/O
  • Hyperdisk ML Up to 2 TiB/s throughput Reading large, immutable ML training/inference datasets

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.