Question

Difficulty: Very hardDisaster Recovery and Business Continuity Execution

An enterprise web application running in primary region `us-central1` uses Cloud SQL for PostgreSQL with a cross-region read replica in `us-east4` for disaster recovery. Compute Engine Managed Instance Groups (MIGs) are deployed in both regions behind a Global External HTTP(S) Load Balancer with backends configured in both regions. Following a catastrophic, unexpected regional failure in `us-central1`, the architecture team must execute their disaster recovery runbook to restore complete write functionality and serve application traffic from `us-east4` with an Recovery Time Objective (RTO) of less than 15 minutes. Which TWO steps must the operations team perform as part of this regional disaster recovery failover process?

  1. Promote the cross-region Cloud SQL read replica in `us-east4` to a standalone primary database instance and update the application configuration in `us-east4` to point to the promoted instance.Answer
  2. Verify that backend instances in `us-east4` pass HTTP load balancer health checks, allowing the Global External HTTP(S) Load Balancer to automatically redirect global client traffic away from the unresponsive `us-central1` backends.Answer
  3. C
    Initiate an automated database restore from a scheduled Cloud Storage cold backup file directly into a newly provisioned Cloud SQL instance in `us-east4` to ensure database integrity.
  4. D
    Reconfigure the load balancer's health check path to query the backend database endpoint directly, ensuring HTTP requests are dropped until the database finishes failover.

Answer

The correct execution steps are promoting the cross-region read replica in the standby region to a standalone primary database instance, and allowing the Global External HTTP(S) Load Balancer to automatically reroute client traffic to healthy backends in the secondary region.
In a regional disaster recovery event involving a Warm Standby or Active-Passive pattern, promoting a Cloud SQL cross-region read replica enables write operations in the secondary region within minutes, satisfying stringent RTO constraints. Simultaneously, using a Global External HTTP(S) Load Balancer allows automatic routing of incoming web traffic to healthy Compute Engine backends in the secondary region as soon as health checks fail in the primary region.

Step-by-Step Solution

1
Assess the state of the primary database during a regional disaster in `us-central1`.
Confirm that `us-central1` is completely unavailable and promote the cross-region read replica in `us-east4` to a standalone read-write primary Cloud SQL instance.
Cloud SQL cross-region replicas continuously stream updates. Promoting the replica makes it a writable master without waiting for lengthy disk backups or new database instance provisioning, meeting the RTO requirement of under 15 minutes.
2
Ensure compute application traffic failover via the Global External HTTP(S) Load Balancer.
Confirm backend health check responses from the MIG in `us-east4` so the Global Load Balancer drains traffic from `us-central1` and sends it to `us-east4`.
Global External HTTP(S) Load Balancing provides built-in multi-region failover. When primary backends fail health probes, the load balancer dynamically routes traffic to healthy backends in secondary regions without manual DNS TTL propagation delays.

Key Concept

Disaster Recovery Execution and Multi-Region Failover Patterns in GCP
Estimated Time:3m 0s
Rate this question