An application is deployed in a GKE cluster. The company wants to implement a robust disaster recovery plan that minimizes Recovery Time Objective…

An active-active, multi-region architecture provides the lowest possible Recovery Time Objective (RTO) and Recovery Point Objective (RPO). By deploying GKE clusters in two regions fronted by a Global External HTTP(S) Load Balancer, traffic is automatically routed to the healthy region if one fails, resulting in a near-zero RTO. Using a globally distributed, strongly consistent database like Cloud Spanner ensures that data is synchronously replicated across regions. This means that once a write is committed, it exists in both regions, leading to a near-zero RPO. This automated failover mechanism represents the lowest operational complexity during a disaster event compared to other multi-region strategies.

A. A backup and restore process results in a high RTO (time to provision a new cluster and restore data) and a non-zero RPO (data loss since the last backup).

B. A single-region cluster, regardless of its size or autoscaling configuration, provides no protection against a complete regional outage. This design is for high availability within a region, not disaster recovery.

D. An active-passive setup has a higher RTO because it requires a failover process (e.g., DNS update, promoting the passive cluster) and potentially a higher RPO due to asynchronous data replication lag.

1. Disaster recovery planning guide (Google Cloud Documentation): This guide outlines DR patterns. The "Hot pattern: active-active serving in two regions" is described as the approach for achieving the lowest RTO and RPO. It explicitly states, "This pattern can result in no downtime... and potentially no data loss." This aligns directly with option C.

2. Cloud Spanner Documentation - Replication: The documentation for multi-region configurations states, "Spanner maintains synchronous, readable replicas of your data in each region... This configuration provides the highest availability (>99.999%) and avoids data loss in case of a regional failure (RPO=0)." This supports the near-zero RPO claim.

3. Multi-cluster Ingress for GKE (Google Cloud Documentation): This document describes deploying a load balancer that spans multiple GKE clusters in different regions. It notes, "If a load balancer backend in a specific cluster becomes unhealthy, traffic is rerouted to other clusters where the backend is healthy," which is the mechanism for achieving a near-zero RTO.

4. External HTTP(S) Load Balancing overview (Google Cloud Documentation): The overview for the Global External HTTP(S) Load Balancer explains that it provides "cross-region failover," which "enables you to build highly available applications" by automatically directing traffic away from a failed region.