Examkin

Soru

Zorluk: ZorDeveloping Procedures for Business Continuity and Disaster Recovery Validation

A multinational financial services enterprise hosts its core payment authorization pipeline across two Google Cloud regions (primary in us-central1, secondary in us-east4). The enterprise requires a quarterly Business Continuity and Disaster Recovery (BCP/DR) drill to validate cross-region failover efficiency under an RPO target of under 1 minute and an RTO target of under 15 minutes. As the Lead Cloud Architect, you must sequence the technical steps for executing and verifying this DR validation exercise without causing unintended data loss or unexpected service failure. Arrange the operational steps below in the correct execution sequence from first to last.

  1. 1Audit compute quota limits and verify active capacity reservations in us-east4 to guarantee resource availability prior to failover.
  2. 2Check Cloud Monitoring metrics for cross-region storage replication lag to confirm compliance with the 1-minute RPO requirement before initiating failover.
  3. 3Promote the standby database in us-east4 to primary mode and update Cloud DNS routing policies to shift incoming payment API requests to us-east4.
  4. 4Run automated synthetic payment transaction suites in us-east4 to verify functional integrity, end-to-end telemetry logging, and total RTO SLA compliance.
  5. 5Configure reverse replication from us-east4 back to us-central1 once testing completes to synchronize state changes prior to executing primary failback.

Cevap

The correct execution order is: 1) Audit compute quota limits and capacity reservations in us-east4; 2) Check Cloud Monitoring cross-region replication lag; 3) Promote standby database in us-east4 and update Cloud DNS routing policies; 4) Run automated synthetic transaction suites in us-east4 to verify integrity and RTO; 5) Configure reverse replication from us-east4 back to us-central1.
The proper DR validation sequence starts with pre-flight checks (confirming compute quotas and capacity reservations, followed by checking replication lag against RPO metrics). Next, the failover is executed by promoting the DR database and updating DNS routing. Afterwards, functional integrity and RTO metrics are validated using synthetic transaction tests. Finally, reverse replication is established back to the primary region to prepare for clean failback without data loss.

Adım Adım Çözüm

1
Pre-flight resource availability verification
Confirmed sufficient regional quotas and reserved compute capacity in the DR target region (us-east4).
Failing to check compute quotas beforehand can cause Compute Engine instance creation to fail during switchover.
2
RPO compliance verification
Verified replication lag is within the required 1-minute window.
Initiating failover when replication lag is high violates RPO objectives and leads to unrecoverable data loss.
3
Failover execution and traffic redirection
Secondary database promoted to write mode and active network traffic redirected to us-east4.
Database promotion and DNS record updates transition the secondary site to active primary status.
4
Failover validation and RTO timing verification
Synthetic transaction suite executed cleanly and total failover time measured against RTO SLA.
Post-failover validation ensures the secondary environment operates reliably under real transaction conditions.
5
Failback preparation and reverse synchronization
Reverse replication initialized from us-east4 back to us-central1.
Re-establishing reverse replication preserves data written to us-east4 during the validation drill before returning primary operations to us-central1.

Anahtar Kavram

Developing Procedures for Business Continuity and Disaster Recovery Validation
Tahmini Süre:2m 30s
Bu soruyu puanla

Konular

Developing Procedures for Business Continuity and Disaster Recovery Validation