What the exam actually feels like on test day

This exam is not a coding exam, but it absolutely punishes shallow hands-on knowledge. Expect around 50-60 multiple-choice and multiple-select questions in 2 hours. No labs. No live terminal. No drag-and-drop in the usual sense. The pressure comes from scenario wording: Google gives you a developer problem, then asks for the most cloud-native fix, not just something that works.

A useful pacing target is about 2 minutes per question, but in practice the distribution is uneven. Some are one-liners about IAM or logging. Others are long deployment scenarios involving Cloud Run vs GKE vs App Engine, plus CI/CD and secret handling. The exam interface lets you flag questions and return later, which matters because the longest scenario questions are often easier after you've cleared the straightforward ones.

Specific pattern I saw repeatedly: a question starts as if it is about code deployment, but the real tested skill is one of these:

choosing the right runtime platform for scaling behavior
separating config from code using Secret Manager or environment variables
adding observability without changing business logic
granting the minimum IAM role to a service account
making a deployment safe with canary, blue/green, or traffic splitting

If you prepare as if this is "a developer exam about writing apps," you'll underperform. It is more like a Google Cloud application lifecycle exam: build, package, deploy, secure, observe, and iterate.

Where the points really are: deployment, integration, and operations

The heaviest-feeling part of the exam is everything around developing, deploying, and operating applications on Google Cloud. I would spend the most time on services a developer directly touches rather than broad architect-level infrastructure.

The topics that showed up most often for me were:

Cloud Run: containerized services, revisions, traffic splitting, concurrency, statelessness, env vars, Secret Manager integration, authentication, and when it beats GKE or App Engine
GKE from a developer angle: Deployments, Services, ConfigMaps, Secrets, readiness/liveness probes, rolling updates, and when Kubernetes is overkill
Cloud Build / Artifact Registry / Cloud Deploy: build triggers, image storage, deployment pipelines, substitutions, and release promotion
Pub/Sub and event-driven design: decoupling services, retries, idempotency, dead-letter topics, push vs pull subscribers
Observability: Cloud Logging, Error Reporting, Cloud Monitoring, Trace, Profiler, and what each tool is actually for
IAM and service accounts: workload identity style thinking, least privilege, service-to-service auth, and avoiding user credentials in code
Data access from apps: Cloud SQL connection patterns, Firestore usage patterns, Memorystore for caching, and choosing managed services over self-managed components

Lower-value study areas for this exam, relative to time spent, are the deeply network-architectural topics that belong more to architect exams. You still need basics like ingress, VPC connectivity, and private access patterns, but if you're deciding between memorizing obscure VPC routing details and learning Cloud Run revision traffic behavior, pick the latter.

Cloud Run, App Engine, or GKE: the exam loves this fork in the road

A huge number of questions boil down to platform selection. Google loves to describe an application and ask for the service that minimizes operational overhead while still meeting one awkward requirement.

Here is the practical decision rule set I kept using:

Cloud Run when the app is stateless, packaged as a container, HTTP-driven or event-driven, and you want fast deployment with minimal ops.
App Engine when the question emphasizes very simple deployment from source, tight integration, or older managed PaaS style tradeoffs. Standard environment especially shows up in questions about quick autoscaling and less infrastructure control.
GKE when the app needs Kubernetes-specific features: custom sidecars, daemonsets, complex networking, specialized scheduling, or strong portability requirements.

Common trap: the question mentions containers and people jump to GKE. That is often wrong. If the app is just a web API in a container and the requirement says minimize operational management, Cloud Run is usually the right answer.

Another trap: the question mentions long-running background processing. Cloud Run can handle background work in some patterns, but if the exam says the process must continuously consume work, maintain cluster-level control, or use Kubernetes-native primitives, Google is nudging you toward GKE. If it's asynchronous event processing with clear request boundaries, they may want Pub/Sub + Cloud Run instead.

Watch for wording around scaling:

If they care about request-driven autoscaling, Cloud Run is favored.
If they care about fine-grained pod behavior, probes, and Kubernetes manifests, GKE is favored.
If they care about simple app deployment without container management, App Engine may be the intended answer.

Know the gotchas that get embedded into answer choices:

Cloud Run services are stateless. If an option stores session or file state locally, it's a bad sign.
For configuration, Google prefers environment variables, ConfigMaps/Secrets, or Secret Manager, not values hardcoded into the image.
For gradual rollout, Cloud Run's revisions and traffic splitting are exam favorites. If the scenario is about reducing deployment risk, that feature is often the clue.

CI/CD questions are less about tools and more about safe release design

The exam likes modern Google-native delivery chains: Cloud Build -> Artifact Registry -> Cloud Deploy / target runtime. You need to know not just what each service does, but why one belongs in the pipeline at a specific step.

The clean mental model:

Cloud Build builds, tests, and packages artifacts.
Artifact Registry stores container images and packages.
Cloud Deploy promotes releases across environments in a controlled way.

Questions often hide the real objective behind a DevOps-sounding story. The actual ask is usually one of these:

how to trigger builds automatically from repository changes
how to separate build from deployment
how to promote the same immutable artifact across dev/test/prod
how to reduce blast radius using canary or staged rollout

Specific exam trap: if an answer rebuilds the container separately for each environment, be suspicious. Google prefers one built artifact promoted across environments, with environment-specific configuration injected externally.

Another repeated gotcha is secrets in CI/CD. If a scenario mentions API keys, DB passwords, or third-party tokens, the right direction is usually:

store them in Secret Manager
grant the build or runtime service account access with least privilege
avoid putting secrets in source control, Dockerfiles, or plain-text substitutions

Also know what not to overcomplicate. If the question is simply about triggering a build on code commit and storing the image, Cloud Build trigger + Artifact Registry is enough. Do not jump to GKE, Jenkins, or custom runners unless the scenario clearly requires them.

For deployment strategy questions, Google likes these distinctions:

Canary/traffic splitting when you need validation with partial production traffic
Blue/green when you need fast rollback and environment isolation
Rolling updates in Kubernetes when the question is clearly at pod deployment level

If the prompt says users are reporting intermittent issues after deployment and you need low-risk rollback, pick the option that uses managed rollout controls rather than manual instance replacement.

Pub/Sub, async processing, and idempotency: easy to underestimate, easy to miss

This exam repeatedly tests event-driven design because Google Cloud pushes it hard. The mistakes people make are usually not about what Pub/Sub is, but about delivery semantics and downstream behavior.

Be ready for questions where the right architecture is:

frontend or API publishes a message to Pub/Sub
one or more services consume asynchronously
retries are expected
processing must be idempotent

That last point matters. If the question describes duplicate message delivery or retry behavior, the exam is not asking you to "make Pub/Sub exactly once" in a casual sense. It is usually asking you to design the consumer to safely handle repeated delivery.

Things to remember when answer choices get subtle:

Pub/Sub decouples producers and consumers; if the scenario wants loose coupling and independent scaling, it is a strong signal.
If failures should not block the user request path, async processing is usually preferred over synchronous service chaining.
If poison messages are mentioned, look for dead-letter topics.
If ordering matters, be cautious: ordering support exists, but many questions are really testing whether you can avoid assuming global ordering.

I saw several scenarios where people might choose Cloud Tasks instead of Pub/Sub or vice versa. My rule:

Cloud Tasks when the exam describes explicit task execution, rate control, and HTTP target invocation with per-task management.
Pub/Sub when the design is event broadcast, fan-out, or loose asynchronous integration.

If a question says "multiple downstream services need to react to the same event," Pub/Sub is the more likely answer.

Security questions are usually about service accounts, not perimeter theory

Security on this exam is very developer-centric. Expect fewer abstract governance questions and more practical ones like: your service needs to call another service, your app needs DB credentials, or your build pipeline needs access to deploy.

The exam strongly rewards these habits:

use service accounts for workloads, not user credentials
grant the smallest IAM role that satisfies the operation
store secrets in Secret Manager
avoid embedding credentials in code, config files, or images
prefer managed identity and built-in auth flows over custom token handling

Common trap: answer choices offering broad roles like Editor or Owner when a narrower runtime role exists. Even if the broad role would work technically, it is usually wrong for this exam.

Another trap is confusion between app config and secrets. If the value is sensitive, Google wants Secret Manager. If it is just environment-specific configuration, environment variables or platform config is fine.

For service-to-service authentication, pay attention to whether the target requires authenticated invocations. In Cloud Run scenarios, the intended answer often includes granting the calling service account permission to invoke the target service instead of making the target public.

For data access questions, don't default to static keys. If the app on Cloud Run or GKE needs to talk to another Google service, the exam usually wants you to attach the appropriate service account and use ADC-style credentials rather than downloading JSON keys.

Observability: know which Google tool answers which question

A lot of candidates blur Monitoring, Logging, Trace, Profiler, and Error Reporting into one bucket. The exam does not. Several questions are basically matching the problem to the right telemetry tool.

Use this practical map:

Cloud Logging: inspect logs, create log-based metrics, troubleshoot events and request details
Error Reporting: aggregate and surface application exceptions
Cloud Monitoring: dashboards, alerting, SLO-style metric watching
Cloud Trace: request latency breakdown across services
Cloud Profiler: CPU/memory performance analysis in running code

Typical question pattern: a microservice app has high latency, but logs show no obvious error. If the issue is understanding where time is spent across services, the answer leans toward Trace, not just more logging.

Another pattern: the app occasionally crashes with stack traces across many instances. Google is often looking for Error Reporting rather than manual log parsing.

A trap I saw is choosing Monitoring when the scenario is actually about capturing structured application logs or searching request-specific failure details. Monitoring is for metrics and alerts; Logging is for event detail. Keep them separate.

Also know that the exam likes structured logging. If the question asks how to make logs more queryable and useful for troubleshooting, emitting structured logs is a stronger answer than dumping plain text.

Data and state questions: developers lose points here by thinking like VM admins

Google keeps nudging you toward managed data services and away from self-managed persistence. If an answer suggests storing important application state on local disk in Cloud Run or ephemeral container storage in general, it is usually bait.

Know the likely matches:

Cloud SQL for relational app backends
Firestore for serverless document-oriented app data and fast developer integration
Memorystore for caching/session acceleration where appropriate
Cloud Storage for object/file storage, not local container filesystem

For Cloud SQL, expect questions around secure connectivity and connection handling. The exam may not go deep into every connector detail, but it does expect you to know that managed connection patterns and service identity are preferred over exposing databases broadly.

A sneaky trap is session state. If the scenario says users are losing session data when instances scale or restart, Google is steering you away from in-memory/local state on individual instances. Look for externalized state: database, cache, or token-based/session redesign.

If the application needs to handle spikes, answers that decouple compute from state are usually favored. That is very much a Google Cloud Developer exam theme.

The last week: what to review from the 375-question practice set

In the final stretch, don't just keep grinding random questions. Use the 375 practice questions to find recurring failure patterns by service boundary. Mine your misses into short review lists.

What I would explicitly revisit in the last week:

Cloud Run
- revisions vs new deployments
- traffic splitting
- authenticated vs unauthenticated invocations
- environment variables and Secret Manager
- stateless design assumptions
GKE developer operations
- readiness vs liveness probes
- ConfigMaps vs Secrets
- rolling updates and rollback behavior
- Service exposure basics
CI/CD
- Cloud Build triggers
- Artifact Registry role in immutable artifacts
- Cloud Deploy promotion concepts
- canary/blue-green reasoning
Async/eventing
- Pub/Sub retries and idempotency
- dead-letter topics
- when Cloud Tasks is the better fit
Observability
- Logging vs Monitoring vs Trace vs Profiler vs Error Reporting
IAM/security
- service accounts for workloads
- least privilege role choices
- Secret Manager usage patterns

One blunt recommendation: create a one-page sheet titled "default Google answer unless requirement blocks it". Mine looked roughly like this:

containerized stateless app -> Cloud Run
async decoupling -> Pub/Sub
secrets -> Secret Manager
built artifact storage -> Artifact Registry
build automation -> Cloud Build
controlled promotion -> Cloud Deploy
app exceptions -> Error Reporting
latency path analysis -> Trace
broad IAM role offered -> probably wrong
local filesystem for durable state -> wrong

That cheat-sheet style review is more useful than rereading docs because this exam is full of near-miss answer choices.

Google exam interface habits that matter for this specific cert

Since this exam has no hands-on lab, your main interface strategy is about triaging scenario length. The longest questions often mix multiple domains — deployment, security, and operations in one prompt. If you know the service family but not the exact feature, flag it and move on rather than burning five minutes reconstructing docs from memory.

Because you can return to flagged items, use a simple pass system:

first pass: answer direct service-identification questions fast
second pass: handle multi-select and migration/deployment scenarios
final pass: revisit the wording-heavy platform-choice questions

For multi-select questions, the Google style often includes two good practices, one over-engineered practice, and one technically possible but not Google-preferred practice. The exam is often testing preference for managed, least-ops, least-privilege solutions.

Pay attention to qualifiers in the prompt because they drive platform choice:

"minimize operational overhead" -> Cloud Run / managed services
"fine-grained control" -> GKE or lower-level option
"gradual rollout" -> traffic splitting/canary tools
"securely store credentials" -> Secret Manager
"investigate latency across services" -> Trace

Finally, if two answers both seem valid, choose the one that is more idiomatic for Google Cloud developers: managed service, externalized config, immutable artifacts, service accounts, and observable distributed systems. That preference shows up again and again on this exam.