RDS Multi-AZ Failover DNS Caching: Common Issue
A company uses Amazon RDS for MySQL with Multi-AZ deployment. The database instance fails and AWS automatically fails over to the standby. After the failover, the application cannot connect to the database. The engineer checks the RDS console and sees that the instance status is Available. What is the MOST likely cause of the connectivity issue?
Quick Answer
The answer is a stale DNS cache causing the application to connect to the old primary’s IP address. After an RDS Multi-AZ failover, the DNS endpoint’s CNAME remains unchanged, but its underlying IP address updates to point to the new writer. If the application caches this resolved IP, it will attempt to connect to the old primary—now a replica or unavailable node—even though the RDS console shows the instance as Available. On the AWS Certified DevOps Engineer Professional DOP-C02 exam, this question tests your understanding of how RDS Multi-AZ failover DNS caching can silently break connectivity, a common trap where engineers assume the endpoint itself changes. The key insight is that the DNS record is a CNAME, not an A record; applications must always resolve the endpoint fresh on each connection. Memory tip: “CNAME stays the same, IP flips—don’t cache the flip.”
⚠ Common exam trap
Many exam-takers assume a failed Multi-AZ failover or a DNS propagation delay, when in reality the instance is healthy and DNS updates quickly, but the application's cached IP address from the old primary is the root cause.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The application is using the database's DNS endpoint for the old primary, which is no longer the writer.
After an RDS Multi-AZ failover, the DNS endpoint for the DB instance remains the same but its underlying IP address changes to point to the new primary (formerly the standby). If the application caches the IP address of the old primary or uses a direct connection to the old writer endpoint, it will attempt to connect to a node that is no longer the writer. The correct practice is to always connect using the RDS instance endpoint (CNAME), which automatically resolves to the current writer, and to avoid caching the resolved IP address. Since the instance status is 'Available', the new primary is ready, so the issue is a stale connection target.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The security group for the RDS instance has changed during failover.
Why it's wrong here
Security groups remain the same.
- ✓
The application is using the database's DNS endpoint for the old primary, which is no longer the writer.
Why this is correct
After failover, the writer endpoint points to the new primary, but if the application caches the old endpoint, it may fail.
- ✗
The DNS record for the RDS endpoint has not propagated to the application's DNS resolver.
Why it's wrong here
RDS DNS updates quickly and is not usually the issue.
- ✗
The database instance is still in the process of failover and is not yet accepting connections.
Why it's wrong here
The status is Available, so failover is complete.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 251 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company is using Amazon RDS for MySQL with Multi-AZ deployment. The database experiences a failover due to an availability zone outage. After the failover, the application team reports that the database endpoint is not resolving to the new primary. What is the most likely reason?
medium- A.The RDS CNAME record was not updated by AWS after the failover.
- B.The application is using the read replica endpoint instead of the primary endpoint.
- C.The application is using a Route 53 health check that failed and redirected traffic away from the endpoint.
- ✓ D.The application is using a cached DNS resolution that points to the old primary.
Why D: After an RDS Multi-AZ failover, the DNS CNAME record for the DB instance is updated to point to the new primary in the standby AZ. However, if the application or its DNS resolver has cached the previous DNS resolution, it will continue to use the old IP address, which is no longer reachable. This is a common issue that can be resolved by reducing the TTL on the DNS record or implementing retry logic with DNS re-resolution in the application.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.