Google PCA: Compute, Application Platforms and Workload Architecture — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overview

This domain covers how to select and design compute platforms on Google Cloud, how to package and deploy applications, and how to operate workloads for reliability, performance, security, and cost efficiency. It spans virtual machines, Kubernetes, serverless runtimes, load balancing, rollout strategies, stateful and specialized compute, and modernization patterns that reduce technical debt while meeting changing demand.

Compute Engine and VM-based Architectures

Compute Engine provides granular control over operating systems, networking, and machine shapes. Choose machine families based on workload characteristics:

E2: cost-optimized general purpose; good for dev/test, bursty apps.
N2/N2D: balanced price/perf for most production workloads; N2D uses AMD CPUs with strong memory bandwidth.
C2/C2D/C3: compute-optimized for CPU-bound tasks (e.g., high QPS API, batch compute).
M3: memory-optimized for large in-memory datasets (caches, in-memory analytics).
A3: GPU-optimized (NVIDIA) for training/inference; also attach GPUs to other families.
Confidential VMs (on supported CPUs) encrypt data in use with minimal code changes.

Managed instance groups (MIGs) bring elasticity and resilience:

Use Instance Templates for immutable configuration and MIGs to scale horizontally across zones.
Autoscaling policies: CPU, load balancer utilization, Cloud Monitoring metrics, or queue depth via custom metrics. Set min/max replicas and cooldown to avoid thrash under bursty loads.
Rolling updates and canaries reduce risk; keep surge and unavailable settings conservative for stateful or cold-start-heavy services.

Load balancing and health checks:

Global external HTTP(S) load balancer terminates TLS, supports URL mapping, and is the standard front end for web APIs; internal HTTP(S) LB for east–west.
Health checks must reach backends. A common failure is blocked probes causing perpetual instance restarts and traffic drop. Allow health check source ranges to backend ports with VPC firewall rules and target tags.

Example to allow HTTP health checks to a MIG:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

VM lifecycle considerations:

Use startup scripts or image metadata to bootstrap; store runtime config in Secret Manager, not baked into images.
For preemptible/Spot VMs, add a shutdown-script to drain work on termination notice.
Patch via baked images and rolling replacement to avoid configuration drift.
Persistent disk resizing is online: increase disk size, then grow the filesystem (e.g., resize2fs on ext4) with minimal downtime.

Example PD resize:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

Secure identity and observability:

Attach least-privilege service accounts to instances; do not embed static credentials.
Install the Ops Agent for Cloud Logging and Cloud Monitoring. Use Cloud Trace and Cloud Profiler to reduce tail latency and hot spots.
Export audit and metric data to BigQuery or Cloud Storage for long-term retention and analysis.

Batch and specialized compute:

Use Cloud Batch or MIGs with preemptible VMs for fault-tolerant batch to reduce cost; implement checkpointing.
Attach GPUs/TPUs where ML acceleration is needed. Use dedicated node pools or sole-tenant nodes to meet compliance/isolation requirements.
Confidential VMs protect sensitive data in memory; measure overhead versus requirements.

State considerations:

Keep application instances stateless; externalize sessions to a shared store (e.g., Memorystore, Cloud SQL) to avoid user-visible anomalies under scale.
For VM-bound state, use regional persistent disks or replicated databases; test failover paths.

Kubernetes and Container Platforms (GKE)

GKE provides a managed control plane with flexible worker node pools:

Regional clusters replicate the control plane and nodes across zones for high availability; zonal clusters concentrate resources for lower cost and latency sensitivity.
Use multiple node pools to segment workloads (e.g., general purpose, GPU, high-memory, spot). Apply taints/tolerations and affinity/anti-affinity to control placement and reduce noisy-neighbor effects.
Autoscaling layers: cluster autoscaler adds/removes nodes; Horizontal Pod Autoscaler (HPA) scales replicas on CPU/custom metrics; Vertical Pod Autoscaler (VPA) rightsizes requests. Combine HPA with cluster autoscaler for elasticity.

Workload scheduling and services:

Right-size CPU/memory requests/limits to minimize eviction risk and maximize binpacking efficiency.
Use PodDisruptionBudgets to preserve availability during upgrades.
Service types: ClusterIP (in-cluster), NodePort/LoadBalancer (north–south), and Ingress for HTTP(S) routing with the global LB. For canaries, direct traffic via separate Services/Ingress backends or a service mesh.

Upgrades and resilience:

Use surge upgrades and maxUnavailable to control churn; pin critical workloads to multiple zones and pools.
Set maintenance windows/exclusions for business-critical periods.
Validate with a pre-production environment and canary node pools before broad rollout.

Images and security:

Store container images in Artifact Registry; enable vulnerability scanning and set up binary authorization or attestations for provenance.
Use Workload Identity to map GSA to KSA for credentialless, least-privilege access to Google APIs.
Pull runtime configuration from Secret Manager via CSI driver; avoid Kubernetes Secrets for highly sensitive values unless encrypted with CMEK and RBAC is tight.

Rollouts and rollback:

Prefer Deployment rolling updates with small steps and health probes; for low-tolerance systems, use blue-green via two Deployments behind a single Service and switch labels/selector.
Always define readiness and liveness probes; misconfigured probes cause cascading restarts or blackholes during rollouts.

Serverless and Event-Driven Platforms

Google Cloud serverless abstracts infrastructure while providing strong controls over scale, security, and cost:

Cloud Run: container-native, HTTP-request or Eventarc-triggered. Scales to zero; configurable concurrency; traffic splitting by revision for canary and rollback. Set min instances to reduce cold starts for latency-sensitive endpoints. Integrate with VPC via Serverless VPC Access for private egress.
App Engine: opinionated PaaS. Standard offers rapid scaling and per-request concurrency constraints per language; Flexible runs containers on VMs with more control. Avoid instance-local session state; externalize to shared storage to prevent stale or duplicate user experiences under load.
Cloud Functions: function-level granularity for event-driven logic. Use Pub/Sub, Cloud Storage, or Eventarc triggers for lightweight micro-operations; keep functions idempotent and stateless. For combined batch/stream pipelines without existing code, Dataflow provides unified processing with autoscaling.

Platform selection trade-offs:

Operational control: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portability: container-based (GKE/Cloud Run/App Engine Flex) > VM images > functions and App Engine Standard.
Latency: Cloud Run with min instances or GKE for low tail latency; avoid cold starts for interactive workloads.
Scaling: Cloud Functions/Run scale fastest; GKE HPA plus cluster autoscaler; MIGs require warm-up and health checks.
Cost: serverless pay-per-use for spiky/low steady-state; GKE/VMs with committed use discounts for steady, high-throughput services; preemptible/Spot for batch.

Identity and configuration:

Each service should use a dedicated service account with least privilege. For Cloud Run and Functions, set the runtime service account explicitly.
Store secrets in Secret Manager and bind access via IAM; inject via environment variables or volume mounts.

Architecture Patterns, Delivery, and Operations

Service decomposition and boundaries:

Monolith: simplest deployment and transactions, but limits independent scaling and blast-radius control; can mask performance issues deep in call chains.
Modular monolith: clear internal modules, shared process; good interim step—enforces interfaces without distribution penalties.
Microservices: independent deployability and scaling; introduces network latency, distributed transactions, and consistency challenges. Define clear bounded contexts and data ownership; avoid shared databases to prevent coupling.

Modernization patterns:

Strangler-fig: incrementally route a portion of traffic to new components, retire legacy endpoints gradually.
Lift and shift: containerize or VM-migrate first to stabilize, then refactor.
Anti-corruption layer/facade: isolate legacy contracts while building new services.
Prioritize high-change, high-friction domains first to maximize business value and reduce risk.

Delivery and rollouts:

CI/CD with automated tests and staged environments reduces rollbacks. Add canary analysis, error budgets, and progressive delivery.
Blue-green minimizes downtime and simplifies rollback at the expense of double capacity.
Traffic splitting: Cloud Run/App Engine support percentage-based routing across revisions/versions; test under real traffic with tight SLO error budgets.

Load balancing and health:

Use global L7 for HTTP and TCP proxy for non-HTTP protocols; internal LBs for private services. Configure session affinity only when necessary and externalize session state.
Health checks should reflect app availability (e.g., dependency health); simple 200 OK that masks datastore failure can cause bad traffic steering.

Observability and governance:

Instrument traces for end-to-end latency attribution across services; enable logging of request IDs to correlate logs and traces.
Export logs/metrics/audit trails to BigQuery or Cloud Storage for retention and audit needs; secure access via views and IAM.
For VM logs, install the Ops Agent; define retention and sinks to control cost and compliance.

Secure software supply chain:

Use Artifact Registry with scanning; keep images minimal. Optimize Dockerfiles: prefer slim bases, install dependencies first, then copy source to leverage build cache.

Networking and segmentation:

Enforce tiered access via VPC firewall tags and rules to only permit expected flows (e.g., web → API → DB). Deny direct web → DB access.

Capacity, Performance, and Specialized Compute

Design for variable demand:

GCE: autoscale MIGs on leading indicators (queue length) to get ahead of CPU saturation; add request-rate limiting and backpressure to protect downstreams.
GKE: combine HPA on requests-per-second or custom metrics and cluster autoscaler; provision a small buffer to avoid scaling lag.
Serverless: adjust concurrency and min instances to balance cost versus latency; use regional deployment for user-proximate latency.

Resiliency and testing:

Run synthetic load to validate autoscaling and SLOs; include chaos testing (e.g., kill random instances/pods) to ensure the system maintains availability during failures and upgrades.
Configure PodDisruptionBudgets and graceful termination hooks to drain connections before pod/VM shutdown.

Performance and storage selection:

High-throughput, low-latency time-series and clickstream ingestion map well to Bigtable; design wide rows and time-bucketed keys to avoid hotspots.
For Spark/Hadoop with minimal operational changes, use Dataproc; rightsize clusters with autoscaling.
For combined hourly batch and streaming without existing code, use Dataflow with autoscaling and windowing to unify pipelines.

Data movement and connectivity:

For sustained, high-bandwidth, private replication (e.g., multi-terabyte databases), consider Dedicated Interconnect; use VLAN attachments and Cloud Router for dynamic routing. For ad hoc or lower throughput, Cloud VPN suffices.

Stateful workloads:

On GKE, use StatefulSets with persistent volumes (regional PDs for HA) and ordered, stable identities; consider Filestore for NFS semantics.
Use managed databases (Cloud SQL, AlloyDB, Spanner) for durability and scaling where possible; plan read replicas and failover.

Security and compliance:

Consider Confidential VMs to protect data-in-use with limited performance overhead; evaluate against workload requirements.
Use CMEK where keys must be customer-controlled; enforce per-environment isolation, and separate projects for dev/test/prod.

Cost controls:

Use committed use and sustained use discounts for steady-state compute; preemptible/Spot for fault-tolerant batch; autoscaling to zero on serverless.
Right-size resources with Monitoring recommendations; remove idle services and set log-based metrics quotas to avoid cost surprises.

Troubleshooting latency:

Use Cloud Trace to identify the microservice adding the most latency; optimize that service’s code path, caching, or database indexes. Validate improvements with A/B canaries.

Practical Problem Scenario

FerroLine Logistics plans to modernize a J2EE monolith that handles shipment tracking and customer notifications. The workload is bursty during regional cutoffs, must meet a 99.9% availability target, and the team wants portability with minimal operational toil while introducing event-driven features.

Stabilize and observe the current system

Rationale: Before changes, baseline behavior and errors to reduce rollback risk. Deploy the Ops Agent on existing VMs for Cloud Logging and Monitoring, and instrument distributed tracing in high-latency request paths. Export logs and metrics to BigQuery for historical analysis and SLO reporting.

Choose a staged landing zone and platform mix

Rationale: Balance control and velocity. Migrate the monolith as a container to Cloud Run jobs for batch components and Cloud Run services for stateless HTTP APIs, setting min instances for latency-critical endpoints. Keep the stateful Oracle DB on Compute Engine initially, fronted by a regional internal HTTP(S) LB for internal APIs, and plan a future move to AlloyDB.

Externalize session and configuration state

Rationale: Avoid instance-local session issues and enable safe autoscaling. Store secrets in Secret Manager with per-service accounts for least-privilege access. Move session state to Memorystore and shared files to Cloud Storage. This prevents users from seeing stale data under peak load.

Establish identity and registry controls

Rationale: Enforce least privilege and provenance. Store images in Artifact Registry with vulnerability scanning enabled. Assign a unique runtime service account to each Cloud Run service and GKE workload (for components later decomposed), and grant only the required roles (e.g., Pub/Sub Publisher).

Implement CI/CD with safe rollout strategies

Rationale: Reduce unplanned rollbacks. Build a pipeline that runs unit/integration tests and deploys to staging. Use Cloud Run traffic splitting to canary 5–10% of traffic to new revisions and enable fast rollback. For the VM-based DB changes, use blue-green schema migration patterns to decouple application and database deploys.

Decompose high-change domains first

Rationale: Incremental value with lower risk. Apply a strangler pattern: carve out notification delivery as a microservice on GKE to leverage HPA for spikes and Pub/Sub for decoupling. Keep the remaining monolith as a modular monolith on Cloud Run while interfaces stabilize.

Design autoscaling and load shedding

Rationale: Handle bursts without cascading failures. Configure Cloud Run concurrency and min instances per endpoint; set Cloud Armor rate limits at the global HTTP(S) LB to protect against unauthenticated surges. For GKE services, enable HPA on custom metrics (requests per second) and provision a small node buffer via cluster autoscaler.

Prepare stateful services and data paths

Rationale: Ensure durability and performance. For GKE notification retries, use a Bigtable table keyed by customer-region and time buckets to store transient delivery state at high write rates. For private, consistent connectivity to on-prem ERP during transition, use Dedicated Interconnect with Cloud Router.

Execute resilience and performance testing

Rationale: Validate SLOs before full cutover. Run synthetic, randomized user flows to trigger autoscaling layers. Inject chaos by terminating random Cloud Run instances (allowing the control plane to recreate) and evicting GKE pods to verify PodDisruptionBudgets and readiness gates. Use Trace to identify the largest contributor to tail latency and remediate.

Operate with cost and compliance guardrails

Rationale: Sustainably run in production. Set per-service budgets and alerts, enable CMEK on sensitive storage where required, and use committed use discounts for GKE node pools and AlloyDB once steady-state is understood. Configure log retention policies and BigQuery views to share audit data with internal auditors securely.

This phased approach delivers immediate stability and observability, introduces safe deployment practices, progressively decomposes the monolith along natural service boundaries, and aligns platform choices with control, latency, portability, scaling, and cost objectives.

← Organization Design · All domains · Data Storage →

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