Google ACE: Compute Engine and Virtual Machine Operations — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Compute Engine provides flexible, high-performance virtual machines and orchestration primitives to run general-purpose and specialized workloads. Operational excellence on Compute Engine means selecting the right machine family and disk, shaping instance lifecycle with templates and instance groups, establishing robust autohealing and autoscaling, hardening access paths, and preparing for failure modes with repeatable recovery procedures. This section explains design choices, trade-offs, and operational patterns that minimize toil and maximize reliability and cost efficiency.

Machine Types, Sizing, and Instance Lifecycle

Machine families

General-purpose: E2 (cost-optimized), N2 (balanced), N2D (AMD-based), Tau T2D/T2A (high price-performance for scale-out), suitable for most workloads.
Compute-optimized: C3 for CPU-bound tasks; choose when you need high per-core performance.
Memory-optimized: M-series for in-memory databases and analytics.
GPUs and accelerators: Attach to supported families when you need CUDA or ML acceleration; ensure driver initialization is captured in startup processes.

Custom machine types

Use custom vCPU and memory to right-size workloads and reduce waste, especially for asymmetric needs (e.g., memory-heavy but moderate CPU).
For CPU-bound services, favor higher vCPU counts; for memory-bound, increase RAM and ensure garbage collectors and caches are tuned.
Watch for licensing models tied to core count; custom types help avoid unnecessary licensed cores.

Workload sizing

Start from resource profiles measured in development or prior environments: CPU utilization at P95, memory high-water mark, disk throughput/IOPS, network bandwidth.
For bursty traffic, plan headroom or use autoscaling; for steady-state, target 60–70% utilization at peak to balance cost and resilience.
Evaluate Spot VMs (preemptible) for batch and fault-tolerant jobs; they can be terminated at any time, so design with checkpointing and retry.

Instance lifecycle resources

VM instances: The atomic compute resource. Use labels and consistent naming to drive automation.
Instance templates: Immutable blueprints capturing machine type, disks, service accounts, metadata, and startup scripts; they are the basis for managed instance groups and ensure repeatable deployments.
Managed instance groups (MIGs): Provide declarative size, autoscaling, autohealing, rolling updates, regional (multi-zone) placement, and per-instance configuration. Favor MIGs for stateless and stateful patterns (stateful MIGs preserve selected disks/IPs).
Unmanaged instance groups: Simple collections for load balancing legacy sets; lack autoscaling/autohealing. Use only when you need to register independently managed VMs.

Availability, Autoscaling, and Maintenance

Autoscaling

Signals: CPU utilization, HTTP load balancer requests per second per instance, Cloud Monitoring metrics, and queue depth. Pick a signal tightly correlated with saturation; CPU is a good baseline for homogeneous CPU-bound workloads.
Cooldowns and stabilization: Configure to prevent thrashing. If your app takes minutes to warm up, increase MIG initial delay and set appropriate autoscaling cooldown.
Exact-one patterns: To force exactly one VM, set autoscaling min=1 and max=1 on a MIG. This preserves health while enabling autohealing.

Autohealing and health checks

Health checks: Use HTTP(S) checks for application liveness; TCP only validates socket acceptance. Implement a health endpoint that exercises critical dependencies.
Thresholds and intervals: Tune check-interval and thresholds to detect failure quickly without false positives.
Initial delay: Set the MIG autohealing initial delay long enough for startup and warm-up to avoid premature replacements of healthy instances coming online.
Failure modes: Misconfigured health endpoints and too-short initial delays cause flapping and overprovisioning.

Regional MIGs and placement

Regional MIGs distribute instances across multiple zones in a region, providing zone failure tolerance. Choose the number of target replicas per zone based on capacity planning.
Use per-instance configs and stateful policies when preserving disks or IPs is required; understand that replacing VMs can be slower due to state reconciliation.

Maintenance, live migration, and reservations

Live migration: Default for most VMs; instances are moved during host maintenance without a reboot. For workloads that cannot tolerate migration (e.g., latency-sensitive HFT), set maintenance policy to terminate and rely on autohealing.
Host maintenance windows are transparent with live migration but still generate events; monitor and test.
Reservations: Create zonal reservations to guarantee capacity for critical launches or strict SLOs. Apply “specific” or “any” reservation consumption based on your governance. Reservations are capacity guarantees; pair with committed use discounts for cost planning.

Storage, Images, and Performance

Persistent disks

Types: Standard (HDD) for sequential throughput at low cost; Balanced (pd-balanced) for general-purpose; SSD (pd-ssd) for high IOPS/low latency; Extreme (pd-extreme) for provisioned IOPS and throughput at high performance tiers. Regional PDs provide synchronous replication across zones for increased availability.
Performance scales with disk size for standard, balanced, and SSD; pre-size to meet peak IOPS/throughput or use Extreme to provision explicitly.
Multi-attach read-only allows sharing datasets across many VMs; coordinate access and caching layers accordingly.

Local SSD

Ephemeral, attached directly to the host, very high IOPS/low latency. Data is lost on stop/terminate/migrate. Use for scratch, caches, and replicated data layers. Ensure application-level replication or checkpoints.

Snapshots and images

Snapshots are incremental, point-in-time backups of persistent disks; schedule with Resource Manager or gcloud to meet RPO. Cross-region storage supports DR.
Images capture boot disks plus configuration. Maintain a hardened, patch-managed image pipeline. Validate guest agents (for logging/monitoring) within your golden images.
Restore patterns: For rapid recovery, keep small base images and configure the rest through startup scripts or cloud-init; this reduces drift and accelerates updates.

Disk choices: trade-offs and failure modes

Underprovisioned disks throttle application throughput; overprovisioning wastes cost. Measure actual I/O characteristics and pick the smallest disk meeting peak needs with margin.
For databases, consider regional PDs and pd-ssd/pd-extreme; validate fsync behavior and queue depths. Avoid local SSD for durable state unless replicated.

Access, Security, Networking, and Specialized Workloads

Linux and Windows administration

Linux SSH: Prefer OS Login to centralize SSH authorization and attribute access to identities. Grant compute.osLogin or compute.osAdminLogin to groups, not individuals.
Windows RDP: Set Windows credentials in the console or via gcloud; ensure firewall rules allow TCP 3389 only from trusted IPs. Use IAP TCP forwarding to avoid public exposure.
Serial console: Enable as a break-glass path; use gcloud compute connect-to-serial-port for boot debugging. Restrict with IAM and audit access.

SSH, OS Login, and key management

Enable OS Login at project or instance level with metadata enable-oslogin=TRUE. Users add their SSH public key to their Google account; IAM controls role-based access.
For sudo/root, use compute.osAdminLogin. Disable project-wide SSH keys if using OS Login to prevent drift.

Metadata, startup scripts, and cloud-init

Metadata server provides instance/project data and service account tokens. Use only well-scoped tokens; never hardcode secrets.
Startup scripts and cloud-init: Bootstrap agents, fetch configs, and register services. Make scripts idempotent and write logs to serial console for diagnostics.
Per-instance metadata can override template settings; use carefully to avoid configuration skew.

Service accounts and scopes

Assign a dedicated service account per workload with least-privilege IAM roles on required resources (e.g., storage.objectCreator on a specific bucket).
Prefer broad Cloud API scopes only when IAM tightly controls access; otherwise restrict scopes to minimum APIs.

Networking and addresses

NICs can have internal-only or external IPs. Prefer private VMs with Cloud NAT or IAP for outbound and admin access.
Reserve static internal IPs for stable endpoints like license servers; avoid depending on ephemeral addresses.
External HTTP(S) Load Balancing terminates TLS at the edge; use managed certificates and health checks to backend MIGs. Keep backend readiness aligned with health check and MIG initial delay.

Specialized workloads and isolation

Shielded VMs: Secure boot, vTPM, and integrity monitoring mitigate rootkits; enable by default unless incompatible drivers require otherwise.
Confidential VMs: Memory encryption with AMD SEV protects data-in-use; generally minimal performance overhead but validate for latency-sensitive apps.
Sole-tenant nodes: Dedicated physical hosts for compliance, noisy-neighbor isolation, and license affinity. Plan for capacity fragmentation and higher cost.

Troubleshooting and Recovery Operations

Common diagnostics

Connectivity: Verify firewall rules, service account permissions, and routes. Use Network Intelligence Center connectivity tests.
Boot issues: Inspect serial console logs, take a screenshot, and check startup script output. Temporarily disable secure boot if unsigned drivers block boot, then remediate.
Access lockout: For SSH issues with OS Login, confirm IAM roles and that keys exist on user accounts; use serial console to add a user as break-glass.
Disk corruption: Detach the boot disk, attach to a rescue VM, repair filesystems, rotate credentials, and capture an image after remediation.

MIG and load balancer behaviors

Overprovisioning: If instances need long warm-up, increase MIG initial delay and autoscaler cooldown; otherwise you may scale out due to 4xx/5xx while the app is still initializing.
Autohealing loops: Confirm health endpoint semantics and dependency readiness; stagger startup dependencies or add retries.

Recovery patterns

Recreate instance from template or image; immutable patterns reduce MTTR.
Restore data from the latest successful snapshot; validate RPO/RTO against business requirements.
For regional failures, fail over to a different zone or region using regional MIGs and cross-region snapshot replication.

Operational safeguards

Reservations for critical capacity; use monitoring-based alerting on reservation consumption and quota.
Audit and logging: Enable admin activity and data access logs for critical services. Attribute access via OS Login and service accounts.

Short examples

Reserve a static internal IP: gcloud compute addresses create lic-ip –region=REGION –subnet=SUBNET –addresses=10.0.3.21
Enable OS Login at project level: gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
Create an HTTP health check and attach to a MIG with autohealing: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –healthy-threshold=1 –unhealthy-threshold=3 gcloud compute instance-groups managed set-autohealing my-mig –health-check=app-hc –initial-delay=200

Practical Problem Scenario

Northwind Analytics runs a latency-sensitive API on Compute Engine. Incidents show frequent overprovisioning during deployments, occasional SSH access confusion among administrators, and a licensed telemetry server that must remain reachable at 10.0.3.21. The goal is to stabilize scaling, harden access, and ensure the license endpoint is stable.

Approach

Create an instance template with right-sized custom machine type and startup bootstrapping

Rationale: The template enforces immutability. A custom 6 vCPU/20 GB RAM shape matches measured P95 CPU and memory while avoiding excess cores that increase licensing costs. A startup script registers the API with the load balancer only after health checks pass, reducing warm-up impact.

Deploy a regional managed instance group behind an external HTTP(S) Load Balancer

Rationale: A regional MIG spreads instances across zones for zone failure tolerance. The HTTP(S) load balancer terminates TLS at the edge and performs per-instance health checks, keeping traffic only on ready backends.

Configure autoscaling on CPU with cooldown and autohealing with a realistic initial delay

Rationale: CPU is strongly correlated with this API’s saturation. A 90-second cooldown prevents thrash on transient spikes. A 200-second initial delay aligns with container warm-up and JIT, preventing the autoscaler from interpreting cold starts as capacity shortfall.

Tune the health check and add an application-level /healthz

Rationale: An HTTP health check that validates dependencies (cache, DB connectivity) detects gray failures. Using 10-second intervals and 3 unhealthy thresholds balances detection speed and false positive risk.

Enable OS Login and grant admin access to an IAM group

Rationale: OS Login centralizes SSH authorization and attribution. Admins add their SSH public keys to their Google accounts; granting compute.osAdminLogin to the on-call group provides sudo while preserving audit trails. This removes per-VM key drift.

Reserve the license server’s static internal IP and attach it to a small, dedicated VM

Rationale: Reserving 10.0.3.21 guarantees the address is available and prevents accidental reuse. Assign it to the license VM’s NIC so dependent apps require no configuration changes. Scope firewall rules to only permitted source subnets.

Assign a dedicated service account to the API template with least-privilege IAM

Rationale: Principle of least privilege reduces blast radius. The service account is granted only the roles needed (e.g., read access to specific secrets and Pub/Sub topics). Using a template ensures all instances inherit the correct identity.

Harden instances with Shielded VM and enforce serial console break-glass

Rationale: Secure Boot and integrity monitoring mitigate kernel/bootloader tampering. Restrict serial console access with IAM and log access for audits; keep it for recovery if SSH fails.

Implement snapshot schedules for stateful disks and test restore

Rationale: Although the API is stateless, build a snapshot schedule for the license server and any configuration disks to meet RPO. Periodic restore tests validate tooling and runbooks.

Validate and deploy

Rationale: Blue/green or canary updates with the MIG’s rolling update settings reduce risk. Monitoring dashboards confirm stabilization of instance counts during deploys, improved admin access attribution, and uninterrupted reachability of 10.0.3.21.

← Resource Hierarchy · All domains · Containers →

Practice these questions → · Timed practice on ExamRoll.io →