1: Designing highly scalable, secure, and reliable cloud-native applications

Learning Objectives

By the end of this chapter, you will be able to:

• Choose between Compute Engine, GKE (Standard and Autopilot), and Cloud Run for a given workload shape, latency target, and operational budget.
• Design APIs that combine HTTP REST and gRPC patterns with Apigee or Cloud API Gateway in front for rate limiting, authentication, and observability.
• Apply session affinity, caching tiers (Memorystore for Redis, Valkey, Memcached), and zonal or regional replication to hit performance and failover targets.
• Wire asynchronous workloads through Eventarc, Pub/Sub, Cloud Tasks, Cloud Scheduler, and Workflows without conflating their roles.
• Apply data lifecycle policies, organization policies, and lock retention to satisfy residency and regulatory requirements.
• Pick authentication patterns (ADC, JWT, OAuth 2.0, Cloud SQL Auth Proxy, Workload Identity Federation) and grant least-privilege IAM roles to users and service accounts.
• Secure service-to-service communication using Cloud Service Mesh, Kubernetes Network Policies, Direct VPC egress, and Private Service Connect.
• Select a storage system across Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Cloud Storage, and BigQuery based on volume, latency, and consistency needs.

Executive Summary

• Compute selection is a function of three variables: the workload's request shape (HTTP request-response, batch, long-lived worker), the team's operational appetite (managed vs hands-on), and the consistency between scaling signals and traffic patterns. Cloud Run absorbs the first when the workload is HTTP and bursty; GKE Autopilot wins when Kubernetes primitives are required without node management; Compute Engine remains the answer for licensed software or non-container workloads.
• Security is layered from artifact through identity to network. Binary Authorization gates which images may run, Workload Identity Federation removes long-lived keys, Cloud Service Mesh provides mTLS between services, and Private Service Connect keeps managed-service traffic off the public internet.
• Storage choice rides on access pattern, not data volume alone. Spanner for global strong consistency at SQL scale, AlloyDB for Postgres analytics + OLTP, Cloud SQL for single-region OLTP lift-and-shift, Bigtable for high-throughput time series, Firestore for mobile real-time, Cloud Storage for blobs with signed-URL access, and BigQuery for analytical writes feeding ML.
• Asynchronous orchestration has a four-way decision: Pub/Sub for fan-out, Eventarc for typed event routing, Cloud Tasks for retryable single-target queues, and Workflows for declarative sequencing. Conflating them produces every common architectural failure on this exam.

Assumptions

• The reader has built and deployed at least one container image to Cloud Run or GKE and understands the basics of gcloud, kubectl, and IAM bindings.
• Region and zone references use the convention us-central1 (region) and us-central1-a (zone). Service account email format is <name>@<project-id>.iam.gserviceaccount.com.
• Where the exam guide lists multiple example services, this chapter covers each by name and shows the tooling surface a developer actually touches.
• All command flags shown reflect the published gcloud reference. When a flag has both a --no- and an unset form, the unset form is the documented default.