Google Cloud Professional Cloud Database Engineer Study Guide

Domain 1: Design scalable, highly available cloud database solutions

Key concepts you must know · 235 practice questions

Match the workload to the service: Cloud SQL for standard managed MySQL, PostgreSQL, or SQL Server; AlloyDB for high-performance, PostgreSQL-compatible transactional and analytical workloads; Cloud Spanner for globally distributed, horizontally scalable relational data with strong consistency.
Choose Bigtable for high-throughput, low-latency wide-column NoSQL (time series, IoT, analytics) and Firestore for serverless document data with real-time sync and mobile/web SDKs.
Use Memorystore (Redis or Memcached) as a managed in-memory cache to reduce read latency and offload the primary database.
Cloud Spanner scales horizontally by adding nodes or processing units and shards data automatically; design a schema that avoids hotspots (do not use monotonically increasing keys as the primary key).
Bigtable performance depends on row-key design: distribute writes evenly and keep related reads contiguous; field promotion and salting avoid hotspotting, and you scale by adding nodes.
For relational HA, Cloud SQL offers a regional high-availability configuration with a synchronous standby in another zone and automatic failover; AlloyDB provides a 99.99% SLA with automatic failover.
Cloud Spanner provides 99.999% availability for multi-region instances and continues serving through zone and region failures with no manual failover.
Right-size for cost and performance: pick instance/machine types, storage type (SSD vs HDD for Bigtable), and autoscaling appropriately, and use committed use discounts for steady workloads.
Decide consistency requirements up front: Spanner and Cloud SQL give strong consistency; Bigtable is eventually consistent across clusters in a replicated instance; Firestore offers strong consistency for document reads and queries.
Design read scaling with read replicas (Cloud SQL, AlloyDB read pools) and cross-region replicas for read-local latency and disaster recovery.

Domain 2: Manage a solution across multiple database technologies

Key concepts you must know · 180 practice questions

Operate managed databases through the console, gcloud, Terraform, and the APIs; automate provisioning and configuration as infrastructure as code for repeatability.
Secure databases with IAM for control-plane access, database-native users for data-plane access, and least-privilege roles; prefer IAM database authentication where supported (Cloud SQL, AlloyDB).
Encrypt data at rest by default with Google-managed keys, or use customer-managed encryption keys (CMEK) in Cloud KMS when policy requires key control; encryption in transit uses SSL/TLS.
Restrict connectivity with private IP (VPC), Private Service Connect, and the Cloud SQL Auth Proxy rather than exposing public IPs; use authorized networks only when public access is unavoidable.
Manage capacity and cost: monitor utilization, enable storage auto-increase for Cloud SQL, scale Spanner nodes/processing units, and use Bigtable autoscaling to match throughput.
Automate operational tasks with maintenance windows, scheduled backups, and Cloud Scheduler; understand that maintenance can cause brief restarts and plan windows accordingly.
Use Cloud Monitoring and Cloud Logging across all database services for a single operational view, with alerting policies on key metrics.
Apply Query Insights (Cloud SQL, AlloyDB) and Key Visualizer (Bigtable, Spanner) to diagnose slow queries and access-pattern hotspots.
Govern data with labels for cost tracking, organization policies for guardrails, and VPC Service Controls to reduce data-exfiltration risk around database services.
Plan patching and version upgrades: managed services handle minor patching, but you plan major-version upgrades (for example Cloud SQL Postgres upgrades) and test them first.

Domain 3: Migrate data solutions

Key concepts you must know · 169 practice questions

Use Database Migration Service (DMS) for homogeneous and supported heterogeneous migrations (for example MySQL/PostgreSQL to Cloud SQL or AlloyDB) with continuous replication for minimal downtime.
Choose a migration strategy - lift-and-shift, replatform, or refactor - based on downtime tolerance, source engine, and the target service's compatibility.
Continuous (change data capture) migrations keep the source and target in sync so you can cut over with minimal downtime; one-time migrations suit small datasets or acceptable downtime windows.
Use Datastream for serverless change data capture and replication from operational databases into BigQuery, Cloud Storage, or other targets for analytics.
For heterogeneous migrations (for example Oracle or SQL Server to PostgreSQL/AlloyDB), assess schema and code conversion effort; DMS conversion workspaces help convert schema and code objects.
Validate a migration by comparing row counts, checksums, and application behavior before cutover, and keep a rollback plan.
Right-size the target before cutover and load-test it, since the source's sizing may not map directly to the managed target.
Minimize cutover risk by promoting the migration job at a low-traffic window, updating connection strings, and monitoring replication lag until it reaches zero.
Migrate large analytical or file-based datasets with the BigQuery Data Transfer Service, Storage Transfer Service, or bulk loads, choosing the tool that matches source and volume.
Account for network throughput and security during migration: use private connectivity, and for very large datasets consider Transfer Appliance or interconnect capacity.

Domain 4: Deploy scalable, highly available databases and ensure DR

Key concepts you must know · 145 practice questions

Deploy Cloud SQL in a regional HA configuration (primary plus synchronous standby) for automatic zonal failover; add read replicas for read scaling and cross-region replicas for DR.
Enable automated backups plus point-in-time recovery (PITR) on Cloud SQL and AlloyDB so you can restore to a specific timestamp after data corruption or accidental change.
Define RPO and RTO first, then choose the pattern: synchronous HA gives near-zero RPO within a region, while cross-region replicas or backups give regional DR with a larger RPO.
For Cloud Spanner, choose a multi-region configuration to survive region failure automatically with strong consistency and no manual failover.
Replicate Bigtable across clusters/regions in one instance for availability and read locality; app profiles control single-cluster vs multi-cluster routing and failover behavior.
Firestore offers multi-region locations for higher availability and durability; pick the location at database creation because it cannot be changed later.
Test disaster recovery regularly: perform restore drills, replica promotions, and failover tests, and document the runbook so recovery is repeatable.
Promote a cross-region read replica to a standalone primary during a regional outage, then repoint the application; understand this is a manual DR step for Cloud SQL.
Use maintenance windows, deletion protection, and backup retention policies to protect production instances from accidental disruption or deletion.
Monitor replication lag, failover events, and backup success, and alert on them so availability objectives are actually met, not just configured.

Google Cloud Professional Cloud Database Engineer exam tips

Build a decision table mapping requirements to services: global strong consistency -> Spanner; PostgreSQL-compatible high performance -> AlloyDB; standard managed relational -> Cloud SQL; high-throughput wide-column -> Bigtable; serverless document/real-time -> Firestore; caching -> Memorystore; analytics -> BigQuery. Most questions hinge on one deciding constraint.
Know HA vs DR precisely: Cloud SQL regional HA (synchronous standby, automatic zonal failover) protects against zone failure with near-zero RPO, while cross-region replicas and backups (with PITR) protect against region loss with a larger RPO and manual promotion.
For Bigtable and Spanner, schema and key design is the exam's favorite performance topic: avoid monotonically increasing or sequential keys, distribute writes to prevent hotspots, and use Key Visualizer to diagnose access patterns.
For migrations, default to Database Migration Service with continuous (CDC) replication for minimal-downtime cutovers, use Datastream when the target is analytics/BigQuery, and always validate row counts and replication lag before promoting.
Prefer private connectivity and IAM database authentication with CMEK where policy demands key control; recognize the Cloud SQL Auth Proxy and private IP as the secure-by-default connection pattern over public IP with authorized networks.

Study guide FAQ

What is the format of the Professional Cloud Database Engineer exam?

It is a two-hour exam of roughly 50-60 multiple-choice and multiple-select questions, taken online-proctored or at a test center. Google does not publish a fixed numeric passing score; results are reported as pass or fail. The certification is valid for two years.

Do I need to know how to write SQL and design schemas?

Yes, at a design level. You should understand relational and NoSQL data modeling, indexing, and query performance, and be able to design Spanner and Bigtable keys that avoid hotspots. The exam focuses on choosing and configuring the right Google Cloud service more than on writing complex queries.

When should I choose AlloyDB over Cloud SQL for PostgreSQL?

Choose AlloyDB when you need higher performance, a 99.99% availability SLA, fast analytical queries on transactional data (columnar engine), and read pools for scale, while staying PostgreSQL-compatible. Cloud SQL for PostgreSQL is the simpler, lower-cost managed option for standard workloads that do not need AlloyDB's performance and scale.

How does the exam test migrations?

Expect scenarios that ask you to pick a migration approach and tool: Database Migration Service for minimal-downtime homogeneous and supported heterogeneous migrations with continuous replication, Datastream for CDC into analytics targets, and the right validation and cutover steps (row/checksum validation, replication lag reaching zero, rollback plan).

Is CertGrid's study guide official Google material?

No. CertGrid is an independent practice platform and is not affiliated with or endorsed by Google. This guide distills the concepts and scenarios the exam emphasizes so you can review efficiently, but always confirm the current objectives on the official Google Cloud certification page before your exam.

Related Google resources

Test yourself: 729 Google Cloud Professional Cloud Database Engineer practice questions