Question

Difficulty: EasyDisaster Recovery and Business Continuity Execution

An enterprise application hosted in a primary Google Cloud region experiences a total regional failure. The cloud operations team must execute the Disaster Recovery (DR) failover runbook to switch service to a warm standby environment in a secondary region. What is the correct chronological sequence of operational steps to safely complete this failover?

  1. 1Promote the cross-region database replica in the secondary region to a standalone primary database.
  2. 2Scale up compute resources in the secondary region from standby capacity to full production capacity.
  3. 3Update Cloud DNS record sets to point incoming application traffic to the secondary region's HTTP(S) Load Balancer.
  4. 4Perform validation testing and monitor application metrics to confirm operational stability in the secondary region.

Answer

The correct operational order is: first promote the secondary database replica to primary, second scale up secondary compute capacity, third update Cloud DNS to redirect traffic, and fourth verify application performance and system health.
Executing a disaster recovery failover requires establishing data write availability first, provisioning sufficient compute capacity second, rerouting external traffic third, and finally verifying post-cutover system health.

Step-by-Step Solution

1
Promote cross-region database replica
Database in secondary region becomes writable and ready for application write operations
Application services cannot function correctly without a writable database tier
2
Scale up standby compute instances/clusters
Secondary region compute capacity matches production workload requirements
Prevents immediate compute resource exhaustion when traffic shifts
3
Modify Cloud DNS routing policy to point to secondary load balancer
User network requests begin migrating to the secondary region endpoint
Directs live traffic to the newly prepared secondary environment
4
Execute system health checks and monitoring validation
Confirms application functionality, latency, and error rates remain within SLOs
Validates business continuity execution success

Key Concept

Disaster Recovery Failover Execution Workflow
Rate this question