An enterprise runs a mission-critical Cloud SQL for PostgreSQL database deployed across multiple Google Cloud regions: Primary instance (db-central): Deployed in us-central1 with High Availability (HA) enabled. Disaster recovery replica (db-west): Cross-region read replica in us-west1. Reporting replica (db-east): Cross-region read replica in us-east1. Application tier: Connects to the database cluster via the Cloud SQL DNS write endpoint. 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?

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.: ### What the Solution Is 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. ### How It Meets All Requirements * **Minimizing Data Inconsistency and Loss:** Connecting to `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. * **Application Connectivity and Routing:** Performing a replica failover automatically updates the Cloud SQL **DNS write endpoint** to route incoming application write traffic directly to the newly promoted primary in `us-west1` without necessitating application redeployment. * **High Availability & Topology Restoration:** Because cross-region replicas do not inherit HA automatically if not pre-configured, High Availability must be enabled on the promoted instance. Furthermore, Cloud SQL does not automatically re-parent sibling read replicas; the former `db-east` replica of the failed primary must be deleted and recreated pointing to the new `us-west1` primary using a distinct instance name. ### Key Advantages * **Guarantees Transactional Completeness:** Assesses WAL replay progress to avoid promoting an instance with unprocessed buffered WAL files. * **Transparent Application Redirection:** Utilizes DNS write endpoint abstraction to re-route client connection pools seamlessly. * **Restores Fault Tolerance:** Re-establishes regional HA and cross-region analytical offloading. ### Why This Is Optimal 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.

Cloud Sql Cross Region Failover Promotion Topology | professional-cloud-data-engineer

Cloud Sql Cross Region Failover Promotion Topology

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.

An enterprise runs a mission-critical Cloud SQL for PostgreSQL database deployed across multiple Google Cloud regions:

Primary instance (db-central): Deployed in us-central1 with High Availability (HA) enabled.
Disaster recovery replica (db-west): Cross-region read replica in us-west1.
Reporting replica (db-east): Cross-region read replica in us-east1.
Application tier: Connects to the database cluster via the Cloud SQL DNS write endpoint.

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?

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.

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.

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.

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.

Professional Cloud Data Engineer

Cloud Sql Cross Region Failover Promotion Topology

Related questions