Question

Difficulty: Very hardDatabase High Availability

A SysOps Administrator is designing a disaster recovery strategy for a critical transactional application. The primary infrastructure is in the eu-west-1 Region, utilizing an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment. For cross-region disaster recovery, the administrator deploys an RDS Read Replica in the eu-central-1 Region.

To manage traffic during a regional outage, the administrator configures an Amazon Route 53 active-passive failover routing policy. The primary routing record is a CNAME pointing to the primary RDS endpoint in eu-west-1, associated with a Route 53 health check. The secondary routing record is a CNAME pointing to the replica's endpoint in eu-central-1.

During a simulated outage of eu-west-1, the health check fails, and Route 53 successfully redirects traffic to eu-central-1. However, the application fails to perform any write operations, returning read-only database transaction errors.

Which of the following describes the root cause of this issue, and the correct action to resolve it?

  1. A
    The Route 53 failover routing policy was configured with an active-active routing configuration rather than active-passive, which kept the primary region CNAME active. The administrator must change the routing policy to active-passive and associate the primary health check with the secondary record to allow RDS to automatically trigger the database promotion API.
  2. B
    The administrator did not configure the cross-region Read Replica as a standby instance within the RDS Multi-AZ deployment configuration. Enabling Multi-AZ globally across both regions is required for RDS to perform automatic failover and promote the secondary replica to a write-enabled state without manual intervention.
  3. Cross-region RDS Read Replicas are read-only and do not automatically promote to primary write-enabled instances during a DNS failover. To restore write capabilities, the administrator must manually promote the Read Replica in the secondary region to a standalone DB instance.Answer
  4. D
    The administrator omitted the 'Enable Failover Target' attribute when launching the cross-region Read Replica. Without this attribute, Route 53 DNS updates redirect the application connection string, but the replica is prevented from assuming the master role and transitioning out of read-only mode.

Answer

Cross-region RDS Read Replicas are read-only and do not automatically promote to primary write-enabled instances during a DNS failover. To restore write capabilities, the administrator must manually promote the Read Replica in the secondary region to a standalone DB instance.
The correct answer is correct because Amazon RDS cross-region Read Replicas are designed for asynchronous read replication and disaster recovery, but they are read-only. Route 53 DNS failover only updates the CNAME record to point to the secondary region endpoint; it does not perform any control-plane actions on the RDS database itself. To enable write operations on the secondary database, the administrator must manually promote the Read Replica to a standalone database instance.

Step-by-Step Solution

1
Analyze the architecture components and identify that the database in the primary region is configured as Multi-AZ, whereas the database in the secondary region is a cross-region Read Replica.
Identify that RDS Multi-AZ provides synchronous replication and automatic failover within a single region, but cross-region disaster recovery relies on asynchronous Read Replicas.
Understanding the replication and failover boundaries is necessary to diagnose the cause of write failures in the secondary region.
2
Examine the role of Route 53 DNS failover in the setup.
Determine that Route 53 active-passive failover only updates DNS routing records (CNAME) to point to the new database endpoint, but it does not execute any database promotion operations.
This distinguishes DNS-level routing updates from database-level state changes (such as promoting a read-only instance to read-write).
3
Identify the write state of the database target in the secondary region.
Confirm that the cross-region Read Replica in the secondary region remains in a read-only state because it has not been promoted.
This explains why the client application receives read-only database transaction errors upon connecting to the replica.
4
Determine the required administrative action to resolve the database write errors.
The administrator must manually promote the cross-region Read Replica to a standalone DB instance to enable write operations.
Promoting the replica breaks replication and opens the database for read-write operations, completing the disaster recovery failover process.

Key Concept

Distinction between local Multi-AZ failover (automatic, synchronous) and cross-region disaster recovery using Read Replicas (manual promotion, asynchronous).
Estimated Time:3m 0s
Rate this question