GCP Professional Cloud Developer common mistakes
GCP Professional Cloud Developer · Understand the traps and how to avoid them.
On Cloud Run, size a CPU-heavy or background-worker service with the platform defaults (1 vCPU, concurrency 80) and assume the container keeps getting CPU between requests.
Instance-based billing and 'CPU always allocated' are opt-in. Under the default request-based billing, CPU is throttled outside request handling, so warm-up work, background threads, and async flush loops stall and the instance looks 'hung' under load. The default concurrency of 80 also means one instance absorbs many simultaneous requests.
What to do instead
Choose the billing model per workload instead of accepting defaults: enable always-allocated CPU (--no-cpu-throttling) only where background work genuinely needs it, move batch work to Cloud Run jobs, and lower --concurrency for CPU-bound handlers after a load test establishes the safe value.
Deploy every workload under the default compute service account, or one shared service account with Editor, because it 'just works', then try to solve security only with network controls.
Sample deployments and quickstarts usually omit --service-account, so the default account is used silently. Candidates then never see per-workload identity and reason about IAM as if it only applied to human users.
What to do instead
Create one user-managed service account per workload holding only the roles the code actually calls (for example roles/pubsub.subscriber, roles/secretmanager.secretAccessor), pass it explicitly at deploy time, and use Workload Identity for GKE instead of node service accounts or exported key files.
Write a request handler that assumes the platform will retry failed work, or that each message is delivered exactly once, without making any write idempotent.
Cloud Run does not retry a failed request unless you ask it to, while Pub/Sub push and pull delivery is at-least-once and redelivers after ack-deadline expiry. Candidates generalise retry and delivery semantics from one product to another, so the same code path is both 'never retried' and 'sometimes duplicated'.
What to do instead
Make handlers idempotent using a natural key or message ID, conditional writes, or an upsert with a version check; enable retries only where the path is safe, and extend ack deadlines or use exactly-once subscriptions where the requirement is genuinely strict.
Write a Cloud Build config where step one installs a tool (apt-get, npm install -g, pip install) and step two invokes that tool.
Every build step runs in its own container; only /workspace is shared. Candidates reason about build steps as if they were sequential lines in a single shell script.
What to do instead
Keep install-and-use inside one step, or use an official builder image that already ships the tool, or build a custom builder image and reference it. Persist only build artifacts under /workspace.
Point tests at the Firestore, Pub/Sub, or Spanner emulator by setting the *_EMULATOR_HOST variable inside a test function, while the client object was already constructed at import time, then claim CI runs against emulators.
Emulator environment variables are read when the client is created, which typically happens at module import or application startup. The flag has no effect, so tests either silently reach the real project or fail in CI where no application default credentials exist.
What to do instead
Set emulator environment variables before any client is constructed (process start, conftest-level env, or CI step environment), add a startup assertion that logs the emulator endpoint, and fail fast if a test process can reach the real project.
Roll back a bad Cloud Run release by deleting the newest revision, or assume a fresh deploy has no effect on which revision is serving traffic.
A revision that is receiving traffic cannot be deleted, and traffic routing is a property of the service rather than of which revisions exist. Deployments using --no-traffic or --tag create candidate revisions that serve zero percent, which surprises candidates who expect an instant full rollout.
What to do instead
Ship candidates with --no-traffic and a tag, shift traffic with a traffic-update command by percentage or tag, and roll back by sending one hundred percent to the last known-good revision, keeping old revisions available for the flip.
Assume a Cloud Run service or GKE pod can reach an internal IP address (Cloud SQL private IP, Memorystore, on-premises host) merely because it lives in the same project, and debug the failure as a code or DNS bug.
Serverless runtimes execute outside the VPC. They need a Serverless VPC Access connector or Direct VPC egress plus the correct egress setting, and the connector's own subnet, region, and firewall rules apply.
What to do instead
Attach egress explicitly with the connector or network and the intended egress mode (private-ranges-only versus all-traffic), size the connector for peak throughput, permit the connector subnet in firewall rules, and verify connectivity from inside the running instance rather than from a laptop.
Rely on messages arriving in order, or on each message being processed once, by publishing to a topic and running several subscriber clients with no ordering key and no deduplication.
Pub/Sub is unordered and at-least-once by default. Ordering needs an ordering key set at publish time and ordering enabled on the subscription, and is guaranteed only per key; exactly-once delivery is a separate subscription setting with region and client constraints.
What to do instead
Set the ordering key when publishing, enable message ordering on the subscription, keep one outstanding batch per key in the client, and still write idempotent consumers. Adopt exactly-once subscriptions only when the region and pull-client requirements fit.
Generate Cloud Storage signed URLs locally with user credentials or application default login and expect them to work in production, or export a long-lived service account key to make signing succeed.
URL signing requires access to a private key. User credentials have none, so local signing fails and teams fall back to downloaded keys. The keyless IAM signBlob route through service account impersonation is the supported approach and is easy to overlook.
What to do instead
Sign through the IAM Credentials signBlob API using the runtime service account (or the equivalent impersonation flag on the CLI), grant the caller roles/iam.serviceAccountTokenCreator, and always set an expiry plus the required HTTP method and headers on the signed URL.
Stream rows into BigQuery with the legacy streaming insert, supply an insertId, and then assume exactly-once delivery and immediate availability of those rows for export, copy, or DML.
insertId is best-effort deduplication over a short window only. Streamed rows sit in the streaming buffer, cannot be exported or copied, and are not visible to every operation, so candidates mistake streaming for an ordinary table write.
What to do instead
Use the Storage Write API with exactly-once semantics (default stream plus offsets) when deduplication matters, and do not depend on freshly streamed rows being immediately exportable: check the streaming buffer status, or land data in a staging table and run a scheduled load and merge.