Google Cloud Certification Prep Kit: Digital Leader, ACE, PCA, PDE & Security Engineer

Certifications do not make you an engineer, but they do two genuinely useful things: they force you to fill the gaps you have been quietly working around, and they give a hiring manager a cheap, legible signal that you have breadth. The trouble with most prep is that it teaches you to recognise answers rather than to reason about scenarios — which is precisely what the modern Google Cloud exams refuse to reward. Nearly every question on the Associate Cloud Engineer and the Professional exams is a short scenario: a workload, a constraint or two (cost, latency, operational toil, compliance, an existing on-premises estate), and four plausible designs. You pass by eliminating the three that violate a constraint, not by remembering a definition. The Professional Cloud Architect goes further still — it bolts entire case studies onto the exam, and a slice of your questions are answerable only by re-reading the case’s requirements.

This kit is built for that reality. It covers the whole Google Cloud ladder — the foundational Cloud Digital Leader (CDL), the Associate Cloud Engineer (ACE), and the Professionals: Cloud Architect (PCA), Cloud DevOps Engineer, Cloud Security Engineer (PCSE), Data Engineer (PDE), Machine Learning Engineer (PMLE), Cloud Network Engineer (PCNE), and the Cloud Database Engineer. For each exam you get the domain breakdown with weightings, a one-page cheat sheet, and a bank of scenario questions with worked answers and an explanation of why each wrong option is wrong, because the distractor analysis is where the real learning lives. There is a dedicated walk-through of the three PCA case studies (Mountkirk Games, EHR Healthcare, Helicopter Racing League), a section on the services examiners deliberately confuse you between (Cloud Run vs GKE vs App Engine vs Functions; Cloud SQL vs Spanner vs Bigtable vs Firestore vs AlloyDB; Dataflow vs Dataproc), a recommended order, a study-plan template you can copy, and a plain explanation of how Google’s pass/fail, no-scaled-score result actually works so you stop fixating on “how many can I get wrong”.

Learning objectives

By the end of this lesson you will be able to:

• Choose the right exam and the right order through the Google Cloud certification ladder for your role and experience.
• Recite the domains and weightings for CDL, ACE, PCA, DevOps, PCSE, PDE, PMLE, PCNE and Cloud Database Engineer, and use them to budget study time.
• Decode the question format (multiple-choice and multiple-select, plus the PCA’s case-study items) and apply a repeatable elimination technique.
• Work scenario questions the way the exam wants — reading for the deciding constraint and using distractor analysis to confirm the answer.
• Navigate the three PCA case studies and pre-decide the architecture each one is steering you toward.
• Distinguish the commonly-confused services — compute, databases, and data processing — that decide a large fraction of associate- and professional-level questions.
• Build a realistic study plan and understand Google’s pass/fail scoring so you walk in calibrated, not anxious.

Prerequisites

You should already have hands-on Google Cloud exposure roughly equal to the earlier lessons in this course: comfort with the global infrastructure, resource hierarchy and pricing model (Google Cloud Fundamentals), IAM (IAM Fundamentals), core compute/storage/networking, and ideally the architecting and portfolio lessons (the Architecting Ladder and Portfolio Projects). This lesson is the readiness layer on top of that knowledge — it assumes the concepts and drills the exam. If a service name here is unfamiliar, treat it as a gap to close before booking the test. This is the final study lesson before the Zero-to-Hero capstone.

The Google Cloud certification ladder and how to choose

Google groups its certifications into three tiers — Foundational, Associate, and Professional — and the Cloud Digital Leader sits in a “foundational” slot of its own. There are no formal prerequisites; you may sit any exam at any time. But there is a sensible order, and trying to skip rungs usually wastes money on a failed sitting and the wait before a re-take.

A few practical notes. Google does not publish a fixed question count; expect roughly 50–60 items, and the visible count varies between forms. Prices are the standard global fee in US dollars and vary by region and currency; some markets and student/partner programmes get discounts or free retake vouchers. The case-study exams (PCA, and to a lesser degree PDE and DevOps) give you linked scenarios you can re-open during the test — read them once carefully at the start. Validity is 2 years for the Professionals and 3 years for the foundational/associate tier; you re-certify by re-sitting (sometimes a shorter renewal form is offered).

The diagram above lays the ladder out as a path: start at the foundational rung if you are new, take the Associate Cloud Engineer to prove hands-on ability, then climb to the Professional that matches your job — most engineers go CDL (optional) → ACE → PCA, or ACE → Cloud DevOps if their work is platform/CI-CD heavy, and bolt on PCSE, PDE, PMLE, PCNE or Cloud Database Engineer when their role demands the specialism.

Recommended order

• Brand new to cloud, non-engineer, or you want a confidence win: Cloud Digital Leader first. It is genuinely foundational and cheap; engineers with a year of real GCP can usually skip it and start at ACE.
• Engineer/architect: ACE is the highest-leverage single certification in the catalogue — it proves you can actually operate the platform with gcloud and the Console, and it is the natural base for every Professional.
• Then specialise by role: add PCA if you design systems (the broadest, most respected Professional), Cloud DevOps if you run them, PCSE if you secure them, PDE/PMLE for data/ML, PCNE for networking, Cloud Database Engineer for the data layer.
• Professional pairings that share a blueprint: ACE → PCA is the classic path; PDE and PMLE overlap heavily (both lean on BigQuery, Dataflow and Vertex AI); PCSE pairs naturally with PCA because security questions leak into every architecture exam.
• Most-valuable additions for a generalist: PCSE (security shows up everywhere) and PCNE (networking is the topic most engineers under-study). Data/ML certs are discipline-specific.

Question formats and how the exam is built

Every Google Cloud exam draws from two basic item types, plus the case-study wrapper on some Professionals:

There is no penalty for wrong answers — the result is based only on correct ones — so never leave a question blank. A flag-for-review feature lets you mark items and return; budget your time and come back to the hard ones. The exams are scenario-led: a typical ACE or Professional stem describes a workload and then asks for the option that is “most cost-effective”, “with the least operational overhead”, “follows Google-recommended practices”, or “with the fewest steps / no code”. Those qualifiers are the whole question — two options are often both technically possible and only one satisfies the qualifier (and Google’s “recommended practice” usually means use the managed/native service and least privilege).

A repeatable technique that works across all of them:

1. Read the last sentence first to find what is actually being asked and the deciding qualifier (cost / overhead / latency / availability / “recommended” / “least privilege” / “no code”).
2. Extract the hard constraints from the stem (compliance/data-residency, RTO/RPO, “no servers to manage”, “existing on-prem”, a specific protocol, “global strong consistency”, “open-source compatibility”).
3. Eliminate options that violate a constraint — usually two fall immediately.
4. Choose between the survivors using the qualifier, not your personal preference. When in doubt, the Google-recommended, most-managed, least-privileged option wins.
5. Flag and move on if you are over budget; speed on easy questions buys time for the case-study items.

Cloud Digital Leader (CDL)

Foundational breadth for a business audience: the value of cloud, Google Cloud’s product families at a name and use-case level, digital transformation, data/ML value, and modernising infrastructure and applications. No gcloud, no architecture, no code — the goal is vocabulary and the shape of the platform.

Checklist: what cloud is and the value proposition (capex→opex, elasticity, managed services, global reach); the shared-responsibility model at a concept level; Google Cloud’s main families by name — compute (Compute Engine, GKE, Cloud Run, App Engine, Cloud Functions), storage (Cloud Storage classes, Persistent Disk/Hyperdisk, Filestore), databases (Cloud SQL, Spanner, Bigtable, Firestore, BigQuery as an analytics warehouse), data/analytics (BigQuery, Dataflow, Pub/Sub, Looker), AI/ML (Vertex AI, the Gemini family, pre-trained APIs like Vision/Speech/Translation), networking (VPC, Cloud Load Balancing, Cloud CDN); the resource hierarchy (Organization → Folder → Project) at a concept level; pricing levers (pay-as-you-go, sustained-use discounts, committed-use discounts, Free Tier / $300 credit, Budgets); the value of data and AI to a business; modernisation paths (rehost/replatform/refactor; containers and serverless reduce toil).

CDL cheat sheet

• The pitch: managed services and global infrastructure let you focus on product, not undifferentiated heavy lifting; pay only for what you use.
• Pricing levers: sustained-use discounts apply automatically the longer a VM runs in a month; committed-use discounts are a 1- or 3-year commitment for a deeper cut; Free Tier + $300 credit for learning.
• Data value chain: ingest (Pub/Sub) → process (Dataflow) → store/analyse (BigQuery) → visualise (Looker/Looker Studio) → act (ML with Vertex AI).
• AI options, easiest first: pre-trained APIs (Vision/Speech/Translation) → AutoML/Model Garden → custom models on Vertex AI; Gemini for generative use cases.

Associate Cloud Engineer (ACE)

The flagship associate and the most useful single cert for an engineer. Hands-on and operational: set up an environment, plan and configure a solution, deploy and implement, ensure successful operation, and configure access and security. Expect gcloud, the Console, and a strong dose of IAM.

Checklist: projects, billing accounts, and the resource hierarchy; gcloud config/contexts and Cloud Shell; IAM deep enough to reason about basic vs predefined vs custom roles, the allow policy and inheritance, service accounts (default vs user-managed), keys vs impersonation, and Workload Identity Federation at a concept level; Compute Engine (machine types, images, startup scripts, snapshots, managed instance groups + autoscaling + autohealing, instance templates); GKE (create clusters/node pools, Autopilot vs Standard, deploy workloads, kubectl basics); Cloud Run and App Engine (deploy a container/app, traffic splitting); Cloud Storage (classes, lifecycle, IAM vs ACLs, signed URLs); Cloud SQL (create, HA, read replicas, connect); networking (VPC, subnets, firewall rules, Cloud NAT, Cloud Load Balancing types, Cloud DNS); operations (Cloud Monitoring, Cloud Logging, alerting, uptime checks, quotas); billing (budgets, alerts, exports); deploying with Deployment Manager/Terraform at a concept level; the gcloud/gsutil/bq command families.

ACE cheat sheet

• Right compute: scale-to-zero containers → Cloud Run; managed Kubernetes → GKE (Autopilot if you want no node management); lift-and-shift VMs / GPUs / special licensing → Compute Engine; simple web app/PaaS → App Engine; tiny event glue → Cloud Functions.
• IAM verbs: grant a role with gcloud projects add-iam-policy-binding; prefer predefined over basic (Owner/Editor/Viewer); use service accounts for workloads and impersonation over downloaded keys.
• MIG instincts: instance template + managed instance group = autoscaling + autohealing + rolling updates; regional MIG spreads across zones for resilience.
• Storage classes: Standard (hot) → Nearline (≥30 days) → Coldline (≥90) → Archive (≥365); set with lifecycle rules; prefer uniform bucket-level access (IAM) over object ACLs.
• Connect to Cloud SQL: the Cloud SQL Auth Proxy (or connectors) for secure connections; private IP keeps it off the public internet.

Professional Cloud Architect (PCA)

The senior, broadest, most respected Professional: design and plan a cloud solution architecture; manage and provision infrastructure; design for security and compliance; analyse and optimise processes; manage implementations; ensure solution and operations reliability. It is the exam with case studies, and the questions reward judgement under competing constraints.

Checklist: translating business and technical requirements into an architecture (the core PCA skill); the resource hierarchy, Organization Policy constraints, Shared VPC and landing-zone design; choosing compute (the Cloud Run/GKE/App Engine/Functions/Compute Engine decision) and data stores (the Cloud SQL/Spanner/Bigtable/Firestore/AlloyDB/BigQuery decision) against requirements; networking (VPC design, hybrid via Cloud VPN / Cloud Interconnect, global vs regional load balancing, Private Service Connect); reliability (SLOs/SLIs, multi-zone vs multi-region, RTO/RPO and DR patterns, backups); security & compliance (least-privilege IAM, CMEK with Cloud KMS, Secret Manager, VPC Service Controls, data residency, Assured Workloads); cost optimisation (committed-use discounts, right-sizing, the right managed service to cut toil); migration (the 7 Rs, Migrate to Virtual Machines, Database Migration Service, Transfer Service); managing implementation (Terraform/Infrastructure Manager, CI/CD, Config Connector); and the Architecture Framework pillars (operational excellence, security, reliability, cost optimisation, performance). The skill being tested is judgement, not recall — and the case studies supply the constraints.

PCA cheat sheet

• Compute decision: stateless HTTP that should scale to zero → Cloud Run; you need Kubernetes/portability/complex orchestration → GKE (Autopilot to minimise ops); legacy/specialised/GPU/licensing → Compute Engine; minimal-ops PaaS web app → App Engine; single-purpose event function → Cloud Functions.
• Data decision (one line each): relational + regional → Cloud SQL; relational + global, horizontally scalable, strong consistency → Spanner; PostgreSQL-compatible, high-performance/HTAP → AlloyDB; massive key-value / time-series / wide-column at low latency → Bigtable; serverless document DB with mobile/real-time sync → Firestore; analytics warehouse / SQL over petabytes → BigQuery.
• Hybrid connectivity: Dedicated/Partner Interconnect for high, consistent throughput and private RFC1918 reach; Cloud VPN (HA VPN) for cheaper/quicker or as Interconnect backup; Cloud Router for dynamic BGP routes.
• Hard security guarantee: Organization Policy constraints (preventive, org-wide), VPC Service Controls (data-exfiltration perimeter), CMEK for key control, least-privilege IAM with deny policies for explicit blocks.
• Reliability tiers: single-zone → multi-zone (regional MIG/GKE, Cloud SQL HA) → multi-region (Spanner, multi-region buckets, cross-region replicas) as RTO/RPO tighten.

The PCA case studies

The PCA exam attaches a small set of fictional companies, each with a business background, technical and business requirements, and an existing environment. A number of your questions reference one of these and are answerable only by matching an option to the case’s stated requirements. They are published in the official exam guide — read them before exam day and pre-decide the architecture each is steering you toward. The three current flagships:

How to use them. For each case, write yourself three notes before the exam: (1) the non-negotiable constraints (global scale, strong consistency, compliance, low latency, “reduce operational overhead”); (2) the data store the constraints imply (Mountkirk → Spanner + Bigtable; EHR → managed relational; HRL → BigQuery + Vertex AI); (3) the compute and networking pattern (almost always GKE or managed/serverless compute behind global load balancing, with hybrid connectivity where a migration is in flight). In the exam, when a question cites the case, the requirement keyword in the case text — “globally”, “strongly consistent”, “regulated”, “real-time”, “reduce overhead” — is the deciding constraint.

Professional Cloud DevOps Engineer

SRE and platform engineering: bootstrap a service-management environment; build and implement CI/CD; apply SRE practices (SLIs/SLOs/error budgets, toil reduction); implement observability; and optimise service performance. It overlaps with the SRE book — Google literally wrote it.

Checklist: the resource hierarchy and Terraform/Infrastructure Manager for bootstrapping; CI/CD with Cloud Build, Artifact Registry, Cloud Deploy (progressive rollouts), and deploying to GKE/Cloud Run; deployment strategies (blue/green, canary, rolling) and Binary Authorization for supply-chain control; SRE core: SLIs vs SLOs vs SLAs, error budgets and budget policies, toil, blameless postmortems; Cloud Operations suite (Cloud Monitoring metrics/dashboards/alerting, Cloud Logging sinks and Log Analytics, Cloud Trace, Error Reporting, Cloud Profiler, uptime checks); defining SLOs in Cloud Monitoring; alerting on burn rate; performance optimisation (latency, autoscaling, capacity). The exam rewards measuring reliability and automating away toil.

Cloud DevOps cheat sheet

• SLI/SLO/SLA: SLI = the measurement (e.g. % of fast, successful requests); SLO = the target for that SLI (e.g. 99.9%); SLA = the contract with consequences. Set SLOs tighter than SLAs.
• Error budget: 100% − SLO is the budget for failure; spend it on releases. Burn-rate alerts (fast + slow burn) beat static threshold alerts.
• CI/CD chain: Cloud Build (build/test) → Artifact Registry (store image) → Binary Authorization (only signed/approved images) → Cloud Deploy (promote dev→staging→prod with approvals and canary).
• Observability four: Monitoring (metrics/alerts), Logging (logs + sinks to BigQuery/Storage/Pub/Sub), Trace (latency/spans), Error Reporting (grouped exceptions); add Profiler for CPU/heap.
• Toil rule: if it is manual, repetitive, automatable and scales with load, automate it; track toil as a budget like errors.

Professional Cloud Security Engineer (PCSE)

The security specialist: configure access (IAM, identity), configure network security, ensure data protection, manage operations (logging, detection, response), and support compliance. Security questions also leak into PCA and DevOps, so this blueprint is broadly useful.

Checklist: IAM in depth (basic vs predefined vs custom roles, the allow policy and inheritance, IAM Conditions, deny policies, the Policy Troubleshooter, service accounts — keys vs impersonation and iam.serviceAccounts.actAs, Workload Identity Federation for keyless), Cloud Identity / directory, MFA, and organization policies; network security (firewall rules and hierarchical firewall policies, Cloud Armor WAF/DDoS, VPC Service Controls perimeters, Private Google Access, Cloud NAT, Identity-Aware Proxy / IAP, Secure Web Proxy); data protection (Cloud KMS with CMEK and envelope encryption, Cloud HSM/EKM, Secret Manager, Sensitive Data Protection / Cloud DLP for discovery and de-identification, default encryption at rest/in transit); operations (Security Command Center for posture and threats, Cloud Audit Logs — admin/data/system, log sinks, Chronicle at a concept level, incident response); compliance (Assured Workloads, data residency, Access Transparency/Approval, regulatory mappings).

PCSE cheat sheet

• Keyless first: prefer Workload Identity Federation and service-account impersonation over downloaded service-account keys (keys are the most-tested anti-pattern).
• Hard guarantees: Organization Policy constraints (preventive, org-wide), deny policies (explicit IAM block that overrides allows), VPC Service Controls (stops data exfiltration across a perimeter).
• Encryption layers: default at rest (Google-managed) → CMEK (your key in Cloud KMS) → CSEK/EKM (your key, externally held) → Cloud HSM (FIPS 140-2 L3). CMEK is the usual “we must control the key” answer.
• Audit: Admin Activity logs are always on and free; Data Access logs you must enable; route both to a sink for retention and Security Command Center for detection.
• Edge protection: Cloud Armor (WAF, DDoS, geo/IP rules) at the global load balancer; IAP to gate app access by identity without a VPN.

Professional Data Engineer (PDE)

Designing, building, operationalising, securing and monitoring data-processing systems, with a heavy BigQuery and pipeline focus and a growing ML slice. Expect storage-choice questions and a lot of Dataflow/BigQuery design.

Checklist: the storage decision (BigQuery for analytics; Bigtable for high-throughput low-latency NoSQL/time-series; Cloud SQL/Spanner/AlloyDB for transactional; Firestore for document; Cloud Storage for files/lake); ingestion with Pub/Sub (and Pub/Sub Lite legacy) and Datastream (CDC); processing with Dataflow (Apache Beam — streaming + batch, windowing, watermarks, exactly-once) vs Dataproc (managed Spark/Hadoop, lift-and-shift OSS) vs Dataform/dbt and Cloud Composer (Airflow) for orchestration; BigQuery deep (partitioning, clustering, slots vs on-demand, materialised views, BI Engine, BigLake, BigQuery ML, authorized views, row/column security); data quality and governance (Dataplex, Data Catalog, lineage); ML enablement (feature pipelines, Vertex AI hand-off); security (CMEK, DLP/Sensitive Data Protection, IAM on datasets, VPC Service Controls); reliability and cost (slot reservations, partition pruning, lifecycle).

PDE cheat sheet

• Pipeline choice: new streaming/batch, serverless, autoscaling → Dataflow (Beam); existing Spark/Hadoop to migrate or Spark-specific libraries → Dataproc; SQL transformations in the warehouse → Dataform/dbt; orchestrate DAGs → Cloud Composer (Airflow).
• Streaming ingest: Pub/Sub → Dataflow → BigQuery is the canonical real-time pattern; Datastream for database change data capture.
• BigQuery performance: partition by date/ingestion and cluster by high-cardinality filter columns to prune scanned bytes; on-demand (per-TB) vs slot reservations (predictable cost) for steady heavy use.
• Right store: analytics → BigQuery; time-series/IoT/very high write → Bigtable; global transactional → Spanner; mobile/document → Firestore; files → Cloud Storage.
• Govern: Dataplex for a lakehouse/governance layer; Sensitive Data Protection to find and de-identify PII; authorized/row/column-level views for least-privilege analytics.

Professional Machine Learning Engineer (PMLE)

The ML lifecycle on Google Cloud: framing problems, architecting ML solutions, preparing and processing data, developing models, and automating/orchestrating ML pipelines (MLOps), plus monitoring. Vertex AI is the centre of gravity, with a growing generative AI component.

Checklist: problem framing (regression/classification/recommendation/forecasting, metrics, when not to use ML); low-code options (AutoML, BigQuery ML, pre-trained APIs, Model Garden/Gemini); data prep (Vertex AI Feature Store, Dataflow/BigQuery for feature pipelines, managed datasets); training (custom training, distributed/GPU/TPU, hyperparameter tuning with Vizier, Workbench notebooks); serving (Vertex AI online/batch prediction, endpoints, autoscaling, private endpoints); MLOps with Vertex AI Pipelines (KFP/TFX), Model Registry, CI/CD for models, continuous training; monitoring (skew/drift detection, Model Monitoring, explainability with Vertex Explainable AI); responsible AI; and generative AI (prompt design, grounding/RAG, fine-tuning, evaluation). The exam increasingly rewards MLOps automation over one-off model training.

PMLE cheat sheet

• Low-code ladder: pre-trained API → BigQuery ML (SQL) → AutoML → custom training on Vertex AI; reach for the lowest rung that meets accuracy needs.
• Feature consistency: use Vertex AI Feature Store so training and serving use the same features (kills training/serving skew).
• MLOps: Vertex AI Pipelines for reproducible, automatable workflows; Model Registry for versioning; continuous training triggered by new data or drift.
• Serving: online endpoints for low-latency single predictions (autoscale, can be private); batch prediction for large offline scoring.
• Monitor: watch for training/serving skew and prediction drift; add Explainable AI for feature attributions and trust.

Professional Cloud Network Engineer (PCNE)

The networking specialist — the topic most engineers under-study: design, implement, manage and secure Google Cloud networks, including hybrid connectivity, load balancing, and network security and operations.

Checklist: VPC design (auto vs custom mode, subnets and secondary ranges, regional subnets, Shared VPC, VPC peering, routes); IP addressing (RFC1918, alias IPs, internal/external, IPv6); firewall rules and hierarchical firewall policies, network tags, service accounts in rules; Cloud Load Balancing in depth — the global vs regional, external vs internal, and application (L7) vs network (L4) matrix; Cloud CDN, Cloud Armor, SSL policies and certificates; Cloud DNS (public/private zones, peering, forwarding, DNSSEC, response policies); Cloud NAT and Private Google Access; Private Service Connect and service endpoints; hybrid (HA VPN, Cloud Interconnect Dedicated/Partner, Cloud Router/BGP, Network Connectivity Center); operations (VPC Flow Logs, Connectivity Tests, Network Intelligence Center, Packet Mirroring, monitoring).

PCNE cheat sheet

• Load balancer matrix: global external HTTP(S) → Global external Application LB; regional L7 → Regional external/internal Application LB; TCP/UDP/TLS pass-through → Network LB (external = pass-through, internal = internal NLB); internal microservice L7 → Internal Application LB. Global LBs use a single anycast IP.
• Private to Google APIs: Private Google Access (subnet flag) for VMs without external IPs; Private Service Connect for private access to Google/published services and producer/consumer patterns.
• Hybrid: Dedicated Interconnect (your own 10/100 Gbps link), Partner Interconnect (via a provider), HA VPN (encrypted over the internet, 99.99% SLA with two tunnels); Cloud Router exchanges routes via BGP.
• Egress control: Cloud NAT gives outbound internet without external IPs; firewall rules + hierarchical policies for ingress/egress; Cloud Armor at the LB edge.
• Troubleshoot: Connectivity Tests for path analysis, VPC Flow Logs for traffic, Firewall Insights for unused/over-broad rules.

Professional Cloud Database Engineer

The data-layer specialist: design scalable and highly-available database solutions, manage them, migrate data, deploy and operate, and monitor and troubleshoot. The signature skill is the database-selection decision and migration.

Checklist: the database-selection decision in depth (Cloud SQL vs Spanner vs Bigtable vs Firestore vs AlloyDB vs BigQuery — by consistency, scale, latency, model, and compatibility); Cloud SQL (MySQL/PostgreSQL/SQL Server, HA with regional/failover, read replicas, PITR, maintenance windows, Cloud SQL Auth Proxy, IAM database authentication); AlloyDB (PostgreSQL-compatible, columnar engine, read pools, high availability); Spanner (multi-region configs, processing units/nodes, interleaving and hotspot avoidance, TrueTime, external consistency); Bigtable (row-key design, app profiles, replication, single vs multi-cluster routing); Firestore (Native vs Datastore mode, indexes, multi-region); migration with Database Migration Service (homogeneous + heterogeneous, continuous CDC), the Spanner migration tooling, and assessment; security (CMEK, IAM, private connectivity); monitoring (Cloud Monitoring, query insights, slow queries) and HA/DR (RTO/RPO, cross-region replicas, backups).

Cloud Database Engineer cheat sheet

• Selection one-liners: regional relational, lift-and-shift MySQL/Postgres/SQL Server → Cloud SQL; demanding PostgreSQL, HTAP, big reads → AlloyDB; global, horizontally scalable, strongly consistent relational → Spanner; petabyte key-value/time-series, low latency, high write → Bigtable; serverless document + real-time/mobile sync → Firestore; analytics warehouse → BigQuery.
• Cloud SQL HA: regional (synchronous standby in another zone) for failover; read replicas (async, can be cross-region) for read scaling and DR; PITR via binary logs/WAL.
• Spanner scaling: size in processing units / nodes; avoid hotspots with non-sequential keys; interleave child tables for locality; TrueTime gives external consistency.
• Bigtable design: the row key is everything — design for even distribution and your query’s access pattern; avoid sequential keys (hotspotting).
• Migrate: Database Migration Service for managed, minimal-downtime migrations with CDC; assess source, replicate, then cut over.

Scenario practice questions with explained answers

This is the core of the kit. Work each one cold: read the stem, decide your answer, then read the explanation. Pay attention to the distractor analysis — being able to say why a wrong option is wrong is the skill the exam tests.

Q1 (ACE) — choosing compute

A team has a stateless containerised HTTP API with spiky, unpredictable traffic. They want it to scale to zero when idle, pay only for what they use, and run no servers or clusters. Which service?

A. Deploy to a GKE Standard cluster with the Horizontal Pod Autoscaler. B. Deploy to Cloud Run. C. Run it on a managed instance group of Compute Engine VMs with autoscaling. D. Deploy to App Engine flexible environment.

Answer: B. Cloud Run runs a container, autoscales on requests, scales to zero, and bills per request/CPU-time with no infrastructure to manage — exactly the three constraints.

Distractor analysis. A GKE Standard means you manage (and pay for) a cluster and nodes — it does not scale the cluster to zero cheaply and adds operational overhead. C a MIG keeps at least the minimum VMs you configure running and is heavier ops than serverless. D App Engine flexible runs on always-on VM instances (it does not scale to zero); App Engine standard can scale to zero but the cleanest “run a container, scale to zero, no servers” answer is Cloud Run.

Q2 (ACE) — least-privilege access for a workload

A Compute Engine VM needs to read objects from one Cloud Storage bucket and nothing else. What is the Google-recommended way to grant this?

A. Create a service-account key, download the JSON, and place it on the VM. B. Attach a service account to the VM and grant it the roles/storage.objectViewer role on that bucket. C. Grant the VM’s service account roles/editor on the project. D. Use the default Compute Engine service account with its default scopes.

Answer: B. Attach a dedicated service account and grant the predefined, narrowly-scoped role at the bucket level — least privilege, no keys to leak. This is the canonical Google-recommended pattern.

Distractor analysis. A downloaded service-account keys are the most-tested anti-pattern — they are long-lived secrets that leak; prefer attached identities/impersonation. C roles/editor is wildly over-broad (it can modify most resources in the project) — it violates least privilege. D the default Compute Engine service account is broadly privileged and shared; Google recommends a user-managed, purpose-scoped service account instead.

Q3 (PCA / Mountkirk) — globally consistent player data

Mountkirk Games needs the primary store for player profiles and game state to be relational, globally distributed, horizontally scalable, and strongly consistent across regions. Which database?

A. Cloud SQL for PostgreSQL with cross-region read replicas. B. Cloud Spanner with a multi-region configuration. C. Firestore in Native mode. D. Cloud Bigtable with multi-cluster replication.

Answer: B. Spanner is the only Google database that is relational, horizontally scalable, and externally (strongly) consistent across regions — precisely Mountkirk’s requirement.

Distractor analysis. A Cloud SQL scales vertically and its cross-region replicas are read-only and asynchronous — not globally writable or strongly consistent. C Firestore is a document store (not relational) and, while scalable, is not the relational/SQL fit the requirement states. D Bigtable is non-relational wide-column and is eventually consistent across clusters — great for telemetry, wrong for strongly-consistent relational state. (Bigtable is the right answer for Mountkirk’s high-throughput telemetry — a different question.)

Q4 (PCA / EHR) — hard data-exfiltration guarantee

EHR Healthcare must guarantee that data in their BigQuery datasets and Cloud Storage buckets cannot be exfiltrated to a project outside their trust boundary, even if a credential is compromised or an IAM policy is misconfigured. What enforces this?

A. Tighten IAM roles to least privilege on every dataset and bucket. B. Configure a VPC Service Controls perimeter around the projects holding the data. C. Enable Cloud Audit Logs and alert on suspicious access. D. Apply an Organization Policy that disables external IP addresses.

Answer: B. VPC Service Controls creates a service perimeter so even a valid credential cannot move data to a project/network outside the perimeter — a preventive, context-aware data-exfiltration guarantee.

Distractor analysis. A least-privilege IAM is necessary but insufficient — a correctly granted credential that is later stolen, or a misconfiguration, can still exfiltrate; the stem explicitly says “even if IAM is misconfigured”. C audit logs are detective, not preventive — they tell you after the fact. D disabling external IPs limits some egress paths but does not stop API-based data movement to another project using valid credentials; it is not a data-perimeter control.

Q5 (PCA / HRL) — real-time predictions

Helicopter Racing League wants to add real-time race outcome predictions with the least operational overhead, served to a global audience. Which approach?

A. Train and host a model on a self-managed GPU cluster on Compute Engine. B. Use Vertex AI to train/host the model and serve online predictions via an endpoint. C. Run predictions as nightly batch jobs in BigQuery. D. Build a bespoke serving service on GKE with your own autoscaling.

Answer: B. Vertex AI is the managed ML platform; an online prediction endpoint gives real-time inference with autoscaling and minimal ops — matching “real-time” and “least operational overhead”.

Distractor analysis. A a self-managed GPU cluster is the opposite of least overhead. C nightly batch predictions are not real-time. D hand-rolling serving on GKE adds operational overhead that the managed Vertex AI endpoint removes; the qualifier (“least operational overhead”) rules it out.

Q6 (PDE) — streaming vs batch processing

A retailer must process a continuous stream of clickstream events with windowed aggregations and exactly-once semantics, autoscaling with load and writing to BigQuery, with no clusters to manage. Which service?

A. Dataproc running a Spark Streaming job. B. Dataflow running an Apache Beam streaming pipeline. C. A Compute Engine VM running a custom consumer. D. BigQuery scheduled queries over raw files.

Answer: B. Dataflow (Apache Beam) is the serverless, autoscaling stream/batch processor with windowing, watermarks and exactly-once built in, writing natively to BigQuery — and there is no cluster to manage.

Distractor analysis. A Dataproc is managed Spark/Hadoop but you size and manage a cluster; choose it to migrate existing Spark/Hadoop, not for a new serverless streaming pipeline. C a custom VM consumer reinvents windowing, exactly-once and autoscaling — high toil, fragile. D scheduled queries are batch over data already landed; they are not a streaming processor.

Q7 (PDE) — BigQuery cost control

Analysts repeatedly run queries that filter a 50 TB events table by event_date and customer_id, and the per-query bytes scanned (and cost) are too high. What is the most effective fix?

A. Switch the table to on-demand pricing. B. Partition the table by event_date and cluster it by customer_id. C. Export the table to Cloud Storage and query externally. D. Add more slots via a reservation.

Answer: B. Partitioning by date lets BigQuery prune to the relevant partitions, and clustering by customer_id further reduces scanned bytes for that filter — directly cutting the bytes-scanned cost the stem describes.

Distractor analysis. A on-demand pricing is per-TB-scanned — it does not reduce the bytes scanned, so cost stays high. C querying external Storage is generally slower and not cheaper, and loses BigQuery’s pruning. D more slots changes capacity/pricing model (and on-demand has no slots to add); it does not reduce the bytes scanned that drive the cost here.

Q8 (PCSE) — keyless CI/CD to Google Cloud

A GitHub Actions pipeline must deploy to Google Cloud. Security policy forbids storing long-lived service-account keys anywhere. What should you use?

A. Create a service-account key and store it as a GitHub secret. B. Configure Workload Identity Federation so GitHub’s OIDC token is exchanged for short-lived Google credentials. C. Use a user’s gcloud credentials in the pipeline. D. Embed a key in the build image and rotate it monthly.

Answer: B. Workload Identity Federation lets an external identity (GitHub’s OIDC token) impersonate a service account and obtain short-lived credentials — no key to store or leak. This is the modern, exam-correct, keyless pattern.

Distractor analysis. A and D both store a long-lived key, which the policy (and Google’s guidance) forbids. C using a human user’s credentials in automation is an anti-pattern — non-auditable, over-privileged, and breaks when the user leaves. Federation is the only option that satisfies “no long-lived keys”.

Q9 (PCSE) — explicit, unconditional block

An organisation must ensure that no principal, regardless of any role they are granted, can delete Cloud Storage buckets in the production folder. What enforces this?

A. Remove roles/storage.admin from everyone in the folder. B. An IAM deny policy denying storage.buckets.delete for all principals on the folder. C. A bucket retention policy. D. An alert in Security Command Center.

Answer: B. An IAM deny policy evaluates before allow policies and an explicit deny cannot be overridden by any granted role — the only way to unconditionally block an action across a folder, regardless of allows.

Distractor analysis. A removing a role does not stop someone else granting it, or another role that includes the permission — not a guarantee. C a retention policy protects objects from deletion for a period; it does not stop bucket deletion broadly the way a deny policy does. D Security Command Center is detective. The “regardless of any role” wording is the tell for a deny policy.

Q10 (Cloud DevOps) — measuring reliability

A team wants to release faster but protect users from regressions. They need a way to express their reliability target and decide, objectively, when to slow down releases. What should they implement?

A. A 100% uptime SLA in the customer contract. B. SLOs with an error budget, alerting on burn rate. C. A manual change-approval board for every release. D. More integration tests in CI.

Answer: B. SLOs + error budgets turn reliability into a number; when the error budget is being consumed too fast (burn-rate alert), you slow releases — exactly the objective release-gating mechanism the stem asks for.

Distractor analysis. A 100% uptime is impossible and an SLA is a contract, not an operational signal; SLOs are set tighter than SLAs precisely so you act before breaching the SLA. C a manual board adds toil and is not data-driven. D more tests help quality but do not give a quantified reliability target or a release-gating signal.

Q11 (PCNE) — global low-latency web entry

A web application must be reachable on a single global anycast IP, route HTTP(S) traffic to the nearest healthy backend across multiple regions, and support a WAF. Which front door?

A. Regional external Application Load Balancer in each region with Cloud DNS round-robin. B. Global external Application Load Balancer with Cloud Armor. C. External Network (pass-through) Load Balancer. D. Internal Application Load Balancer.

Answer: B. The global external Application Load Balancer provides a single anycast IP, routes L7 traffic to the nearest healthy backend across regions, and integrates Cloud Armor (WAF/DDoS) — every requirement.

Distractor analysis. A per-region LBs plus DNS round-robin gives multiple IPs and DNS-based (not anycast) routing with slower failover. C a Network LB is L4 pass-through — no HTTP routing and no Cloud Armor at L7. D an internal LB is for traffic inside the VPC, not a public global front door.

Q12 (Cloud Database Engineer) — relational HA with read scaling

A regional PostgreSQL workload on Cloud SQL needs automatic failover for availability and to offload heavy reporting reads. What do you configure?

A. A single high-CPU instance. B. A regional (HA) Cloud SQL instance for failover plus one or more read replicas for reporting. C. Two independent instances with application-side sharding. D. Cloud Spanner.

Answer: B. A regional/HA Cloud SQL instance gives a synchronous standby for automatic failover, and read replicas (asynchronous) offload the reporting reads — the two requirements map to the two features.

Distractor analysis. A a single instance has no failover and no read offload. C application-side sharding is heavy custom work and does not provide managed HA. D Spanner is for global, horizontally scalable relational needs — overkill (and a re-platform) for a regional PostgreSQL workload that just needs HA + read replicas.

Q13 (PCA) — committed-use vs sustained-use vs spot

A workload runs a steady baseline of Compute Engine VMs 24/7 for the next two years, plus a fault-tolerant batch tier that can be interrupted. What is the most cost-effective purchasing mix?

A. On-demand for everything. B. Committed-use discounts for the steady baseline and Spot VMs for the fault-tolerant batch tier. C. Sustained-use discounts only. D. 3-year committed-use discounts for both tiers.

Answer: B. Committed-use discounts give the deepest cut for predictable, steady usage; Spot VMs are cheapest for interruptible, fault-tolerant work — matching each tier to its right discount.

Distractor analysis. A on-demand is the most expensive for steady usage. C sustained-use discounts apply automatically but are smaller than committed-use for known 24/7 baselines — leaving savings on the table. D committing the batch tier to a 3-year CUD wastes money because that tier is interruptible and variable — Spot is far cheaper for it; the fault-tolerance is the signal that Spot is safe.

Q14 (CDL) — the right pricing concept

A finance stakeholder asks how to get a predictable discount for databases and VMs the company knows it will run continuously for the next year. Which Google Cloud pricing mechanism applies?

A. Free Tier. B. Committed-use discounts (a 1- or 3-year commitment). C. Per-second billing. D. Network egress pricing.

Answer: B. Committed-use discounts trade a 1- or 3-year usage commitment for a significant, predictable price reduction — exactly “we know we will run this continuously”. (Sustained-use discounts also apply automatically to long-running VMs, but the commitment-for-discount concept the stakeholder describes is the CUD.)

Distractor analysis. A Free Tier is for low-volume/learning, not production commitments. C per-second billing is the granularity of charging, not a discount. D egress pricing is a cost driver, not a discount mechanism.

Commonly-confused services — the exam tips

A surprising share of associate- and professional-level questions reduce to telling two or three similar services apart. Burn these distinctions in — they decide more marks than any other single topic.

Cloud Run vs GKE vs App Engine vs Cloud Functions (vs Compute Engine)

Tip: “container, scale to zero, no servers” → Cloud Run. “Kubernetes / portability / mesh” → GKE (Autopilot to cut ops). “Tiny event-triggered function” → Cloud Functions. “Simple managed web app” → App Engine. “VMs / GPU / legacy / OS control” → Compute Engine.

Cloud SQL vs Spanner vs Bigtable vs Firestore vs AlloyDB

Tip: global + relational + strong consistency → Spanner. Regional relational / migrate an existing DB → Cloud SQL. Demanding PostgreSQL / HTAP / big reads → AlloyDB. Massive low-latency key-value / time-series → Bigtable. Document store with mobile/real-time sync → Firestore. (And analytics over petabytes is BigQuery, which is a warehouse, not an OLTP database.)

Dataflow vs Dataproc

Tip: new, serverless, streaming-or-batch, exactly-once → Dataflow. Existing Spark/Hadoop to migrate, or a Spark-specific library → Dataproc.

Hands-on lab — a free, self-marking practice harness

You cannot replicate the real exam, but you can build the habit of timed, scenario-style practice for free, and confirm a couple of the facts the questions hinge on. This lab spins up nothing chargeable — it uses read-only gcloud calls (which do not provision anything) and a tiny local quiz loop to drill the elimination technique. Run it in Cloud Shell or any machine with the Google Cloud CLI authenticated.

Step 1 — confirm a fact the exam will test (free, read-only): predefined roles exist for least privilege (Q2). List the storage object-viewer role to see it is a real, narrowly-scoped predefined role you would grant instead of roles/editor:

# Read-only: describes a predefined role. Provisions nothing, costs nothing.
gcloud iam roles describe roles/storage.objectViewer \
  --format="value(title, includedPermissions)"

Expected output: the title Storage Object Viewer and a short list of read-only storage.objects.* / storage.buckets.get permissions — proof that a narrow predefined role is available instead of a broad basic role.

Step 2 — confirm the keyless-vs-key fact (PCSE Q8), read-only. List service-account keys for a service account to see whether any long-lived user-managed keys exist (the anti-pattern); on a clean account you should see only Google-managed system keys:

# Replace with a real SA email in your project; read-only listing.
SA="$(gcloud iam service-accounts list --format='value(email)' --limit=1)"
gcloud iam service-accounts keys list --iam-account="$SA" \
  --format="table(name.scope(keys):label=KEY_ID, keyType, validAfterTime)"

Expected output: rows with keyType of SYSTEM_MANAGED (rotated by Google) and ideally no USER_MANAGED rows — the absence of user-managed keys is the lesson (prefer impersonation / Workload Identity Federation).

Step 3 — build a local timed quiz loop (no GCP, no cost). Save a few questions as JSON and drill them with a timer so you practise the budget (about two minutes each):

cat > /tmp/gcp-quiz.json <<'JSON'
[
  {"q":"Container, scale to zero, no servers to manage?","a":"Cloud Run"},
  {"q":"Global, relational, horizontally scalable, strongly consistent?","a":"Spanner"},
  {"q":"Stop data exfiltration across a trust boundary?","a":"VPC Service Controls perimeter"},
  {"q":"Keyless deploy from GitHub Actions to GCP?","a":"Workload Identity Federation"},
  {"q":"New serverless streaming+batch pipeline, exactly-once?","a":"Dataflow (Apache Beam)"},
  {"q":"Block an action for all principals regardless of role?","a":"IAM deny policy"}
]
JSON

python3 - <<'PY'
import json, time
qs = json.load(open("/tmp/gcp-quiz.json"))
score = 0
for i, item in enumerate(qs, 1):
    start = time.time()
    print(f"\nQ{i}: {item['q']}")
    input("  (think, then press Enter to reveal) ")
    print(f"  Answer: {item['a']}   [{time.time()-start:0.0f}s]")
    if input("  Did you get it right? (y/n) ").strip().lower() == "y":
        score += 1
print(f"\nScore: {score}/{len(qs)}  — aim for sub-120s per question.")
PY

Validation: Step 1 should print a short list of read-only storage permissions (proving the least-privilege option in Q2); Step 2 should show only SYSTEM_MANAGED keys (proving the keyless instinct in Q8); Step 3 reports your score and per-question time. If any single question took more than ~120 seconds, that is a topic to revise.

Cleanup: there is nothing chargeable to delete — only remove the temp file:

rm -f /tmp/gcp-quiz.json

Cost note: every command here is either a read-only API call (gcloud iam roles describe, ... keys list, ... service-accounts list — these describe/list and provision nothing) or runs locally. The lab cost is 0 and stays within the Free Tier. The lesson: build the timed-elimination habit before you pay for the real sitting.

Common mistakes & troubleshooting

Best practices

• Study from the official exam guide first. Each exam has a published guide listing the in-scope tasks and a “sample questions” set; it is the source of truth for what is testable, and the section weightings tell you where to spend hours.
• Read the PCA case studies cold, before exam day. They are published — pre-decide each company’s architecture so the case questions are recognition, not analysis, under time pressure.
• Build before you memorise. The portfolio projects in this course are the fastest route to durable knowledge; you remember a thing you deployed far longer than a thing you read.
• Practise the format, timed. Do full-length, timed mocks under exam conditions; managing ~50–60 scenario questions (plus case re-reading) in two hours is itself a skill.
• Keep a “confused services” sheet. Every time two services trip you up, write the one-line distinction. The three groups in this lesson (compute, databases, data processing) are the usual suspects.
• Default to the Google-recommended option. When two answers both work, the one using the managed/native service, least privilege, and no downloaded keys is almost always the intended answer.
• Climb in order. ACE before PCA; specialise (DevOps/PCSE/PDE/PMLE/PCNE/Database) after you can operate the platform. The Professionals assume associate-level fluency and punish gaps.
• Schedule the exam to create a deadline. Open-ended study expands to fill infinite time; a booked date focuses it. Note the re-take wait (14 days after a first fail, longer after subsequent ones) so you do not gamble a date you are not ready for.

Security notes

Certification study is also security study — much of every blueprint is security, and the habits transfer straight to production:

• Least privilege is the default exam-correct answer. When two options differ only by scope of permissions, the narrower predefined (or custom) role beats a basic role (Owner/Editor/Viewer). Carry that instinct into real IAM work.
• Prefer impersonation and Workload Identity Federation over downloaded keys. Questions offering “create and store a service-account key” versus “use Workload Identity Federation / attach a service account” almost always want the keyless option; the same is true in production.
• Preventive beats detective when the question says “guarantee”, “prevent”, or “regardless of role”. Organization Policy and IAM deny policies for hard guarantees; VPC Service Controls for exfiltration perimeters; Security Command Center and audit logs for detection. Know which the stem is asking for.
• Encrypt by default and control keys with Cloud KMS. CMEK, envelope encryption, and “we must hold the key” appear across every exam — and are table stakes in real systems; reach for EKM/Cloud HSM only when an external/FIPS requirement is stated.
• Do not practise against shared or production projects. Use a personal sandbox project with a budget alert for any hands-on study, so a study mistake never touches anything that matters.

Interview & exam questions

1. Q: When would you choose Cloud Run over GKE? A: When the workload is a stateless container that should scale to zero with minimal operational overhead and you do not need full Kubernetes (daemonsets, operators, mesh, node-level control). Choose GKE (Autopilot to cut ops) when you need Kubernetes portability or complex orchestration.

2. Q: Spanner vs Cloud SQL — what is the deciding factor? A: Global scale and strong consistency. Spanner is relational, horizontally scalable and externally consistent across regions; Cloud SQL is a regional relational database that scales vertically (with read replicas). If the requirement is “global, strongly consistent, horizontally scalable relational”, it is Spanner; if it is “regional relational” or “migrate an existing MySQL/Postgres”, it is Cloud SQL.

3. Q: Bigtable vs Firestore — when each? A: Bigtable for very high throughput, low-latency wide-column / time-series / IoT at petabyte scale (design the row key carefully). Firestore for document data with mobile/web real-time sync and simpler scaling needs.

4. Q: Dataflow vs Dataproc? A: Dataflow (Apache Beam) for new serverless batch or streaming pipelines with windowing and exactly-once and no cluster to manage. Dataproc for migrating existing Spark/Hadoop or when you need a specific OSS library; you manage (or ephemerally spin up) a cluster.

5. Q: How do you grant a workload access to one bucket using Google-recommended practice? A: Attach a dedicated service account to the workload and grant a narrow predefined role (e.g. roles/storage.objectViewer) scoped to that bucket — no downloaded keys, least privilege.

6. Q: How do you guarantee no principal can perform an action regardless of granted roles? A: An IAM deny policy. Deny rules are evaluated before allow rules and cannot be overridden by any granted role, giving an unconditional block at the org/folder/project scope.

7. Q: What stops data exfiltration even if a valid credential is compromised? A: VPC Service Controls — a service perimeter that prevents data in protected services (e.g. BigQuery, Cloud Storage) from being moved to projects/networks outside the perimeter, regardless of IAM.

8. Q: What is the keyless way to authenticate an external CI/CD system to Google Cloud? A: Workload Identity Federation — exchange the external system’s OIDC/SAML token for short-lived Google credentials via service-account impersonation, eliminating long-lived service-account keys.

9. Q: SLI vs SLO vs SLA, and how do error budgets gate releases? A: SLI = the measured reliability indicator; SLO = the internal target for it (set tighter than the SLA); SLA = the external contract with penalties. The error budget (100% − SLO) is spent on releases; a burn-rate alert firing means slow down or freeze releases until reliability recovers.

10. Q: Sustained-use vs committed-use discounts? A: Sustained-use discounts apply automatically the longer eligible VMs run within a month (no commitment). Committed-use discounts require a 1- or 3-year commitment for a deeper discount — the right choice for known, steady baseline usage; pair Spot VMs for fault-tolerant, interruptible work.

11. Q: Which load balancer for a single global anycast IP serving HTTP(S) with a WAF? A: The global external Application Load Balancer with Cloud Armor — one anycast IP, L7 routing to the nearest healthy backend across regions, WAF/DDoS at the edge.

12. Q: How does Google’s exam scoring work, and how should it change your strategy? A: Google reports a simple pass/fail — there is no scaled score and no per-domain breakdown shown to you. The commonly cited passing bar is roughly 70%. Because there is no wrong-answer penalty, answer every question, flag-and-review the hard ones, and calibrate readiness on your practice percentage, not a “how many can I miss” count.

Quick check

1. A stateless container must scale to zero with no servers to manage. Which compute service?
2. You need a relational database that is globally distributed and strongly consistent. Which service?
3. Which control prevents data exfiltration across a trust boundary even with a valid credential?
4. What is the keyless way to authenticate GitHub Actions to Google Cloud?
5. How is the Google Cloud exam scored, and should you ever leave a question blank?

Answers

1. Cloud Run — runs a container, autoscales on requests, scales to zero, no infrastructure to manage.
2. Cloud Spanner — the only Google database that is relational, horizontally scalable and externally (strongly) consistent across regions.
3. A VPC Service Controls perimeter — preventive and context-aware, it stops data leaving the perimeter regardless of IAM.
4. Workload Identity Federation — exchanges GitHub’s OIDC token for short-lived Google credentials, eliminating long-lived keys.
5. Pass/fail only (no scaled score; pass is roughly 70%). Never leave a question blank — there is no penalty for guessing.

Exercise

Pick the next exam you intend to sit and produce a one-page readiness plan of your own:

1. Download the official exam guide for your target (e.g. PCA) and copy its domain table with weightings; for the PCA, also read all three case studies.
2. Self-score 1–5 per domain on honest current confidence, then multiply each gap by the domain weighting to get a priority score — study the highest-priority gaps first.
3. Write your own three “confused-services” cards for the groups you personally muddle (compute, databases, data processing), plus any others.
4. For a case-study exam, write a one-line architecture verdict per case (Mountkirk → Spanner + Bigtable + global LB; EHR → managed DBs + GKE multi-region + compliance; HRL → Vertex AI + CDN + BigQuery).
5. Draft a four-week plan using the template below, ending with two timed full-length mocks, and book the exam for the end of week four — moving it only if your timed mocks are not yet consistently at/above ~70%.

Four-week study-plan template (adapt to your timeline and exam):

Certification mapping

This lesson is the readiness layer for the entire Google Cloud ladder: the foundational Cloud Digital Leader; the Associate Cloud Engineer; and the Professionals — Cloud Architect (PCA), Cloud DevOps Engineer, Cloud Security Engineer (PCSE), Data Engineer (PDE), Machine Learning Engineer (PMLE), Cloud Network Engineer (PCNE), and the Cloud Database Engineer. The domain checklists and weightings map directly to each official exam guide; the practice questions are tagged by exam; the case-study section targets the PCA’s Mountkirk/EHR/HRL items specifically; the confused-services section targets the compute, database and data-processing decisions that decide the most questions across ACE/PCA/PDE/Database; and the scoring/format notes apply to every exam in the catalogue.

Glossary

• Pass/fail result: Google reports only whether you passed; there is no scaled score and no per-domain percentage shown. The commonly cited passing bar is roughly 70%.
• Multiple-select item: a question requiring you to select N correct options (“choose TWO/THREE”); scored as a unit with no partial credit.
• Case study: a persistent scenario (company background, business and technical requirements, existing environment) attached to the PCA (and some other Professionals); several questions reference it, and the requirements are the answer key.
• Distractor: an incorrect answer option deliberately designed to look plausible; analysing why it is wrong is the core study skill.
• Qualifier: the deciding phrase in a stem (most cost-effective / least operational overhead / Google-recommended / fewest steps) that chooses between technically-correct options.
• Domain weighting: the published percentage of an exam devoted to a domain; used to budget study time.
• Sustained-use discount (SUD): an automatic discount that grows the longer eligible Compute Engine resources run within a month — no commitment required.
• Committed-use discount (CUD): a deeper discount in exchange for a 1- or 3-year commitment to a baseline of usage; the right lever for known steady workloads.
• IAM deny policy: a policy that explicitly denies permissions and is evaluated before allow policies, so an explicit deny cannot be overridden by any granted role.
• VPC Service Controls: a service perimeter that prevents data in protected services from being exfiltrated to projects/networks outside the perimeter, independent of IAM.
• Workload Identity Federation: a keyless mechanism that exchanges an external identity’s token (e.g. GitHub OIDC) for short-lived Google credentials via service-account impersonation.

Next steps

You now have the checklists, the question-working technique, the PCA case-study verdicts, the confused-services distinctions, and a plan. Turn study into proof by building the real thing: continue to the Google Cloud Capstone — Build an Enterprise Landing Zone + 3-Tier App, which exercises the ACE/PCA/Security blueprints end to end. For depth on the topics the questions probe, revisit the Google Cloud Architecting Ladder, Portfolio Projects, IAM Fundamentals, and the troubleshooting playbooks (single-service and multi-service RCA). Book the date, work the plan, and pass.