Examkin

Soru

Zorluk: OrtaDisaster Recovery and Business Continuity Execution

An energy utility company operates a smart grid telemetry platform on Google Cloud. The primary workload runs in region `us-east1`, utilizing Compute Engine Managed Instance Groups (MIGs) behind an External HTTP(S) Load Balancer and a Cloud SQL for PostgreSQL database. To maintain a Warm Standby disaster recovery pattern targeting an RTO of less than 15 minutes and an RPO of less than 5 minutes in secondary region `us-central1`, the team maintains a cross-region Cloud SQL read replica and a baseline MIG of 2 instances in `us-central1`. During a simulated disaster recovery failover test where `us-east1` is declared offline, the automation script successfully promotes the Cloud SQL read replica in `us-central1` to standalone primary status and attempts to scale out the `us-central1` MIG to 50 instances to handle full production traffic. However, the MIG scaling operation fails immediately and cannot launch additional compute instances, causing the failover to stall. Which of the following is the most likely cause of this execution failure?

  1. The Google Cloud project lacks sufficient regional Compute Engine resource quota in `us-central1`, as quota increases were only granted for the primary region.Cevap
  2. B
    VPC Network Peering was omitted between `us-east1` and `us-central1`, preventing the newly scaled MIG in `us-central1` from establishing a valid network path to the database.
  3. C
    Cloud SQL for PostgreSQL cross-region read replicas cannot be promoted unless the primary database is migrated to Cloud Spanner for multi-region global consistency.
  4. D
    HA VPN was selected for inter-region connectivity instead of Dedicated Interconnect, restricting the control plane throughput necessary to provision new Compute Engine instances.

Cevap

The Google Cloud project lacks sufficient regional Compute Engine resource quota in us-central1, as quota increases were only granted for the primary region.
In Google Cloud, compute resource quotas (such as N2 CPUs, Regional External IP addresses, and In-use IP addresses) are assigned on a per-region basis within a project. In a Warm Standby disaster recovery topology where instances are kept minimal in the recovery region, attempting to scale out rapidly from a low baseline to full production capacity during a DR event will fail if regional quotas in the target region have not been requested and increased in advance.

Adım Adım Çözüm

1
Analyze the disaster recovery failover behavior and symptoms.
The database promotion succeeded, but expanding the Compute Engine Managed Instance Group from 2 to 50 instances in the failover region failed immediately.
Identifying whether the bottleneck is database replication, network routing, or infrastructure capacity constraint narrows down the failure domain.
2
Evaluate Google Cloud resource limit boundaries across regions.
Compute Engine CPU and instance quotas are project-specific and region-specific.
If a project has not pre-requested higher resource quotas in the backup region, scaling up instances during a regional DR event will trigger a quota exceeded error.
3
Select the root cause that directly prevents MIG capacity expansion.
Missing or insufficient regional quota pre-allocation in the DR region prevents instance creation.
Pre-requesting and regularly auditing resource quotas across primary and backup regions is a fundamental requirement for executing DR procedures.

Anahtar Kavram

Disaster Recovery Capacity & Quota Management
Bu soruyu puanla

Konular

Disaster Recovery and Business Continuity Execution

Bu konudan daha fazla soru