Question

Difficulty: HardDisaster Recovery and Business Continuity Execution

An enterprise analytics application processes real-time telemetry and is deployed across two Google Cloud regions: `us-central1` (primary) and `us-west1` (secondary). The application uses Google Kubernetes Engine (GKE) clusters in both regions for stateless processing and a multi-region Cloud Bigtable instance for low-latency time-series data storage. A major regional utility failure renders all compute resources in `us-central1` completely unavailable. The disaster recovery plan mandates failing over active operations to `us-west1` with minimal Recovery Time Objective (RTO) while ensuring incoming client traffic is redirected and database operations resume cleanly. Which TWO operational steps must the response team execute to complete the disaster recovery failover?

  1. Update the Cloud Bigtable app profile configuration to enforce single-cluster routing pointing to the cluster in `us-west1`.Answer
  2. Update the Cloud DNS failover routing policy or Global External Load Balancer backend service configuration to direct client traffic exclusively to the GKE ingress in `us-west1`.Answer
  3. C
    Route traffic from `us-west1` through `us-central1`'s Cloud Router via VPC Network Peering to reach on-premises data centers during the outage.
  4. D
    Initiate a manual restore of the database in `us-west1` from the latest scheduled export file stored in Cloud Storage.
  5. E
    Submit a quota increase request for Compute Engine vCPUs in `us-west1` immediately after declaring the disaster recovery event.

Answer

To execute disaster recovery failover, the team must update the Cloud Bigtable app profile to direct database requests to the healthy cluster in the secondary region and update Cloud DNS routing or Global Load Balancer backends to direct ingress traffic to the secondary GKE deployment.
During a regional failover, operational execution requires redirecting application traffic to healthy compute infrastructure and ensuring stateful service app profiles or endpoints route requests to active database clusters in the surviving region. Updating Cloud Bigtable app profiles to target the surviving cluster and updating Cloud DNS/Load Balancing endpoints ensures rapid restoration of service with minimal RTO.

Step-by-Step Solution

1
Redirect database traffic at the application layer
Database queries from the secondary region are routed directly to the local, healthy Cloud Bigtable cluster.
Reconfiguring the app profile allows application instances in the surviving region to issue reads and writes against the local Bigtable cluster immediately.
2
Redirect incoming user and ingress traffic to the surviving region
Client traffic bypasses the impacted primary region and routes to the secondary GKE cluster.
Updating Cloud DNS routing policies or global load balancing backend weights ensures all public traffic is served by operational infrastructure.

Key Concept

Disaster Recovery Execution for Replicated Services and Traffic Steering
Rate this question