Google PCD: Compute, Containers and Serverless Runtime Platforms — Study Guide

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Overview

Google Cloud offers multiple runtime platforms spanning serverless, containers, and virtual machines. Selecting the right platform depends on workload characteristics such as request patterns, state management, build and release discipline, operational model, and networking constraints. This section covers design principles, failure modes, and trade-offs for Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE), and Compute Engine, along with supporting services for images, identity, networking, configuration, and operations.

Serverless Runtimes: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Model: Fully managed containers with HTTP request handling or containerized Jobs that run to completion.
• Revisions and traffic: Each deploy creates an immutable revision. Splitting traffic by percentage across revisions enables canary and blue-green patterns with instant rollback. Example:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10
  

• Concurrency and scaling: Default concurrency is 80; set to 1 for CPU-bound or non-thread-safe code. Higher concurrency reduces cold-start amplification and cost, but can increase tail latency if per-request CPU/memory is inadequate. Cloud Run scales to zero and up based on incoming request rate; control with min/max instances to reduce cold starts and bound cost.
• CPU allocation: Choose “CPU always allocated” for background work between requests at the cost of additional billing; otherwise CPU is only allocated while handling requests.
• Jobs: Cloud Run Jobs run N parallel tasks until completion with max retries per task and overall timeouts; suitable for ETL, batch, and fan-out processing. Failure modes include hot-spotting backends when many tasks target the same dependency; add rate limiting and retries with backoff.
• Networking: Public, authenticated via IAM, or private behind VPC via Serverless VPC Access and Private Service Connect.

App Engine

• Environments:
  • Standard: Sandboxed, rapid scale, per-language fixed runtimes; low cold-start latency with automatic scaling; restricted file system, request timeouts, and inbound request size limits. Use Cloud Storage signed URLs for large uploads.
  • Flexible: Docker-based, VM-like capabilities, custom runtimes, slower scale-up than Standard, supports background threads and writing to local disk.
• Services and versions: A service (microservice) can host multiple versions; route traffic by percentage across versions similar to Cloud Run. Use dispatch.yaml to route specific paths or hosts to services for simple, centralized routing without an external load balancer.
• Scaling: Manual, basic, or automatic in Standard; VM count-based scaling in Flexible. Trade-off: aggressive autoscaling improves responsiveness but can increase cost and backend contention.
• Common pitfalls: Unbounded instance scale without quotas can overwhelm downstream systems; enforce quotas and circuit breakers.

Cloud Functions

• Event-driven handlers: Triggered by HTTP, Pub/Sub, Cloud Storage, or Eventarc events. Use 2nd gen to leverage Cloud Run’s execution model, VPC egress control, and concurrency; 1st gen processes one request at a time.
• Retries and idempotency: Background functions can be retried on failure; design idempotent handlers and use de-duplication keys to avoid double-processing. HTTP triggers are not retried by the platform; implement client retries with exponential backoff.
• Runtime configuration: Environment variables, Secret Manager integration, and per-function concurrency/max-instances. Set timeouts to contain runaway costs. Beware of long cold-starts with large dependencies; keep packages slim.

Containers on Google Kubernetes Engine

Workloads

• Deployments: Stateless pods with rolling updates. Ensure safe rollouts with surge/unavailable limits:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  

• StatefulSets: Ordered, stable network IDs and persistent volumes for stateful services.
• DaemonSets, Jobs, CronJobs: Node-level agents and batch workloads.

Services and Ingress

• Service types:
  • ClusterIP for internal-only.
  • NodePort for simple external access (operationally limited).
  • LoadBalancer for regional external/internal load balancing.
• Ingress: HTTP(S) routing and TLS termination; prefer Gateway API or Ingress with managed controllers for L7 policies. Failure mode: health checks failing due to firewall; allow load balancer IP ranges to backend nodes.

Autoscaling and Node Pools

• Horizontal Pod Autoscaler (HPA): Scales pods on CPU, memory, or custom metrics; combine with Pod Disruption Budgets to protect availability.
• Vertical Pod Autoscaler (VPA): Right-sizes pod requests/limits; avoid simultaneous HPA+VPA on same dimension to prevent feedback loops.
• Cluster Autoscaler: Adds/removes nodes to meet pending pod resource requests.
• Node pools: Separate pools by workload class. Use taints/tolerations and labels for scheduling. Mix spot/preemptible for cost-sensitive workloads with disruption tolerance. Choose machine types with enough memory bandwidth/CPU for per-pod limits to avoid throttling.

Health and rollouts

• Liveness, readiness, and startup probes prevent sending traffic to unready pods and restart deadlocked containers. Tight liveness probes can cause cascading restarts; tune initial delays and failure thresholds.
• Rollback with kubectl rollout undo. For canary, use multiple Deployments and Service-level traffic splitting via Ingress/Gateway.

Compute Engine for Application Workloads

VM design

• Instance templates define machine type, image, disks, service account scopes, startup scripts, and metadata. Keep images minimal; use startup scripts or images baked by Packer for deterministic boot.
• Disks: Use balanced or SSD persistent disks for latency-sensitive apps. Share large read-only datasets across a managed instance group via a read-only persistent disk attached to multiple instances for low-latency and quick startup.
• Networking: Create firewall rules for health checkers when using load balancers. Example:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS
  

Managed Instance Groups (MIGs)

• Autoscaling by CPU, load balancer requests per second, custom metrics, or schedules. Set cool-downs to prevent thrashing.
• Autohealing with health checks restarts unhealthy VMs; ensure the health check path tests application readiness, not just port reachability, to avoid serving 500s.
• Rolling updates and blue-green: Create a new instance template and start a canary update to a subset of instances. If errors rise, rollback to the previous template. Uptime checks and SLO-based alerting detect degradations quickly.

Logging and monitoring

• Install agents to collect app logs without code changes; ship to Cloud Logging and alert via Cloud Monitoring. Use Debug Logpoints for live diagnostics with minimal disruption.

Build, Identity, Networking, Secrets, and Operations

Artifact Registry and images

• Use Artifact Registry for container images and language artifacts. Enable vulnerability scanning and provenance generation. Keep images small:
  • Multi-stage builds to separate build and runtime.
  • Avoid dev tools in final image; pin OS and package versions. Example:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app
  
  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]
  

• Promotion: Tag images immutably (e.g., app:1.3.7, app:prod-20240901) and promote by retagging in Artifact Registry; avoid mutable latest in production. Gate promotions with integration and canary test results.

Runtime identity and least privilege

• Assign a dedicated service account per workload with the minimum IAM roles required. Avoid broad roles such as Editor. In GKE, map Kubernetes ServiceAccounts to Google service accounts via Workload Identity. For serverless, set the runtime service account explicitly and remove default-token scopes.

VPC connectors and service networking

• Serverless VPC Access connectors route egress from Cloud Run, Cloud Functions, and App Engine to a VPC. Choose egress mode:
  • Private ranges only to reach RFC1918 and VPC-connected services while public egress goes direct.
  • All traffic via connector plus Cloud NAT for deterministic egress IPs and restricted outbound policies.
• Private dependencies: Prefer Private IP for Cloud SQL and Private Service Connect for Google APIs or partner services. Ensure connectors are region-matched and sized for throughput; monitor connector CPU to avoid throttling.

Configuration, secrets, and health checks

• Use environment variables for non-secret config. Store secrets in Secret Manager and mount or inject at runtime; rotate keys regularly. In GKE, use Secrets and CSI driver for Secret Manager. In App Engine and Cloud Run, grant the service account access to specific secrets.
• Health checks:
  • Cloud Run: instance restarts on crash; use request-level checks and latency SLIs.
  • App Engine: built-in health checks; customize liveness/readiness for Flexible.
  • GKE: configure liveness/readiness/startup probes.
  • Compute Engine behind LBs: use HTTP(S) health checks with application-specific endpoints.

Troubleshooting, rollback, and release patterns

• Blue-green and canary with traffic splitting on Cloud Run and App Engine; in GKE, use parallel Deployments or progressive delivery controllers; in MIGs, use canary subsets of instances. Always define abort criteria based on SLO error budget and latency.
• Common failure modes:
  • Thundering herds after scale-to-zero or large rollouts; mitigate with min instances, warmups, and rate limiting.
  • Exceeded backend quotas or connection limits; apply exponential backoff and circuit breakers.
  • Cold starts due to large images or dependencies; slim images and pre-initialize clients.

Practical Problem Scenario

Acme Retail plans to migrate an image-resize API from self-managed VMs to a scalable, cost-effective platform with low-latency responses, private access to a regional Cloud Storage bucket, and safe canary releases.

Approach

1. Package the service as a small container image and publish to Artifact Registry.

• Rationale: A slim, multi-stage Docker build minimizes cold starts and network transfer. Artifact Registry centralizes scans and promotion workflows.

2. Deploy the API to Cloud Run with min instances of 2, concurrency of 40, and CPU always allocated disabled.

• Rationale: Cloud Run provides instant horizontal scaling and managed HTTPS. A small min instance pool reduces cold start latency during diurnal peaks. Concurrency of 40 balances cost and tail latency for I/O-bound image transforms. Disabling always-on CPU avoids paying for idle compute between requests.

3. Create a Serverless VPC Access connector and set egress to private ranges only; enable Private Google Access in the subnet and configure a VPC-SC or Private Service Connect endpoint for Cloud Storage if needed.

• Rationale: The API must fetch and write images privately without public egress. Private ranges mode ensures only VPC traffic goes through the connector, keeping public calls direct and efficient. Private Google Access or Private Service Connect provides private access to Google APIs from the VPC.

4. Grant a dedicated runtime service account least-privilege access to the target Cloud Storage bucket and required secrets.

• Rationale: Principle of least privilege limits blast radius. The runtime identity receives storage.objectViewer and storage.objectAdmin on the specific bucket, and accessor on the needed Secret Manager secrets.

5. Store API keys and per-environment configuration in Secret Manager and environment variables; inject secrets at runtime.

• Rationale: Centralized secret rotation and auditable access. Non-secret config via env vars supports 12-factor practices.

6. Implement exponential backoff and idempotent writes to handle 429/5xx from Cloud Storage.

• Rationale: During bursts or regional events, transient errors can occur. Backoff with jitter protects both the API and Cloud Storage from retry storms.

7. Configure a canary revision and split 10% traffic to it; monitor error rate, P95 latency, and saturation.

• Rationale: Traffic splitting on Cloud Run enables safe progressive rollout. SLO-based monitors provide automatic rollback triggers if error budgets burn too quickly.

8. Add an HTTP health endpoint that exercises downstream dependencies; set alerts on Cloud Monitoring uptime checks and log-based metrics.

• Rationale: End-to-end health detects dependency failures early. Uptime checks provide external perspective; log-based metrics capture application-specific failure patterns.

9. Establish autoscaling limits and budgets; set max instances to cap spend, and define 429 handling for overload.

• Rationale: Bounding scale prevents runaway cost and backend exhaustion. Graceful overload behavior maintains service stability.

10. Document rollback: shift 100% traffic back to the previous Cloud Run revision with a single command.

• Rationale: Immutable revisions make rollback safe and fast, minimizing mean time to recovery.

← Cloud-Native Application Architecture and Service Selection · All domains · API Design →

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

Browse Google →