professional-cloud-data-engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise runs a mission-critical Cloud SQL for PostgreSQL database deployed across multiple Google Cloud regions:
StudyCerts
StudyCertsdb-central): Deployed in us-central1 with High Availability (HA) enabled.db-west): Cross-region read replica in us-west1.db-east): Cross-region read replica in us-east1.A catastrophic outage renders the entire us-central1 region unavailable. You need to execute an emergency failover to promote db-west to the new primary while minimizing data loss, redirecting application traffic with minimal downtime, and restoring read and HA topology.
Which operational procedure should you execute?
Trigger synchronous promotion of db-west to enforce RPO=0, retain the instance name of db-east when re-attaching it to db-west, and update local DNS records to point client traffic to db-west.
Initiate immediate promotion of db-west using gcloud CLI, update client connection strings to the static IP address of db-west, and allow Cloud SQL to automatically switch the replication master of db-east to db-west.
Perform a graceful switchover between db-central and db-west, preserve the existing db-east read replica connection, and rely on Point-in-Time Recovery (PITR) during the 15-minute promotion window.
Inspect received versus replayed WAL records on db-west, promote db-west using replica failover so the DNS write endpoint updates, enable High Availability on the newly promoted primary, and recreate the db-east replica pointing to db-west under a new instance name.
Trigger synchronous promotion of db-west to enforce RPO=0, retain the instance name of db-east when re-attaching it to db-west, and update local DNS records to point client traffic to db-west.
Initiate immediate promotion of db-west using gcloud CLI, update client connection strings to the static IP address of db-west, and allow Cloud SQL to automatically switch the replication master of db-east to db-west.
Perform a graceful switchover between db-central and db-west, preserve the existing db-east read replica connection, and rely on Point-in-Time Recovery (PITR) during the 15-minute promotion window.
Inspect received versus replayed WAL records on db-west, promote db-west using replica failover so the DNS write endpoint updates, enable High Availability on the newly promoted primary, and recreate the db-east replica pointing to db-west under a new instance name.
In Cloud SQL for PostgreSQL, cross-region replication operates asynchronously. When an unplanned regional disaster incapacitates the primary instance in us-central1, disaster recovery requires manually or programmatically promoting a designated cross-region read replica to assume the read-write primary role.
db-west via a PostgreSQL client to check pg_catalog.pg_last_wal_receive_lsn() and pg_catalog.pg_last_wal_replay_lsn() verifies that the replica has fully applied all write-ahead log (WAL) transactions received from the primary before the outage, preventing stale or partially applied state upon promotion.us-west1 without necessitating application redeployment.db-east replica of the failed primary must be deleted and recreated pointing to the new us-west1 primary using a distinct instance name.This procedure correctly addresses data consistency verification, dynamic application routing via DNS endpoints, and the architectural requirement to rebuild orphaned sibling read replicas from the new primary.