Study guide
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups
Google Professional Cloud Architect Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Strategy & Case Study Methodology
1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions
2 Chapter 2: Designing for Business Requirements
2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning
3 Chapter 3: Designing for Technical Requirements & Availability
3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction
4 Chapter 4: Compute Selection & Workload Architecture
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
5 Chapter 5: Storage, Database & Data Warehouse Architecture
5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery
6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing
6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS
7 Chapter 7: Identity, Access & Resource Governance
7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance
8 Chapter 8: Security Architecture, Data Protection & Compliance
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center
9 Chapter 9: DevOps, Automation & Infrastructure as Code
9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators
10 Chapter 10: Site Reliability Engineering & Operations Excellence
10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting
11 Chapter 11: Data Pipelines, Integration & Modernization
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options
12 Chapter 12: Well-Architected Framework & Official Case Study Solutions
12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive
13 Chapter 13: AI, Machine Learning & Generative AI Architecture
13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups
Key Takeaways Explain This Topic AI
Compute Engine machine families are architected for distinct workload profiles: General-purpose (E2 cost-optimized/burstable, N2/N4 balanced, C3/C4 high-performance with Titanium offload), Compute-optimized (C2/C2D for HPC/gaming), Memory-optimized (M1/M2/M3 for ultra-large SAP HANA and in-memory databases), and Accelerator-optimized (A2/A3/G2 for AI/ML training and inference).
Custom machine types allow precise tailoring of vCPU and memory ratios to optimize compute spend and reduce core-based third-party software licensing fees (e.g., Microsoft SQL Server or Oracle).
Regional Managed Instance Groups (MIGs) distribute instances evenly across three zones in a region to deliver high availability and resilience against single-zone failures, while Stateful MIGs preserve persistent disks, static IP addresses, and custom metadata across VM restarts, auto-healing, and rolling updates.
MIG rolling updates offer Proactive and Opportunistic update modes, controlled precisely by maxSurge (additional instances created above target) and maxUnavailable (instances taken offline during deployment) to maintain strict availability SLAs.
Spot VMs provide up to 60–91% cost savings for fault-tolerant workloads with a 30-second ACPI shutdown notice, whereas Sole-Tenant nodes provide dedicated physical server isolation for strict regulatory compliance, BYOL licensing, and custom host maintenance policies.
Last updated: August 2026
Compute Engine Architecture, Sizing & Managed Instance Groups
Architectural Objective: Compute Engine provides flexible, enterprise-grade virtual machines running on Google's global infrastructure. A Google Professional Cloud Architect must master workload-specific machine family selection, cost-optimized rightsizing, instance lifecycle management, and high-availability patterns using Regional and Stateful Managed Instance Groups (MIGs).
Compute Engine Machine Families & Architectural Sizing
Selecting the optimal machine family is the foundation of cost and performance optimization in Compute Engine. Google Cloud categorizes machine types into five primary architectural families, each engineered for distinct workload characteristics: +---------------------------------------------------------------------------------------------------+
- | COMPUTE ENGINE MACHINE FAMILY TAXONOMY |
- +---------------------------------------------------------------------------------------------------+
- | 1. GENERAL-PURPOSE | E2 (Cost/Burstable) | N2/N2D/N4 (Balanced) | C3/C4 (Titanium DPU / High IOPS) |
- | 2. COMPUTE-OPTIMIZED | C2 / C2D (High Single-Thread Performance, HPC, EDA, Gaming Servers) |
- | 3. MEMORY-OPTIMIZED | M1 / M2 / M3 (In-Memory Databases, SAP HANA, Large Scale Analytics) |
- | 4. ACCELERATOR-OPTIMIZED| A2 (NVIDIA A100) | A3 (NVIDIA H100) | G2 (NVIDIA L4 AI Inference / Media)|
- | 5. STORAGE-OPTIMIZED | Z3 (Dense High-Throughput NVMe Local SSDs, Real-Time Analytics) |
- +---------------------------------------------------------------------------------------------------+
- Detailed Machine Family Comparison
Machine Family Series CPU Platform Memory-to-vCPU Ratio Optimal Workload Scenarios
General-Purpose E2 Intel Xeon / AMD EPYC 0.5 GB to 8 GB per vCPU (Dynamic/Shared) Cost-sensitive web backends, dev/test environments, microservices, light batch jobs.
General-Purpose N2 / N2D Intel Cascade/Ice Lake, AMD Milan/Genoa 1 GB to 8 GB per vCPU (Customizable) General enterprise workloads, web/application servers, medium databases, cache layers.
General-Purpose C3 / C4 Intel Emerald Rapids with Titanium DPU 2 GB to 8 GB per vCPU High-concurrency enterprise apps, dense container hosting, high-IOPS storage workloads.
Compute-Optimized C2 / C2D Intel Cascade Lake / AMD Milan (High Turbo) 4 GB per vCPU (Fixed 1:4) High-Performance Computing (HPC), electronic design automation (EDA), AAA gaming engines, video encoding.
Memory-Optimized M1 / M2 / M3 Intel Xeon Scalable (Up to 12 TB RAM) Up to 28 GB per vCPU (1:14 to 1:28) Ultra-large in-memory databases (SAP HANA certified), massive Redis clusters, in-memory data fabrics.
Accelerator-Optimized A2 / A3 / G2 NVIDIA A100 / H100 / L4 Tensor Core GPUs Scaled GPU-to-CPU host memory LLM pre-training, fine-tuning, generative AI inference, computer vision, 3D graphics virtualization.
Custom Machine Types
When a workload requires a non-standard memory-to-core ratio (for example, a memory-intensive caching daemon requiring 4 vCPUs and 32 GB RAM), provisioning a standard n2-standard-8 (8 vCPUs, 32 GB RAM) results in paying for 4 unutilized vCPUs. Compute Engine allows architects to define Custom Machine Types ( custom-vCPUs-RAM ) in the N1, N2, and N2D series.
Licensing Optimization: Custom machine types are especially valuable for third-party commercial software licensed on a per-core basis (such as Microsoft SQL Server or Oracle Database). By provisioning an n2-custom-4-32768 instead of an n2-standard-8 , the enterprise cuts software licensing fees in half while maintaining the necessary 32 GB memory footprint.
Extended Memory: If a machine requires more than 8 GB of RAM per vCPU, architects can attach extended memory up to maximum platform thresholds without adding more vCPUs.
Instance Templates & Configuration Overrides
Instance Templates: Immutable, reusable global resources that define machine type, boot image, persistent disk attachments, network interfaces, subnets, service accounts, and startup scripts. Because templates are immutable, updating a template requires creating a new version ( instance-template-v2 ) and updating the Managed Instance Group target.
Configuration Overrides (All-Instances vs. Per-Instance):
All-Instances Configuration: Applies baseline metadata, labels, and service accounts across the entire group.
Per-Instance Configurations (PICs): Allows architects to attach specific persistent disks, reserve static internal/external IP addresses, or apply unique metadata keys to individual named instances within an otherwise uniform Managed Instance Group without breaking MIG membership.
Managed Instance Groups (MIGs): Zonal vs. Regional Architectures
A Managed Instance Group (MIG) pools identical Compute Engine instances created from a shared instance template, providing automated provisioning, auto-healing, auto-scaling, and rolling updates. ZONAL MANAGED INSTANCE GROUP REGIONAL MANAGED INSTANCE GROUP (HIGH AVAILABILITY)
- ┌──────────────────────────────────────┐ ┌────────────────────────────────────────────────────────┐
- │ Region: us-central1 │ │ Region: us-central1 │
- │ ┌────────────────────────────────┐ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
- │ │ Zone: us-central1-a │ │ │ │ Zone: -a │ │ Zone: -b │ │ Zone: -c │ │
- │ │ [VM-1] [VM-2] [VM-3] [VM-4]│ │ │ │ [VM-1] │ │ [VM-2] │ │ [VM-3] │ │
- │ └────────────────────────────────┘ │ │ │ [VM-4] │ │ [VM-5] │ │ [VM-6] │ │
- │ [!] Single Zone Outage = Total Down │ │ └──────────────┘ └──────────────┘ └──────────────┘ │
- └──────────────────────────────────────┘ │ [OK] Zone Outage: Traffic shifts across healthy zones │
- └────────────────────────────────────────────────────────┘
- Architectural Comparison: Zonal vs. Regional MIGs
Architectural Attribute Zonal MIG Regional MIG
Geographic Scope Confined to a single zone (e.g., us-east1-b ). Spans multiple zones (typically 3) within a region.
Failure Domain Vulnerable to physical datacenter or zonal network disruptions. Survives complete zonal outages; automatically redistributes capacity.
Capacity Distribution Single pool. Even distribution across zones (default) or ANY_SINGLE_ZONE / balanced.
Cross-Zone Network Cost Zero cross-zone traffic between members. Standard inter-zone egress pricing ($0.01/GB) for inter-node communication.
Target Use Case Low-latency HPC clusters, single-zone stateful nodes. Production web tiers, API gateways, resilient microservices backends.
Auto-Healing and Health Checks
MIGs integrate with Google Cloud Application-Level Health Checks. When an instance fails health check probes (e.g., consecutive HTTP 500 responses or TCP connection timeouts on /healthz ):
The health check marks the instance UNHEALTHY .
The MIG controller gracefully shuts down and recreates the VM in place, preserving its configuration and IP addressing if configured as stateful.
Initial Delay (Cool-Down Period): Architects must configure an adequate initialDelaySec (e.g., 60–180 seconds). This instructs the auto-healer to ignore health check failures while the VM is completing OS boot, pulling container images, and running startup scripts, preventing infinite recreation loops.
Stateful Managed Instance Groups
While traditional MIGs are designed for stateless applications where instances can be destroyed and recreated arbitrarily ("cattle"), Stateful MIGs accommodate workloads that require persistent state, fixed identity, or localized storage across VM lifecycles. +-----------------------------------------------------------------------------------+
- | STATEFUL MIG PERSISTENCE GUARANTEES |
- +-----------------------------------------------------------------------------------+
- | 1. STATEFUL DISKS | Preserves data disks across recreation, updates, healing. |
- | 2. STATEFUL IPS | Retains static internal / external IPs on VM restart. |
- | 3. STATEFUL METADATA | Preserves unique node-specific configuration keys. |
- | 4. INSTANCE IDENTITY | Preserves stable instance names (e.g., kafka-broker-0). |
- +-----------------------------------------------------------------------------------+
- When to Deploy Stateful MIGs
Stateful Clustered Databases: Apache Cassandra nodes, Apache Kafka brokers, Elasticsearch clusters, and ZooKeeper ensembles.
Legacy Monoliths: Enterprise applications that store local configuration files or write transaction logs to a dedicated persistent disk that cannot be lost during OS updates.
Fixed Network Endpoints: Internal systems that require static private IP addresses for legacy firewall whitelist rules.
Stateful vs. Stateless Auto-Healing Behavior
Stateless MIG: When an instance becomes unhealthy, the MIG deletes the VM, wipes the root and attached disks, and boots a brand-new instance from the template.
Stateful MIG: When an instance becomes unhealthy, the MIG stops the VM, detaches the stateful persistent disk, recreates the underlying compute instance, reattaches the exact stateful disk with all existing data intact, and reassigns the same private/public IP address.
Rolling Update Strategies & Lifecycle Orchestration
Deploying new software versions or OS patches to a MIG requires updating the underlying instance template and executing a rolling update. Google Cloud provides two update operational modes: +-----------------------------------------------------------------------------------+
- | MIG ROLLING UPDATE CONFIGURATION |
- +-----------------------------------------------------------------------------------+
- | PROACTIVE UPDATE | MIG immediately replaces/updates instances automatically. |
- | OPPORTUNISTIC | MIG applies new template ONLY when instances are recreated |
- | | manually, scaled out, or replaced by auto-healing. |
- +--------------------+--------------------------------------------------------------+
- | maxSurge | Number of EXTRA instances created above target size. |
- | maxUnavailable | Number of instances that can be OFFLINE during update. |
- +-----------------------------------------------------------------------------------+
- Sizing maxSurge and maxUnavailable for Production Workloads
Deployment Objective maxSurge maxUnavailable Operational & Capacity Impact
100% Serving Capacity Guarantee 3 (or 25% ) 0 Zero-downtime, no capacity degradation. Provisions 3 new VMs first, verifies health, then terminates 3 old VMs. Requires available vCPU regional quota for the surge instances.
Strict Quota Constraints 0 2 (or 20% ) No extra quota needed. Terminates 2 old VMs first, creates 2 new VMs, verifies health. Cluster serving capacity drops to 80% during the rollout.
Maximum Rollout Speed 50% 50% Rapid deployment; replaces half the fleet at a time. Ideal for non-production environments.
Instance Lifecycle Stages
Architects must understand the state machine of Compute Engine instances:
PROVISIONING : Hardware resources (CPU, RAM, Disks) are being allocated on the physical host.
STAGING : Resources are allocated; the hypervisor is booting the kernel and initializing startup scripts.
RUNNING : The instance is actively executing; billable compute and OS licensing apply.
STOPPING : Shutdown scripts are executing; guest OS is terminating processes.
TERMINATED : VM is completely halted. vCPU/RAM are released (no compute billing); attached Persistent Disks and reserved Static IPs continue to incur standard storage/networking charges.
Spot VMs and Graceful Preemption Handling
Spot VMs are surplus Compute Engine capacity offered at 60% to 91% discounts relative to on-demand pricing. Spot VMs have no maximum runtime limit (unlike legacy 24-hour Preemptible VMs), but Google Cloud can reclaim them at any moment when capacity is required by standard on-demand customers. +-----------------------------------------------------------------------------------+
- | SPOT VM PREEMPTION SEQUENCE (30 SECONDS) |
- +-----------------------------------------------------------------------------------+
- | Google Reclaims Capacity ──> ACPI Shutdown Event Dispatched ──> Guest OS Catches |
- | Signal |
- | │ |
- | v |
- | 1. Stop accepting new tasks / unregister from queue. [ 30 SEC |
- | 2. Flush memory buffers and active transactions. COUNTDOWN ]|
- | 3. Write checkpoint state to Cloud Storage / Firestore. │ |
- | 4. Cleanly exit container / OS shutdown. v |
- | VM Terminated |
- +-----------------------------------------------------------------------------------+
- Designing Resilient Spot Workloads
30-Second ACPI Signal: When Google Cloud preempts a Spot VM, it sends an ACPI Power Off signal. The guest OS receives this event and triggers configured /etc/acpi/events handlers or standard shutdown scripts.
Graceful Teardown Script: Shutdown scripts must execute within 30 seconds . For distributed workloads (e.g., Apache Spark or rendering nodes), the script flushes intermediate calculations to Cloud Storage or commits job status back to a Cloud Pub/Sub queue.
MIG Mixed-Instance Policies: In production batch architectures, architects configure MIGs with a combination of standard on-demand instances (providing a guaranteed minimum serving floor) and Spot instances for elastic bursting.
Sole-Tenant Nodes: Enterprise Isolation, BYOL & Maintenance
Sole-Tenant Nodes are physical Google Cloud Compute Engine servers dedicated entirely to a single enterprise customer's virtual machines. They provide hardware-level physical isolation from all other cloud tenants while retaining Compute Engine APIs and elasticity. +-----------------------------------------------------------------------------------+
- | PHYSICAL SOLE-TENANT NODE SERVER (DEDICATED HOST) |
- | ┌───────────────────────────────────────────────────────────────────────────┐ |
- | │ Enterprise Tenant A Virtual Machines Only: │ |
- | │ [VM-1: Windows Server (BYOL)] [VM-2: Windows Server] [VM-3: SQL Server]│ |
- | │ - No noisy neighbors │ |
- | │ - Physical core visibility for licensing compliance │ |
- | └───────────────────────────────────────────────────────────────────────────┘ |
- +-----------------------------------------------------------------------------------+
- Primary Architectural Use Cases
Strict Regulatory Compliance & Security: Workloads in healthcare (HIPAA), government (FedRAMP High), or banking that legally mandate single-tenant physical hardware separation.
Bring Your Own License (BYOL): Enterprise software (Microsoft Windows Server, SQL Server, Red Hat Enterprise Linux) licensed per physical core, socket, or processor. Sole-tenant nodes allow enterprises to view physical core mappings to satisfy licensing audit requirements.
Host Maintenance Policies: Architects can control how Google performs physical hardware maintenance on the host:
Migrate in Group (Default): VMs automatically live-migrate to another sole-tenant node within the same node group during hardware maintenance, ensuring 100% continuous uptime.
Restart in Place: VMs shut down and restart on the same physical host once maintenance completes (required for strict software licenses tied to physical CPU IDs).
- Concrete Architectural Scenario: Clustered Messaging & Analytics Pipeline
- Scenario Profile
Workload: Enterprise Kafka cluster processing 250,000 telemetry messages/sec alongside a stateless data transformation worker fleet.
Availability SLA: 99.99% availability with zero message loss.
Budget Constraint: Maximize compute cost efficiency without risking cluster integrity.
Solution Architecture Blueprint
Kafka Broker Tier: Deployed across a Regional Stateful Managed Instance Group in us-east4 spanning zones -a , -b , and -c . Each broker is assigned a Stateful Persistent Disk (SSD) and a Stateful Static Internal IP . When an auto-healing or rolling OS update event occurs, the MIG reattaches the exact storage volume and IP, preventing Kafka partition rebalancing storms.
Worker Processing Fleet: Deployed in a Regional Stateless MIG utilizing Spot VMs with an autoscaling policy tied to the Kafka consumer group lag metric. An ACPI shutdown hook checkpoints in-flight batch state to Cloud Storage within the 30-second preemption notice window.
Licensing Compliance: Dedicated legacy database hosts are placed on a Sole-Tenant Node Group with a Migrate in Group maintenance policy to utilize existing per-core Microsoft SQL Server BYOL licenses.
Important
Exam Watch: On the Google Professional Cloud Architect exam, whenever a scenario mentions running stateful clustered systems (like Kafka, Cassandra, or Elasticsearch) on Compute Engine that require persistent disk attachments and static IPs across auto-healing cycles, choose Stateful MIGs . If the question involves minimizing licensing costs for software licensed per physical core, choose Sole-Tenant Nodes with BYOL. If a question describes batch or fault-tolerant processing with strict budget limits, choose Spot VMs with graceful shutdown handling.