Examkin

Question

Difficulty: HardDisaster Recovery and Business Continuity Execution

A financial SaaS company hosts a transactional service on Google Cloud using a warm standby disaster recovery topology. The compute layer uses Compute Engine Managed Instance Groups (MIGs) deployed in primary region `us-central1` and secondary region `us-east4`. The database layer relies on Cloud SQL for PostgreSQL in `us-central1` with a cross-region read replica in `us-east4`. During an unexpected total outage of `us-central1`, the disaster recovery plan mandates achieving a Recovery Time Objective (RTO) of less than 15 minutes and a Recovery Point Objective (RPO) of less than 1 minute. When executing the emergency failover, the operations team observes that attempting to scale out the secondary MIG in `us-east4` fails due to regional CPU quota exhaustion, while application traffic is still attempting to connect to `us-central1`. Which sequence of execution steps should the cloud architect mandate to successfully complete the disaster recovery failover within the target metrics?

  1. Promote the cross-region Cloud SQL read replica in `us-east4` to a standalone primary database instance, utilize pre-committed or reserved compute capacity in `us-east4` while requesting an emergency quota increase, and update Cloud DNS records with a low TTL to route traffic to the `us-east4` load balancer.Answer
  2. B
    Restore the database in `us-east4` from the latest automated Cloud Storage nightly backup export, recreate the Compute Engine instances via automated Terraform scripts, and re-point the global HTTP(S) Load Balancer backend service to the new instances.
  3. C
    Migrate the database workload during the incident to a multi-region Cloud Spanner instance to achieve automated zero-RPO cross-region synchronization and eliminate the need for manual replica promotion.
  4. D
    Force MIG autoscaling in `us-east4` without requesting quota adjustments, and configure temporary VPC Network Peering from `us-east4` to `us-central1` to allow instances in the secondary region to query the primary Cloud SQL instance until `us-central1` recovers.

Answer

Promote the cross-region Cloud SQL read replica in us-east4 to a standalone primary database instance, utilize pre-committed or reserved compute capacity in us-east4 while requesting an emergency quota increase, and update Cloud DNS records with a low TTL to route traffic to the us-east4 load balancer.
Executing a successful DR failover within tight RTO (< 15 min) and RPO (< 1 min) metrics requires promoting existing cross-region database replicas, leveraging pre-reserved compute resources to overcome regional quota bottlenecks, and shifting traffic via DNS updates.

Step-by-Step Solution

1
Evaluate data replication status and promote the secondary database
Cloud SQL cross-region read replica in us-east4 is promoted to a standalone read-write primary instance, preserving data written right up to the outage (RPO < 1 minute).
Promoting an asynchronous/semi-synchronous cross-region replica is the standard GCP pattern for achieving minimal data loss without rebuilding the database.
2
Address compute capacity limits in the secondary region
Application workloads run on pre-reserved VM capacity in us-east4 while an emergency regional quota request is processed to handle additional burst traffic.
Relying purely on dynamic autoscaling during a regional disaster can fail if regional quotas or resource availability in the failover region are constrained.
3
Execute traffic switchover via DNS routing
Client connections shift from us-central1 endpoints to the us-east4 load balancer.
Updating DNS records with low Time-To-Live (TTL) or using Cloud DNS routing policies allows external clients to quickly resolve to the new operational regional ingress point.

Key Concept

Disaster Recovery Execution for Relational Databases and Compute Capacity Management
Rate this question

Topics

Disaster Recovery and Business Continuity Execution

More questions from this topic