Book TOC · Chapter 0 of 7 · Next: Chapter 1

Chapter 0: The PCD Reference Stack & 10 Core Principles

Chapter Focus: A visual guide to the Google Cloud Certified Professional Cloud Developer (PCD) architecture stack, how the core Google Cloud services fit together, and the 10 Core Architectural Principles that govern production design decisions.

1. The Master Architectural Map: All In-Scope Services & Tools of the Architecture Stack

The official Google Cloud Professional Cloud Developer Curriculum spans four major domains (~32% Designing Scalable/Secure/Reliable Apps, ~23% Building & Testing, ~24% Deploying to Cloud Run & GKE, and ~21% Integrating with Services, APIs & Observability). Rather than memorizing services in isolation, organize the 36 core Google Cloud services and developer tools across Six Architectural Planes:

Complete Reference Table of In-Scope PCD Services & Tools

2. The 10 Core Architectural Principles of the Architecture Stack

Whenever you are torn between two plausible-sounding options In Google Cloud architectures, apply these 10 Core Architectural Principles—they eliminate over 80% of look-alike service comparisons immediately:

1. Principle 1 — Never Export Static Service Account JSON Keys: Any option that downloads a .json service account key file—whether for a local laptop, a GKE Pod, a Compute Engine VM, or a GitHub Actions pipeline—is almost always a trap. Use Application Default Credentials (ADC) with --impersonate-service-account locally, GKE Workload Identity for Pods, attached Service Accounts for Cloud Run/GCE, and Workload Identity Federation (WIF) for external CI/CD or multi-cloud workloads.
2. Principle 2 — Stateless Compute Demands Externalized State & stdout Logging: Cloud Run instances and GKE Pods are ephemeral. Never write session state or application logs to the local container disk (/var/log). Externalize user session data to Memorystore for Redis or Firestore, store files in Cloud Storage (using Signed URLs for direct client uploads/downloads), and emit structured JSON logs to stdout and stderr with the logging.googleapis.com/trace field.
3. Principle 3 — Match the Async Tool to the Control Model (Pub/Sub vs. Cloud Tasks vs. Workflows vs. Eventarc):
4. Need 1-to-many fan-out decoupling where the publisher does not know the subscribers? → Cloud Pub/Sub.
5. Need rate-limited dispatch (maxDispatchesPerSecond) or scheduled delivery to protect a fragile downstream API/DB? → Cloud Tasks.
6. Need stateful step-by-step orchestration with conditional branching and Saga compensation rollbacks? → Cloud Workflows.
7. Need standardized CloudEvents routing from 130+ Google Cloud services (Audit Logs/GCS) to Cloud Run/GKE? → Eventarc.
8. Principle 4 — Tune Cloud Run Concurrency & Minimum Instances to the Runtime: Cloud Run defaults to concurrency 80. If a container runs a single-threaded CPU-bound process or heavy memory workload per request, lower --concurrency (down to 1 if necessary) so Cloud Run scales out instances instead of blocking the event loop. To eliminate cold-start latency on latency-sensitive APIs, configure --min-instances (and enable Startup CPU Boost for slow JVM/CLR initialization).
9. Principle 5 — Separate the Three Kubernetes Probes by Lifecycle Phase:
10. startupProbe: Protects slow-starting legacy/Java containers from premature termination during initial boot.
11. readinessProbe: Controls traffic routing—if a dependency is temporarily overloaded or the pod is warming caches, failing readinessProbe removes the Pod IP from the Service load balancer without restarting the container.
12. livenessProbe: Detects deadlocks—failing livenessProbe kills and restarts the container. Never check external databases in a livenessProbe, or a transient DB blip will trigger a cascading restart storm across your entire cluster!
13. Principle 6 — Prevent Hotspots in Distributed Databases (Spanner, Bigtable, Firestore): Never use monotonically increasing integers (AUTO_INCREMENT), raw timestamps as the row-key prefix, or sequential document IDs at high write rates—they route 100% of writes to a single storage split/tablet. Use UUIDv4, hash-prefixed keys, or bit-reversed sequences in Cloud Spanner; use MetricType#ReverseTimestamp or salted prefixes in Cloud Bigtable; and use auto-generated random IDs in Firestore.
14. Principle 7 — Manage Database Connections Carefully from Serverless Compute: When Cloud Run or Cloud Functions scales out to 500 instances during a traffic spike, opening a new database connection per request will instantly exhaust max_connections on Cloud SQL or AlloyDB. Always initialize your connection pool in global scope (outside the request handler), bound the pool size per instance, and connect securely via the Cloud SQL Auth Proxy / AlloyDB Auth Proxy or Direct VPC Egress.
15. Principle 8 — Secret Manager Stores Application Secrets; Cloud KMS Manages Cryptographic Keys: Never store database passwords, OAuth client secrets, or third-party API keys directly in Cloud KMS or plaintext cloudbuild.yaml / Dockerfile ENV instructions. Store them in Secret Manager, grant roles/secretmanager.secretAccessor to the runtime service account, and reference the pinned secret version via native Cloud Run volume mounts/env vars or the Secret Manager API.
16. Principle 9 — Enforce Supply Chain Integrity from Build to Runtime (Cloud Build → Artifact Analysis → Binary Authorization): Build images from source using multi-stage Dockerfiles or Google Cloud Buildpacks, scan automatically on push with Artifact Analysis, verify vulnerability counts in your cloudbuild.yaml pipeline before creating a cryptographic Attestation, and enforce Binary Authorization on GKE/Cloud Run using immutable @sha256 image digests (never mutable :latest tags).
17. Principle 10 — Consume APIs Defensively (Field Masks, Page Tokens, Batching, and Exponential Backoff with Jitter): When calling Google Cloud or REST/gRPC APIs, restrict payload bandwidth using the fields parameter (FieldMask), traverse large collections with pageToken / pageSize (never unbounded OFFSET), consolidate small calls via Batching, and handle transient 429 Too Many Requests or 503 Service Unavailable errors using Truncated Exponential Backoff with Randomized Jitter to prevent thundering herds.

Book TOC · Chapter 0 of 7 · Next: Chapter 1