View Professional Cloud Database Engineer Exam Questions

Q: 1

Your ecommerce application connecting to your Cloud SQL for SQL Server is expected to have additional traffic due to the holiday weekend. You want to follow Google-recommended practices to set up alerts for CPU and memory metrics so you can be notified by text message at the first sign of potential issues. What should you do?

Options

Discussion

Robin Feb 18, 2026 6:47 pm

Makes sense to pick D here. Cloud Monitoring lets you set alert policies on CPU and memory no code required, and SMS can be configured as a notification channel. A is way more complex than needed. Pretty sure D is Google's best practice, but open to other opinions.

Jack R. Feb 24, 2026 1:53 pm

I don't think B is right here. D is the only option that natively supports alerting for CPU and memory with SMS through Cloud Monitoring. Error Reporting doesn't do general metric monitoring, it's more for logs/exceptions. Anyone see a reason you'd use B?

RileyJ Feb 22, 2026 12:01 am

C vs D but I think D has it. Cloud Monitoring lets you set up alerts on CPU/memory and add SMS with like two clicks, no extra scripts or workarounds. C is more for custom stuff. Not 100% though, anyone got different take?

Morgan Feb 25, 2026 3:34 am

C or D? I picked C since Pub/Sub could send messages and you can process them for SMS, so it seems flexible if you want integration. But not totally sure since Cloud Monitoring is more direct for alerts. Did anyone go with C here?

Jason Feb 21, 2026 7:28 pm

Yeah, D is the move. Cloud Monitoring does the alerting and you can add SMS directly as a notification channel, no need to build anything extra. Pretty sure that's how Google wants it set up, correct me if I'm missing something.

Aisha X. Feb 18, 2026 9:17 pm

Totally agree with D, Cloud Monitoring has built-in SMS alerts. No custom code needed here. D

Neha Z. Mar 2, 2026 1:53 pm

Option C the question is really clear about notification methods.

Be respectful. No spam.

Q: 2

Your organization is running a MySQL workload in Cloud SQL. Suddenly you see a degradation in database performance. You need to identify the root cause of the performance degradation. What should you do?

Options

Discussion

Emma Mar 2, 2026 3:02 am

Option B, Logs let you dig deeper, but first thing is to check metrics like CPU and memory in Cloud Monitoring. A is tempting but can miss the bigger picture.

Drew G. Mar 3, 2026 5:52 am

A , Logs Explorer should highlight any error spikes or slow queries logged by MySQL. I usually start there for quick clues when performance drops. Not 100% sure it's the fastest way here though.

Ben Feb 27, 2026 1:28 am

Don’t think A is right here. B lets you check CPU, memory, and storage metrics in real time, which almost always show where the slowdown starts with Cloud SQL. If you’ve hit performance issues before, that’s usually the first place to look. Pretty sure it’s B.

Daniel G. Feb 25, 2026 2:05 am

Its A

Rowan M. Mar 5, 2026 3:02 pm

B makes the most sense. Cloud Monitoring gives you real-time visibility into CPU, memory, and disk usage, which are usually behind performance drops in Cloud SQL. Logs (A) are helpful but more for digging deeper after spotting an issue. Pretty sure B is the right first move.

IvyJ Feb 22, 2026 3:27 am

B , Cloud Monitoring gives a quick view of resource bottlenecks that usually cause Cloud SQL slowdowns. A looks tempting but is more for digging into specific events after you know something’s up. Pretty sure B is what Google expects here. Disagree?

Grace B. Mar 6, 2026 12:05 am

A is wrong, B. Metrics from Cloud Monitoring show resource issues way quicker for Cloud SQL performance hits.

Be respectful. No spam.

Q: 3

Your company has PostgreSQL databases on-premises and on Amazon Web Services (AWS). You are planning multiple database migrations to Cloud SQL in an effort to reduce costs and downtime. You want to follow Google-recommended practices and use Google native data migration tools. You also want to closely monitor the migrations as part of the cutover strategy. What should you do?

Options

Discussion

Sean Feb 26, 2026 6:46 am

Option A fits best since Database Migration Service (DMS) is Google's native tool, and it's designed for both one-time and minimal-downtime migrations with monitoring built in. Pretty sure that's what Google wants you to pick here, but open if anyone has counterpoints!

Sam Q. Feb 25, 2026 12:24 pm

A. matches official guide recommendations for native migrations. I’ve seen similar on practice tests too.

Nora Mar 3, 2026 10:44 pm

Maybe D makes more sense, since sometimes partner tools are used along with Database Migration Service when you want more monitoring or advanced migration features. Not 100% sure though, feels like a common trap in these questions.

Kevin Feb 16, 2026 4:59 pm

A tbh

Olivia B. Mar 3, 2026 9:11 pm

A since the question says to use native Google tools and doesn't mention ongoing CDC. Unless I'm missing a scenario?

Jason Q. Feb 28, 2026 9:12 pm

Saw this on a practice recently, pretty sure it's A.

Layla G. Feb 24, 2026 6:35 am

Probably A, I remember a similar question in an exam report and DMS is the Google-native choice.

Owen C. Feb 16, 2026 7:36 am

A is correct, official guide and exam practice both point to Database Migration Service for this.

ChloeV Mar 2, 2026 1:06 pm

Its A here, Google specifically recommends the Database Migration Service for these use cases and you can monitor everything through their console. Nothing in the scenario calls for CDC or third-party tools. Pretty sure but open to other views.

Nathan X. Feb 17, 2026 5:37 am

A imo

Be respectful. No spam.

Q: 4

You are choosing a new database backend for an existing application. The current database is running PostgreSQL on an on-premises VM and is managed by a database administrator and operations team. The application data is relational and has light traffic. You want to minimize costs and the migration effort for this application. What should you do?

Options

Discussion

Arjun J. Mar 4, 2026 4:47 am

B . Firestore and Spanner are expensive or need app changes, pretty sure D is a trap since it's more admin effort.

Anita T. Feb 25, 2026 5:24 am

Its B, but only if there’s no weird PostgreSQL extensions in use that Cloud SQL can’t support.

Alex Feb 16, 2026 1:39 am

B , Cloud SQL for PostgreSQL is almost a drop-in with way less admin work. D feels like a trap because you still manage the VM, so not really minimizing effort. Unless I'm missing something about feature requirements?

Anita Feb 24, 2026 1:43 pm

B from exam reports, Cloud SQL for PostgreSQL is what comes up when minimizing migration and cost are main priorities. Firestore and Spanner both need more app changes or budget. Not 100 percent but I've seen this pattern.

Ben Y. Feb 28, 2026 4:17 pm

Option D this whole managed platform upcharge annoys me. Just spin up PostgreSQL on Compute Engine, same as on-prem so migration is dead simple and you keep total control. Yeah, pretty sure that's what I'd do if worried about cost.

EthanB Feb 18, 2026 2:58 am

Not sure but B, is the best fit. I saw a similar scenario on a mock test, and Cloud SQL for PostgreSQL keeps it managed and low effort since it matches the existing tech. Firestore or Spanner would need app changes or more budget. Not 100 percent but sure enough.

Nina Feb 28, 2026 3:35 pm

B tbh

LeoQ Feb 17, 2026 11:53 pm

Cloud SQL for PostgreSQL (B) makes the most sense here. It's fully managed, supports PostgreSQL natively, so migration is low effort, and you avoid the overhead of managing VMs. Firestore and Spanner both mean a bigger refactor or higher cost, and running on Compute Engine is just more ops work again. Pretty sure B matches the goal of low cost and smooth migration. Agree?

Be respectful. No spam.

Q: 5

You want to migrate an on-premises mission-critical PostgreSQL database to Cloud SQL. The database must be able to withstand a zonal failure with less than five minutes of downtime and still not lose any transactions. You want to follow Google-recommended practices for the migration. What should you do?

Options

Discussion

SkepticalMentor8154 Mar 5, 2026 2:08 am

D pretty sure. HA makes the instance regional so zonal failures are handled, matches the RTO requirement.

Ava A. Feb 25, 2026 6:56 pm

D. but notice that if this was about cross-region resiliency (not just zonal), you'd have to go deeper than HA alone. For zonal failure and <5m downtime though, HA covers it per Google docs.

Nina P. Feb 26, 2026 12:21 am

D , enabling HA makes the database regional in Cloud SQL so you get failover if a whole zone goes down. That matches the <5 min RTO requirement and transaction safety. Other options miss the point for zonal failures, I think.

Sean T. Feb 27, 2026 12:53 pm

Not sure why you'd pick B here, even though CDC sounds cool. For less than 5 min downtime and no lost transactions on zonal failure, D is Google's recommended HA approach. Think B is a trap for DIY folks.

Skyler C. Feb 20, 2026 6:09 pm

Lots of practice tests highlight D as the way to handle zonal failure in Cloud SQL. Official docs confirm it too. D

IvyZ Feb 14, 2026 2:48 pm

Hard to say, D since enabling HA in Cloud SQL makes the database regional, which covers zonal failure and meets the <5 min downtime. The other options don't guarantee seamless failover or transaction safety under a full zone outage. Pretty sure that's what Google expects for this scenario, but open to other takes if anyone disagrees.

Kevin W. Feb 22, 2026 5:04 pm

C vs D, but C looks tempting for cross-region but misses the zonal failover with sub-5min RTO part.

Quinn A. Feb 27, 2026 11:21 pm

Probably D here, that's the only choice with regional HA built in for Cloud SQL.

Ava J. Mar 1, 2026 10:51 am

D here. Enabling HA makes the Cloud SQL instance regional, so a zonal failure triggers quick failover and no transaction loss. Pretty sure that's what Google recommends for under 5 minutes downtime.

Emma A. Mar 3, 2026 9:06 pm

B
I'm leaning toward B because a CDC pipeline lets you continuously replicate transactions, which should help minimize downtime and avoid losing changes. Nightly snapshots (A) seem riskier, but with CDC you capture all activity in near real time. Not 100% sure if this is the official way Google recommends though. Disagree?

Be respectful. No spam.

Q: 6

Your company is evaluating Google Cloud database options for a mission-critical global payments gateway application. The application must be available 24/7 to users worldwide, horizontally scalable, and support open source databases. You need to select an automatically shardable, fully managed database with 99.999% availability and strong transactional consistency. What should you do?

Options

Discussion

QuickTester9830 Mar 2, 2026 6:34 pm

Honestly, Google keeps pushing Spanner but I always think Cloud SQL could handle these if you pick the right engine and size it up. My choice is B. It claims high availability and supports open source DBs like Postgres and MySQL, so seems workable for most global apps. Maybe I overlook the auto sharding though, not sure.

Karan I. Mar 3, 2026 7:37 pm

D imo, Cloud Spanner is the only one here with global scaling, auto-sharding and that strict 99.999% SLA plus strong consistency. The others either can't hit those uptime guarantees or aren't natively globally distributed. Unless "open source" meant strict MySQL/Postgres required, D's the one. Disagree?

Ryan Feb 23, 2026 4:40 pm

B. Cloud SQL actually supports open source engines so I picked that. Not sure if it can hit 99.999% or global horizontal scaling but seemed right for open source part.

Maya I. Feb 28, 2026 5:55 pm

I don’t think Cloud SQL (B) meets the 99.999% SLA or global auto-sharding requirements. Spanner (D) is specifically built for that, even if it’s not native open source. Trap here is picking B just for MySQL/Postgres compatibility.

KaranR Feb 20, 2026 3:33 am

C/D? Cloud SQL (B) supports open source but can't do global scale or 99.999% like Spanner. D fits.

Chloe G. Feb 24, 2026 10:50 am

Probably D. Only Spanner gives automatic sharding, global distribution, and true 99.999% SLA with strong consistency. Cloud SQL doesn't scale worldwide at that level. Pretty sure this is the only fit for mission-critical use.

Rowan Q. Feb 18, 2026 12:40 pm

Maybe B, since Cloud SQL supports open source databases and high availability, though Spanner's sharding is tempting.

Karan V. Feb 15, 2026 3:44 pm

Its D here. Cloud Spanner is built for global scale, auto-sharding, and strong consistency with super high (99.999%) availability. Cloud SQL can't match that uptime or scale across regions. Pretty sure Spanner fits this best.

Be respectful. No spam.

Q: 7

Your team is running a Cloud SQL for MySQL instance with a 5 TB database that must be available 24/7. You need to save database backups on object storage with minimal operational overhead or risk to your production workloads. What should you do?

Options

Discussion

Casey S. Feb 27, 2026 5:12 am

I'm not convinced by B or C here. Those both add steps and could still hit performance, especially with a huge 5TB DB. Serverless exports (A) are designed to avoid production impact and automate the job, which matches minimal ops overhead. I'm pretty sure that's the intent, since D is a classic trap for high load cases.

Robin J. Mar 6, 2026 1:13 am

I don't think it's D, that's more manual and can load the prod instance. A avoids that risk and automates the job.

Priya E. Feb 25, 2026 2:34 am

D , since a lot of practice dumps and labs show using mysqldump on the primary for exports. Thought it was the standard way, but maybe there's a better GCP-native route. Would double-check the official guide because these scenarios can trip you up.

Casey F. Feb 17, 2026 8:04 am

A imo, serverless exports are made for this use case. Minimal ops work and no extra stress on prod DB, which you need with 24/7 uptime. The other options add risk or steps, so I think A fits best. Disagree?

Vikram D. Feb 22, 2026 10:48 am

B or C here. Creating a read replica and using mysqldump seems like a safe choice since it won't affect the primary workload directly, which matters for 24/7 uptime. The official Google cloud SQL docs and some practice exams cover backup strategies pretty well, but I might be missing something subtle about serverless exports vs replica dumps.

AvaP Mar 5, 2026 3:24 pm

Had something like this in a mock, definitely A. Serverless exports go straight to Cloud Storage and don't put extra load on prod. The other options risk downtime or add manual steps, pretty sure that's not what Google tests here. Agree?

Riley G. Mar 1, 2026 5:07 am

Not D, running mysqldump on primary is risky for prod load. A is built for low overhead and safety.

Logan T. Feb 24, 2026 12:40 am

Option D (if the DB is under heavy load, direct mysqldump could actually cause downtime).

RyanW Feb 25, 2026 8:35 am

A , serverless exports in Cloud SQL are built for this. D is a typical pitfall but it hits the live database and adds risk. I think A's what Google expects for least ops overhead, unless I'm missing some special scenario.

Jack F. Mar 6, 2026 10:09 am

Ugh, Google keeps adding new features after every cert update. Not D, A is what they want now. Serverless exports let you dump to Cloud Storage without touching the prod instance, so there's less risk and way less manual work involved. Pretty sure that's what they're testing here, but happy to hear arguments for B or C if I'm missing something.

Be respectful. No spam.

Q: 8

You are designing a new gaming application that uses a highly transactional relational database to store player authentication and inventory data in Google Cloud. You want to launch the game in multiple regions. What should you do?

Options

Discussion

Jordan X. Feb 21, 2026 9:31 am

D since Cloud SQL with regional read replica could work for multi-region, pretty sure it's a trap because it isn't truly global transactional but seems plausible if you don't catch the consistency detail.

Piya U. Feb 15, 2026 6:15 am

For me, A for this one, since Cloud Spanner is the only option that gives true global consistency and handles high transactions. D looks close but only covers regional, so it's a bit of a trick. Anyone see it differently?

RobinS Feb 22, 2026 11:45 am

Spanner (A) is built for global scale, strong consistency, and lots of transactions at once. Cloud SQL can't handle multi-region writes, so it's not ideal here. Pretty sure about this but let me know if I'm missing something.

Parker A. Feb 14, 2026 1:59 pm

Honestly not D, since regional replicas can't guarantee transactions globally. A is made for this use case.

AveryE Feb 20, 2026 6:34 am

A imo, pretty sure that's what the official guide recommends for multi-region transactional workloads. Saw similar in practice tests too.

Nathan Feb 14, 2026 1:52 pm

Why does Google keep making Cloud SQL sound like it works for global transactions? This one is A all day.

Amelia D. Feb 21, 2026 11:00 am

If high transactional consistency is needed across multiple regions, Cloud Spanner (A) is the only real fit. Cloud SQL with replicas can't do cross-region write consistency. I think it's A unless they're asking for something less strict around transactions.

Casey T. Mar 4, 2026 12:35 am

A tbh, since Spanner is designed for global, highly transactional apps. D is regional, so doesn't really fit multi-region needs.

Be respectful. No spam.

Q: 9

You are the DBA of your organization. You provided a cloned instance from the production Cloud SQL for PostSQL database to the developers for testing purposes. After the creation of the clone. Your developers notice missing data in one of the recently altered tables. What should you do to ensure that all data in included?

Options

Discussion

Nathan H. Feb 21, 2026 5:59 am

Luna L. Feb 22, 2026 8:57 pm

Had something like this in a mock, C fits best. PITR will include all changes up to a specific point, so any recent alters or missing data should be covered. Dumps can miss new data if not timed right. Pretty sure C is what they want here, but open if someone spots a detail I missed.

Aisha Feb 26, 2026 7:52 pm

I think C. Using PITR ensures all changes, including recent alters, are included in the cloned instance. Dumps or backups might miss new data if taken before the change. Let me know if someone sees a catch here, but this matches what I’ve seen in practice.

Ajay W. Mar 2, 2026 11:44 pm

A is off here, C is what you need since PITR ensures all latest changes are included in the clone.

FriendlyAuditor6456 Feb 20, 2026 9:44 am

C vs D but I'm confident it's C. PITR will let you restore the clone after all recent changes, including any ALTERs, so you catch new data. D is a common distractor unless unlogged tables were involved, which isn’t specified here.

Logan L. Feb 20, 2026 11:12 pm

It’s C here. PITR means you can clone the current production database to a state after any recent table alterations, so you don’t miss data added or changed after the initial clone. D looks tempting but only matters if those tables were UNLOGGED, which isn’t stated. Seen similar question in practice sets.

Reese K. Feb 25, 2026 8:52 am

Option D

Cameron Mar 3, 2026 5:06 am

C vs D here, but pretty sure C is right. PITR gets all the latest changes after table alters, while D's focus on unlogged tables is a bit of a trap in this scenario. Seen similar advice in practice sets, but open if anyone disagrees.

Vikram I. Feb 21, 2026 6:34 am

C tbh. Using PITR with a fresh clone will pull in all the recent changes, including those new table alterations and data that might’ve been missed before. Standard dumps or older backups could leave out recent stuff. Someone correct me if I’m missing something obvious!

HelpfulAnalyst2997 Feb 19, 2026 12:54 am

Not sure C or D, but leaning C.

Be respectful. No spam.

Q: 10

You have a non-critical business application running on Google Kubernetes Engine (GKE) in the app- dev VPC. You have created an AllayDB cluster with private Service Access (PSA) and no public IP address in the db-dev VPC. You want your application to securely connect to AllowDB in a cost- effective way. What should you do?

Options

Discussion

Ajay G. Feb 22, 2026 10:31 pm

Option B fits since the app is non-critical and PSA already provides secure path, so direct private IP avoids extra cost or setup. If the VPCs weren’t peered, that’d change the answer. Anybody else disagree?

Riley K. Feb 19, 2026 12:09 pm

Maybe B. is the way for cost-effective and secure since proxies add needless complexity here. D is kind of a trap.

Vikram Y. Feb 20, 2026 4:17 pm

Does the question state that app-dev and db-dev VPCs are already peered, or is it just assumed because of PSA? If not, how would direct private IP (B) even work without peering in place?

MethodicalAuditor6447 Mar 6, 2026 8:33 am

B , just use the private IP with PSA. No need to overengineer with proxies or VPN for a non-critical app, PSA handles security inside the VPC. Pretty sure that's what Google expects here.

Parker W. Mar 1, 2026 1:35 pm

Its B. Private IP access between VPCs is the most straightforward and cost-effective here unless you need extra auth or crossing different projects.

Ivy T. Feb 15, 2026 11:32 pm

B , direct private IP with PSA is all you need in this case given the non-critical app and cost concern.

Riley Feb 17, 2026 11:34 am

Its B, no need for proxy (C/D) because PSA already makes the private IP secure. VPN (A) is overkill here.

Jamie H. Feb 23, 2026 1:35 pm

Nah, C's tempting but I think B is right. For non-critical apps needing simple and cheap connections, direct private IP does the trick-Auth Proxy adds unnecessary complexity here. PSA handles security already. Anybody see a downside?

Be respectful. No spam.

Question 1 of 20 · Page 1 / 2

Premium Access Includes

✓ Quiz Simulator
✓ Exam Mode
✓ Progress Tracking
✓ Question Saving
✓ Flash Cards
✓ Drag & Drops
✓ 3 Months Access
✓ PDF Downloads

Get Premium Access

Premium Access Includes

FLASH OFFER

avail 10% DISCOUNT on YOUR PURCHASE