We’ve just released our Professional Cloud Database Engineer practice exams!
There are 5 full length practice exams, with 250 realistic questions to help you pass.
I’ve included 3 preview questions at the bottom of this article.
Since this was in such high demand, we decided to release these practice exams while we work on the video lessons for this course, in case you want to get started.
You might be wondering, how does the Professional Cloud Database Engineer (PCDBE) certification compare to the Professional Data Engineer (PDE) certification?
The PCDBE is more focused on database admin work. Optimizing, managing, and migrating databases. It focuses on all GCP databases, but more on Cloud SQL, AlloyDB, Spanner.
The PDE is focused on the broader data lifecycle. Data ingestion, data processing, data analytics. Cloud SQL, AlloyDB, and Spanner are still relevant, but it focuses more on BigQuery, Bigtable, Cloud Storage, Dataflow, Dataproc, etc.
The PCDBE is a great companion to the PDE - a little easier to study for, but still challenging and impressive to have on your resume.
I hope you enjoy the practice exams. Everything is up to date and aligned with the latest version of the certification.
All my best,
Ben
P.S. Join my free Circle Community for GCP tips, office hours, live streams and webinars!
A healthcare analytics company runs a Cloud SQL for MySQL instance that stores patient billing transactions updated throughout the day. After a recent incident where an automated script accidentally overwrote critical records, the engineering team needs the ability to restore the database to any specific second within the past seven days to reverse such errors. What should you do to meet this requirement?
Choose only ONE best answer.
A) Enable automated backups and binary logging on the instance
B) Configure automated backups with a 7-day retention window
C) Provision a high-availability instance with automatic failover
D) Create a cross-region read replica to maintain a redundant copy
Take a moment to think through this question. The key phrase here is "any specific second" and that level of granularity is the real challenge to solve.
Option A suggests enabling both automated backups and binary logging together. Automated backups give you full snapshots of the database at regular intervals, while binary logging captures every individual change that happens between those snapshots. Together, they let you reconstruct the database state at any arbitrary moment in time. That sounds promising, but let's look at the other options before deciding.
Option B talks about configuring a 7-day retention window on automated backups. A seven-day window matches the time range mentioned in the question, which makes it tempting. But automated backups alone only let you restore to the exact moments when those snapshots were taken. If the script corrupted the data two hours after the last backup ran, those two hours of valid transactions would be gone. There is no way to land on an arbitrary second between backup points without something filling in the gaps.
Option C proposes provisioning a high-availability instance with automatic failover. HA failover is designed to protect against infrastructure problems like a zone going down or a hardware failure. It continuously mirrors the primary database to a standby. But if bad data gets written to the primary, it gets mirrored to the standby too. There again is no mechanism here to roll back to a point before the error happened.
Option D suggests creating a cross-region read replica. Like the HA option, replicas stay synchronized with the primary in near real time. That is great for distributing read traffic or surviving a regional outage, but it offers no protection against logical data errors like an accidental overwrite. The bad data would unfortunately propagate to the replica almost immediately.
The critical requirement is recovering to any specific second, not just the last backup checkpoint.
A) Enable automated backups and binary logging on the instance.
A healthcare technology company runs a Cloud SQL database that powers a patient scheduling platform used across multiple states. The platform experiences sudden surges in usage during flu season and other health events. Leadership has mandated that the database architecture must withstand a full regional failure and that the team must be able to validate the disaster recovery workflow in a safe manner that does not impact production workloads. The solution must also align with aggressive RPO and RTO commitments outlined in the company's service level agreements. Which approach best meets these requirements?
Choose only ONE best answer.
A) Deploy a cross-region failover replica and test database cloning
B) Configure an external replica in a separate VPC and test instance migration
C) Establish a zonal standby instance and test point-in-time recovery
D) Create a cross-region read replica and test promotion of the read replica
Take a moment to work through this one carefully. There are two distinct requirements here: surviving a full regional failure, and being able to validate the recovery process safely without touching production. Both need to be satisfied by the same approach.
Option A suggests a cross-region failover replica paired with database cloning as the test mechanism. The cross-region part sounds promising. But cloning creates an independent snapshot of the database at a point in time, which is useful for other purposes but does not actually exercise the failover path that would be invoked during a real regional outage. You would be testing something different from what you would actually need to execute under pressure.
Option B proposes an external replica in a separate VPC with instance migration as the test. External replicas introduce significant networking complexity that is not part of Cloud SQL's native replication and promotion capabilities. In an emergency, that added complexity could slow down recovery rather than speed it up. Testing instance migration also does not map directly to what a regional failover would look like in practice, which undermines the goal of validating the actual DR workflow.
Option C recommends a zonal standby instance and testing point-in-time recovery. A zonal standby only protects against failures within a single availability zone and would do nothing during a broader regional outage, which is exactly the scenario leadership is worried about. Point-in-time recovery is a valuable tool for data corruption scenarios, but it is not the mechanism that gets invoked when an entire region goes dark.
Option D proposes a cross-region read replica with promotion as the test. A cross-region replica keeps a continuously synchronized copy of the primary database in a geographically separate region, directly addressing the regional failure requirement. And crucially, promoting the replica to a standalone primary is exactly the operation that would be performed during a real disaster. Testing simulates recovery and also validates the actual failover path. Promotion can also be tested without disrupting the original production database, satisfying the mandate to keep DR testing safe.
The critical requirements are surviving a regional failure and validating the real recovery workflow without impacting production.
D) Create a cross-region read replica and test promotion of the read replica.
A healthcare technology company manages patient appointment data in Cloud SQL and stores billing records in Cloud Spanner. Both systems are hosted on Google Cloud. The analytics team needs to build dashboards and generate reports using specific fields from these databases, but company policy prohibits giving analysts direct login credentials to any production database. The team also wants to minimize infrastructure overhead and avoid maintaining separate copies of the data. The company already has BigQuery as its central analytics platform and wants analysts to query everything through BigQuery while ensuring only approved tables and columns are visible. What should the data engineering team do?
Choose only ONE best answer.
A) Configure the analytics tools to connect directly to the production databases using read-only database roles limited to specific schemas
B) Create BigQuery views containing EXTERNAL_QUERY statements that reference the production databases and grant analysts access only to those views
C) Build read replicas of the production databases in separate Cloud SQL and Cloud Spanner instances and give analysts read-only credentials to the replicas
D) Set up scheduled data pipelines to extract the relevant tables from the production databases into BigQuery datasets and provide analysts with access to those datasets
There are several constraints here. No direct production credentials for analysts, no separate copies of the data, BigQuery as the single query interface, and column-level access control.
Option A suggests connecting analytics tools directly to production databases using read-only roles. The read-only scoping sounds reasonable, but this approach still requires issuing database-level credentials to analysts or their tools, which company policy explicitly prohibits. It also bypasses BigQuery as the centralized analytics platform entirely, which goes against the stated architecture.
Option B proposes creating BigQuery views that use EXTERNAL_QUERY statements pointing at the production databases, then granting analysts access only to those views. BigQuery supports federated queries against Cloud SQL and Cloud Spanner natively, meaning the data can be queried in place without being moved or duplicated. The views act as a controlled access layer. Analysts only see the tables and columns the views expose, which enforces the column-level restrictions the company requires. Credentials to the production databases stay within the service account layer and never reach individual analysts.
Option C suggests building read replicas of both production databases and giving analysts read-only credentials to those replicas. This addresses the concern about touching production, but it creates separate infrastructure to manage and still requires handing out database credentials to analysts. Both of those things are ruled out by the stated constraints. It also means maintaining additional Cloud SQL and Cloud Spanner instances, which adds operational overhead rather than reducing it.
Option D proposes scheduled pipelines that copy data from the production databases into BigQuery datasets. This does centralize analytics in BigQuery, which sounds appealing at first. But it creates duplicated datasets that need ongoing maintenance, refresh cycles to stay current, and synchronization logic to handle schema changes. That directly contradicts the requirement to avoid maintaining separate copies of the data.
The critical requirements are no production credentials for analysts, no data duplication, BigQuery as the single interface, and column-level access control.
B) Create BigQuery views containing EXTERNAL_QUERY statements that reference the production databases and grant analysts access only to those views.
Thanks for reading! To get access to the rest of the 250 practice questions, click here.
