Examkin

Question

Difficulty: Very hardDisaster Recovery and Business Continuity Execution

A financial platform uses a Warm Standby disaster recovery architecture across two Google Cloud regions: `us-central1` (primary) and `us-east4` (secondary). Database state is continuously synchronized across regions using Cloud Spanner. The application tier runs on Google Kubernetes Engine (GKE) clusters in both regions. The `us-east4` application VPC is peered to a central hub VPC in `us-central1` that hosts core IAM and compliance microservices, while the `us-central1` application VPC is also peered directly to the same hub VPC. During a primary region outage in `us-central1`, the operations team updates Cloud DNS to direct traffic to the `us-east4` external Application Load Balancer and triggers GKE cluster scaling in `us-east4`.

Following the failover, incoming user requests to `us-east4` time out because pods cannot establish connections with the hub VPC microservices. Furthermore, GKE pod scaling stalls due to immediate CPU quota exhaustion in `us-east4`.

Which combination of architectural modifications and failover procedures will correctly eliminate these single points of failure and fulfill a Recovery Time Objective (RTO) of under 15 minutes?

  1. Deploy redundant compliance microservices in `us-east4` connected directly to the local VPC, eliminate reliance on transitive VPC peering across regions, and establish pre-allocated Compute Engine capacity reservations with pre-approved quota increases in `us-east4`.Answer
  2. B
    Enable custom route exports on the existing VPC Network Peering connections between the hub and spoke VPCs to allow transitive routing to `us-central1` during failover, and configure automated quota request scripts to run during failover execution.
  3. C
    Convert the secondary region architecture into a Cold Standby model using Cloud Storage database exports and Cloud Deployment Manager templates, provisioning GKE clusters and core microservices in `us-east4` only when a disaster event is declared.
  4. D
    Provision an HA VPN tunnel using default bandwidth settings between the `us-east4` application VPC and the `us-central1` hub VPC to bypass peering limitations, relying on standard dynamic autoscaling without reserved compute instances.

Answer

Deploy redundant compliance microservices in the secondary region connected directly to the local VPC to remove transitive VPC peering dependencies, and maintain pre-allocated compute capacity reservations with pre-requested regional quotas.
The correct answer ensures true regional independence by eliminating cross-region dependencies on `us-central1` during a `us-central1` outage. GCP VPC Network Peering is non-transitive, meaning traffic cannot hop across peering connections. Deploying core services locally within `us-east4` removes cross-region bottlenecks. Concurrently, establishing pre-allocated compute capacity reservations and requesting regional resource quotas in advance guarantees that GKE nodes can scale immediately during failover without encountering quota limit errors.

Step-by-Step Solution

1
Analyze network path constraints during regional outage
GCP VPC Network Peering is strictly non-transitive. Traffic from `us-east4` app VPC cannot traverse the `us-central1` hub VPC to reach other peered networks, and relying on `us-central1` infrastructure during a `us-central1` regional outage breaks disaster recovery independence.
Regional failover targets must be self-contained or use high-availability cross-region routing architectures like Cloud Interconnect/Cloud VPN with dedicated regional redundancies.
2
Analyze compute scaling and quota mechanisms during DR execution
Dynamic quota increases take time to be approved by GCP support and cannot be guaranteed during an emergency. Pre-requested quotas and Compute Engine capacity reservations ensure capacity is available in `us-east4`.
Securing resource availability prior to failover is mandatory to prevent startup failures during failover execution.
3
Synthesize optimal BCDR architecture matching RTO < 15 min
Redundant local service deployment in `us-east4` paired with pre-reserved compute capacity meets the RTO target without single-region dependencies.
Eliminating cross-region hard dependencies and pre-provisioning capacity guarantees immediate workload availability.

Key Concept

Disaster Recovery Execution Dependencies and Multi-Region Network non-transitivity
Estimated Time:3m 0s
Rate this question

Topics

Disaster Recovery and Business Continuity Execution

More questions from this topic