RDS Multi-AZ Failover: Understanding Endpoint Behavior

• A.A new endpoint is created for the standby and the application must use the new endpoint.
• ✓ B.The existing endpoint continues to work and automatically points to the standby DB instance.
• C.The database becomes unavailable until the primary is restored from a snapshot.
• D.The existing endpoint is deleted and a new endpoint is provided after manual DNS update.

Why B: In a Multi-AZ RDS deployment, the DNS endpoint remains unchanged during a failover. When the primary DB instance fails, Amazon RDS automatically updates the DNS record to point to the standby instance in the other Availability Zone. This ensures the application can continue using the same endpoint without any manual intervention, providing high availability.

• A.The standby instance is created in the same Availability Zone as the failed primary.
• B.A manual DNS update is required to connect to the new primary.
• ✓ C.The DNS CNAME record is updated to point to the new primary.
• D.The endpoint changes to the standby instance's endpoint.
• ✓ E.The applications can continue using the same database endpoint.

Why C: Option C is correct because when Amazon RDS performs automatic failover in a Multi-AZ deployment, it updates the DNS CNAME record for the primary DB instance to point to the new primary (formerly the standby). This ensures that applications using the original endpoint are transparently redirected to the new primary without manual intervention.

• A.The read replica is now the primary and cannot handle write traffic.
• B.The failover process disabled automatic backups.
• C.The DNS endpoint did not update to point to the new primary.
• ✓ D.The new primary instance is in a different Availability Zone, increasing network latency.

Why D: Option D is correct because after a Multi-AZ failover in Amazon RDS for MySQL, the new primary instance is launched in a different Availability Zone (AZ) than the original primary. If the application's compute resources (e.g., EC2 instances) remain in the original AZ, cross-AZ network traffic incurs additional latency due to the physical distance and the need to traverse the AZ boundary, which typically adds 1–2 ms of round-trip time. This increased network latency directly impacts application performance, especially for latency-sensitive queries.

• A.The standby instance took longer than expected to promote to primary.
• B.The standby instance was not in a synchronized state and required a manual promotion.
• C.The application was using the wrong endpoint and needed to be reconfigured.
• ✓ D.The DNS record for the DB instance endpoint needed to update to point to the new primary.

Why D: Option D is correct because after an automatic failover in Amazon RDS Multi-AZ, the DNS record for the DB instance endpoint is updated to point to the new primary. This DNS change can take up to 60 seconds to propagate, during which the application may receive 'unreachable' errors if it caches the old DNS resolution. The 60-second outage aligns with the typical TTL (Time To Live) of 30 seconds for RDS DNS records plus propagation delays.

• A.The application is using a read replica endpoint, which does not support write operations.
• ✓ B.The application is using the RDS instance endpoint instead of the cluster endpoint, so it does not automatically route to the standby after failover.
• C.The application is connecting through a Network Load Balancer, which is not configured for cross-zone failover.
• D.The application connection pool is exhausted because the failover caused all existing connections to drop simultaneously.

Why B: Option B is correct because in a Multi-AZ RDS deployment, the instance endpoint always points to the current primary instance. During a failover, the DNS record for the instance endpoint is updated to point to the new primary, but existing connections to the old primary are dropped, and the DNS change can take time to propagate. The application's connection string using the instance endpoint means it does not automatically route to the standby during the failover transition, causing a brief write outage until the DNS update completes and the application reconnects. In contrast, using a cluster endpoint (available for Aurora, not standard RDS) or implementing retry logic in the application would mitigate this.

• A.The database instance is in a 'stopped' state after failover.
• B.The Multi-AZ failover requires manual intervention to complete.
• C.The security group for the RDS instance was not updated during failover.
• ✓ D.The application is using the old primary instance endpoint instead of the RDS CNAME.

Why D: The correct answer is D. After a Multi-AZ failover in Amazon RDS for PostgreSQL, the DNS CNAME record automatically updates to point to the new primary instance in the standby Availability Zone. If the application hardcodes the old primary instance's endpoint (specific IP or DNS name) instead of using the RDS CNAME (which remains constant), it will attempt to connect to the failed instance, causing connectivity loss. The CNAME is the stable connection point that always resolves to the current primary instance.