Home / cloud-computing / Google Cloud Certified Professional Cloud Developer / Cheat Sheet
Google Cloud Certified Professional Cloud Developer

GCP PCD Cheat Sheet

Cloud Developer Tests Managed Runtimes, Event Wiring and Credential Hygiene — Not Framework Syntax

For developers building cloud-native apps, using the April 2026 guide that adds AI coding assistants and MCP servers. The shift: reach for Cloud Run, client libraries and short-lived identities before custom code or standing keys.

Check Your Readiness →
Among the harder certs
Avg: Not published by Google
Pass: 750 / 1000
Most candidates understand Google Cloud Certified Professional Cloud Developer concepts — and still fail. This exam tests how you apply knowledge under pressure.

Professional Cloud Developer Section Map (April 2026 guide)

Code-adjacent scenarios with one or two hard constraints: bursty traffic, regulated data, a fragile partner API or a latency limit. Several answers work in principle; the scored one is the most managed option with the least custom code. Generative AI tooling appears inside sections rather than as its own.

  1. 01
    Designing scalable, secure, reliable cloud-native apps (~32%) — Cloud Run vs. GKE vs. Compute Engine, data store fit, Pub/Sub vs. Cloud Tasks vs. Workflows, Apigee
  2. 02
    Configuring apps for deployment (~24%) — Cloud Run revisions and tags, Eventarc and push auth, concurrency, GKE probes and HPA
  3. 03
    Building and testing applications (~23%) — gcloud emulators, Cloud Code, Cloud Workstations, Cloud Build, Artifact Registry, provenance, MCP scope
  4. 04
    Integrating with Google Cloud services (~21%) — Cloud SQL connectors and pooling, Pub/Sub acks and dead-lettering, backoff, structured logs and traces

Wrong instinct vs correct approach

Jobs must call a partner API that allows only a fixed number of requests per second
✕ Wrong instinct

Publish each job to Pub/Sub with a push subscription

✓ Correct approach

Cloud Tasks dispatches to one target with explicit per-queue rate limits, retries and scheduled delivery. Pub/Sub fans events out to many independent subscribers, Cloud Scheduler runs timed jobs, and Workflows handles multi-step branching.

A mobile shopping-list app must sync edits made offline across devices with no servers to manage
✕ Wrong instinct

Cloud SQL behind a Cloud Run API

✓ Correct approach

Firestore is a serverless document database with offline support and real-time sync to clients. Spanner suits global relational transactions, Bigtable suits time-series key lookups, and Cloud SQL or AlloyDB suit regional relational workloads.

A Cloud Run service lists millions of objects then hits HTTP 429 calling a rate-limited Google API
✕ Wrong instinct

Retry each failed call every second until it succeeds

✓ Correct approach

Use the client library's pagination and field masks, then retry only transient 429 and 503 errors with exponential backoff and jitter, or queue calls through Cloud Tasks. Tight synchronised retries amplify overload.

Only images built by the company's trusted Cloud Build pipeline may run in production
✕ Wrong instinct

Enable Artifact Analysis scanning and consider it enforced

✓ Correct approach

Have Cloud Build generate SLSA provenance and enforce a Binary Authorization policy at deploy time. Scanning lists known CVEs but proves nothing about which builder or source produced the image, and it never blocks a deployment.

Know these cold

  • ▸ Check Cloud Run first, then GKE, then Compute Engine, unless a stated need rules one out
  • ▸ Session affinity aids cache locality; carts and sessions belong in Memorystore or a database
  • ▸ Signed URLs give one object to someone without a Google account until expiry
  • ▸ Spanner leading keys — UIDv4 or bit-reversed sequences, never auto-increment
  • ▸ Apigee for monetised, versioned, analysed APIs; Cloud API Gateway for simple serverless fronts
  • ▸ gcloud run deploy --source builds with buildpacks or a Dockerfile via Cloud Build
  • ▸ Test a tagged zero-traffic revision, then shift percentages; roll back by moving traffic
  • ▸ Raise Cloud Run concurrency for I/O-bound code; lower it for CPU-heavy or non-thread-safe code
  • ▸ HPA scales Pods and needs resource requests; Pending Pods need node capacity instead
  • ▸ A disabled-API error is fixed by enabling the API, not by granting more roles

Can you answer these without checking your notes?

In this scenario: "Jobs must call a partner API that allows only a fixed number of requests per second" — what should you do first?
Cloud Tasks dispatches to one target with explicit per-queue rate limits, retries and scheduled delivery. Pub/Sub fans events out to many independent subscribers, Cloud Scheduler runs timed jobs, and Workflows handles multi-step branching.
In this scenario: "A mobile shopping-list app must sync edits made offline across devices with no servers to manage" — what should you do first?
Firestore is a serverless document database with offline support and real-time sync to clients. Spanner suits global relational transactions, Bigtable suits time-series key lookups, and Cloud SQL or AlloyDB suit regional relational workloads.
In this scenario: "A Cloud Run service lists millions of objects then hits HTTP 429 calling a rate-limited Google API" — what should you do first?
Use the client library's pagination and field masks, then retry only transient 429 and 503 errors with exponential backoff and jitter, or queue calls through Cloud Tasks. Tight synchronised retries amplify overload.

Common Exam Mistakes — What candidates get wrong

Making a Cloud Run service public so Eventarc or push deliveries succeed

Opening the service to allUsers exposes it to the internet. Grant the Cloud Run Invoker role to the trigger's or push subscription's service account, and authenticate Pub/Sub push with an OIDC token from that account.

Using a long liveness initial delay to cover slow application startup

Liveness failure restarts the container, readiness failure removes the Pod from Service endpoints without restart, and a startup probe holds both until boot finishes. Cache warm-up errors during rolling updates call for a readiness probe.

Opening a new Cloud SQL connection per request from Cloud Run

Scaled-out instances exhaust database connection limits. Use the Cloud SQL language connectors or Auth Proxy for IAM-authorised, encrypted connections and a pool sized to instance limits, never authorised networks with changing serverless egress IPs.

Acknowledging Pub/Sub messages before the work has finished

A crash after an early ack loses the message. Ack after success, extend deadlines for long work, make handlers idempotent because delivery is at-least-once, and route poison messages to a dead-letter topic after maximum attempts.

Pointing unit tests at a shared Firestore or Spanner test database

Shared state makes runs flaky, slow and billable. gcloud emulators cover Pub/Sub, Firestore, Datastore, Bigtable and Spanner via emulator host variables with no code change; integration tests run as Cloud Build steps before push.

Resources to help you pass Google Cloud Professional Cloud Developer on your first attempt

Check whether your Cloud Run, Pub/Sub and credential choices match what the Cloud Developer exam rewards.