Question

Difficulty: Very hardDatabase High Availability

An organization's enterprise resource planning (ERP) application uses an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment within the us-east-1 Region. For disaster recovery purposes, the database also has a cross-Region read replica configured in the us-west-2 Region. The application servers in us-east-1 connect to the database using the primary database endpoint CNAME. Amazon Route 53 is configured with an active-passive failover routing policy to redirect client traffic to us-west-2 only if the application stack in us-east-1 becomes completely unavailable.

Following an unexpected hardware failure on the active primary DB instance in us-east-1, the database undergoes an automatic failover. However, the SysOps Administrator observes that the local application servers in us-east-1 continue to encounter database connection timeout errors for several minutes, and Route 53 does not redirect client traffic to the us-west-2 Region.

Which two statements correctly explain these observations and identify the appropriate steps to resolve the connection issues? (Select TWO.)

  1. The database connection timeouts occur because the application servers or database clients have cached the DNS resolution (IP address) of the RDS primary database endpoint. Restarting the client applications or reducing the client-side DNS cache TTL will force them to resolve the endpoint to the newly promoted standby instance's IP address.Answer
  2. Route 53 did not redirect traffic to us-west-2 because the failover was localized to the primary Region. The database endpoint CNAME was updated to point to the standby instance within us-east-1, keeping the primary Region's application stack healthy and functional once client DNS caches cleared.Answer
  3. C
    To resolve the connection timeouts, the administrator must manually promote the us-west-2 read replica to a standalone primary DB instance, as RDS Multi-AZ standby instances do not automatically assume the primary database endpoint CNAME during a failover.
  4. D
    To prevent future connection timeouts during database failovers, the application connection strings should be updated to point to the read replica endpoint in us-west-2, allowing synchronous write redirection to the promoted standby instance.
  5. E
    Route 53 failed to redirect client traffic because active-passive failover routing requires the primary database to be configured with an active-active routing policy to synchronize CNAME records across both Regions during a local AZ outage.

Answer

The database connection timeouts are caused by client-side DNS caching of the RDS database endpoint, which can be resolved by restarting the application or reducing the DNS cache TTL. Route 53 did not fail over because the database failover was successfully handled locally within the primary Region, keeping the primary application stack healthy.
The correct options state that client-side DNS caching is the cause of connection timeouts following an RDS Multi-AZ failover, which can be mitigated by resetting connections or reducing cache TTL. Additionally, Route 53 did not fail over because the database failover was successfully resolved within the primary Region, maintaining the overall health of the primary application stack.

Step-by-Step Solution

1
Analyze the database configuration and the scope of the failover event.
The primary database is configured as an RDS Multi-AZ deployment in us-east-1, meaning automated failover is managed locally at the database service layer, while the us-west-2 read replica is asynchronous and decoupled from local AZ failovers.
To determine whether the failure represents a localized AZ issue or a regional disaster recovery event.
2
Evaluate the behavior of the database endpoint CNAME during Multi-AZ failovers.
RDS automatically promotes the standby DB instance and updates the CNAME of the database endpoint to resolve to the standby's new IP address, typically completing within 60 to 120 seconds.
To verify that manual intervention (such as promoting the read replica) is not required for a local AZ failover.
3
Diagnose the source of client connection timeouts following the failover.
Identify that client-side DNS caching (at the OS, JVM, or application level) preserves the resolved IP address of the failed primary instance, ignoring the updated CNAME target until the cache is cleared or restarted.
To explain the connection errors despite successful database-side standby promotion.
4
Evaluate Route 53 DNS routing status and health check conditions.
Confirm that Route 53 active-passive failover did not trigger because the application stack in us-east-1 recovered locally once client DNS cache cleared, keeping the primary Region's application health checks green.
To explain why client traffic was not redirected to the disaster recovery Region in us-west-2.

Key Concept

RDS Multi-AZ failovers rely on DNS CNAME updates to redirect local traffic, but client-side DNS caching can delay recovery. Route 53 regional failovers only trigger when the entire primary regional application stack fails health checks.
Estimated Time:3m 0s
Rate this question