Study guide
1.3 GKE Modes and Compute Engine Trade-offs
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
1.3 GKE Modes and Compute Engine Trade-offs
Key Takeaways Explain This Topic AI
GKE Autopilot manages nodes but has workload restrictions and hardware-dependent billing.
GKE Standard offers broader node/privileged-workload configuration; arbitrary replacement kernels are not a GKE feature.
Database pools need explicit capacity controls even when frontend compute scales automatically.
Last updated: October 2026
Google Kubernetes Engine (GKE): Standard vs. Autopilot
Google Kubernetes Engine (GKE) is Google Cloud's managed Kubernetes orchestration platform. GKE provides container clustering, declarative service routing, pod autoscaling (HPA/VPA), fine-grained multi-tenancy, and hardware acceleration.
GKE Autopilot vs. GKE Standard
GKE operates under two distinct deployment modes with significantly different shared-responsibility boundaries: +-----------------------------------------------------------------------+
- | GKE Autopilot |
- | - Control Plane & Worker Nodes managed entirely by Google Cloud |
- | - Billing: Pod-based for general-purpose workloads; node-based for some hardware |
- | - Hardened: Enforces Pod Security Standards, disallows privileged pods|
- | - Zero node management: Auto-upgrades, auto-repair, auto-scaling |
- +-----------------------------------------------------------------------+
- vs
- +-----------------------------------------------------------------------+
- | GKE Standard |
- | - Control Plane managed by Google Cloud; Nodes managed by user |
- | - Billing: Billed for underlying Compute Engine VM instances |
- | - Full Control: Custom DaemonSets, privileged containers, sysctl |
- | - Node Pool Customization: Custom machine types, Local SSDs, GPUs |
- +-----------------------------------------------------------------------+
- In-Depth Comparison: Autopilot vs. Standard
Capability / Property GKE Autopilot GKE Standard
Node Management Fully automated (node pools, OS, sizing hidden) Manual or automated node pools (user configures machine families)
Pricing Metric Pod-based general-purpose pricing; some compute classes use node-based pricing Per-node Compute Engine VM pricing plus cluster management fee
Privileged Containers Restricted; selected verified partner workloads have controlled exceptions Supported (subject to cluster RBAC and Pod Security Admission)
Custom DaemonSets Restricted to non-privileged workloads Fully supported across all worker nodes
Kernel Customization Not permitted (standard GKE COS image enforced) More control over supported node images and settings; arbitrary replacement kernels are not a GKE feature
Hardware Accelerators Supported GPU/TPU configurations depend on region, availability, and compute class Broader node-pool configuration options; supported hardware and locations must be checked
Multi-tenancy Model Namespaces plus explicitly designed RBAC and network policies; namespaces alone are not a security boundary Explicit namespace/RBAC/network-policy design and dedicated node pools
When to Choose GKE over Cloud Run
Complex Inter-Service Orchestration: Workloads requiring Kubernetes CRDs (Custom Resource Definitions), operators, sidecar architectures (Envoy, OpenTelemetry, Istio), or cross-pod affinity/anti-affinity.
Stateful Workloads: Applications requiring persistent volume management across restarts ( StatefulSets , ReadWriteMany Filestore PVs, ReadWriteOnce Persistent Disks).
Custom Protocol and Port Requirements: Non-HTTP/gRPC protocols, multi-port services, or UDP-based workloads (gaming, VoIP, DNS, streaming).
DaemonSet Infrastructure Agents: Specialized host-level security agents, compliance log aggregators, or custom storage drivers requiring execution on every physical node.
Compute Engine: Infrastructure as a Service (IaaS)
Compute Engine delivers raw virtual machines hosted on Google's worldwide infrastructure. It provides maximum infrastructure control at the cost of highest operational management overhead.
Architectural Use Cases for Compute Engine
Non-Containerized Legacy Monoliths: Complex legacy enterprise applications (e.g., enterprise ERPs, legacy Microsoft Windows servers) that cannot easily be containerized or refactored into microservices.
Custom Operating System Kernels: Applications requiring specialized Linux kernel patches, proprietary kernel modules (e.g., custom SAN drivers), or specific legacy OS versions.
VM Virtualization and Separate Bare-Metal Services: Nested virtualization (running KVM inside Compute Engine VMs) ; Bare Metal Solution is a separate service for workloads such as legacy Oracle deployments, not a Compute Engine VM feature.
High-Performance Scratch Storage: Distributed storage clusters (Hadoop/HDFS, Ceph, GlusterFS) requiring raw local NVMe block devices configured as high-IOPS RAID arrays.
Management Overhead and Responsibility Matrix
Compute Engine requires teams to manage OS patching, security vulnerability remediation, VM image family baking (via Packer), startup scripts, Managed Instance Group (MIG) health checking, and custom autoscaling policies. Unlike Cloud Run and GKE Autopilot, unpatched Compute Engine VMs present persistent operational maintenance burdens.
Architectural Decision Matrix
Use this decision matrix to evaluate compute options for the Cloud Developer certification:
- Evaluation Criterion Cloud Run GKE Autopilot GKE Standard Compute Engine
- Operational Overhead Lowest (Serverless) Low (No node ops) Moderate to High Highest (Full VM ops)
- Scaling Latency Seconds (0 to 1000s) Minutes (Pod + Node) Minutes (Node autoscaling) Minutes (MIG boot)
Scale to Zero Yes (automatic) Workloads can be explicitly scaled to zero; HPA behavior depends on configuration Node pools can scale to zero where supported; cluster system capacity still matters MIG autoscaling can reach zero with supported policies; CPU-only policies have restrictions
Max Request Timeout 60 min (service requests) / 168 hr (non-GPU job tasks) Unlimited Unlimited Unlimited
Protocol Support HTTP/1, HTTP/2, gRPC, WebSockets All IP protocols (TCP/UDP) All IP protocols (TCP/UDP) All networking protocols
Hardware Accelerators GPU configurations in supported locations; check current availability GPUs and TPUs Supported accelerator configurations Supported accelerator configurations
Host configuration / node daemons No No Yes Yes
Downstream DB Protection High risk without --max-instances Controlled via replica limits Controlled via replica limits Controlled via MIG target size
- Architectural Scenarios and Exam Traps
- Scenario A: Burst-Driven Webhook Ingestion
Requirement: An e-commerce partner sends erratic webhook bursts (from 0 to 50,000 requests per minute). Maintenance overhead must be zero, and costs must reflect idle periods.
Solution: Deploy to Cloud Run . Configure --concurrency=80 and --max-instances=500 . Set --min-instances=0 to ensure scale-to-zero when no webhooks arrive.
Scenario B: Enterprise Microservices with Istio Service Mesh
Requirement: A financial platform requires 30 microservices communicating with mutual TLS (mTLS), fine-grained traffic shifting, tracing sidecars, and stateful caching databases. The DevOps team does not want to manage OS patches or node sizing.
Solution: Deploy to GKE Autopilot . Autopilot automatically manages node pools, enforces security baselines, and injects managed sidecars without requiring node maintenance.
Scenario C: High-Throughput Packet Inspection Agent
Requirement: A compliance agent must run on every cluster node with root-level access ( privileged: true ), capturing raw network interface packets across all tenant pods.
Solution: Deploy to GKE Standard using a DaemonSet . GKE Autopilot disallows privileged security contexts and direct node DaemonSet manipulation, making GKE Standard mandatory.
Scenario D: Preventing Downstream Database Overload
Exam Trap: When Cloud Run scales out to absorb thousands of concurrent client requests, it can spin up hundreds of container instances simultaneously. If each container instance opens 10 connections to an internal Cloud SQL PostgreSQL instance, the database connection pool is immediately exhausted (e.g., 500 instances * 10 connections = 5,000 connections).
Developer Mitigation:
Set --max-instances on the Cloud Run service to throttle the maximum number of simultaneous container instances.
Route database traffic through an actual connection pooler such as PgBouncer ; the Cloud SQL Auth Proxy authenticates and encrypts connections but does not pool them.
Use Direct VPC egress , or a Serverless VPC Access connector to ensure private, high-bandwidth database connectivity without public IP exposure.
Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .