SAA-C03 Design Resilient Architectures Practice Question
A production application uses an Amazon RDS Multi-AZ DB instance. During an unplanned failover, the database endpoint remains the same. What change should the application team make to handle the failover reliably?
⚠ Common exam trap
A common mix-up: candidates assume the endpoint changes or that Multi-AZ provides seamless failover without any application-side changes, but in reality the application must implement retry logic to handle the brief connection disruption during DNS propagation.
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
✓
Keep using the same RDS endpoint and implement connection retry logic on failures.
The RDS Multi-AZ DNS endpoint remains unchanged during a failover, automatically pointing to the new writer instance. Implementing connection retry logic with exponential backoff allows the application to handle the brief DNS propagation delay and connection interruption, ensuring reliable recovery without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Hard-code the new writer instance IP address after failover completes.
Why it's wrong here
Hard-coding an instance's private IP address is brittle because RDS Multi-AZ failover promotes a different physical instance while the existing IP may no longer belong to the new writer. The correct connection address is the RDS endpoint, a DNS name that changes to point at the promoted instance; by hard-coding an IP, the application bypasses this DNS mechanism, so it will continue sending traffic to a stale IP and require an extra, manual configuration step that lengthens recovery. This directly defeats the automatic failover benefit of Multi-AZ.
- ✓
Keep using the same RDS endpoint and implement connection retry logic on failures.
Why this is correct
The RDS endpoint is DNS-based and remains constant across a Multi-AZ failover, so clients should continue using that same hostname. When failover occurs, existing active connections are dropped and in-flight transactions may fail; the application must treat those errors as transient and reconnect using retry logic with backoff or jitter. This allows the app to automatically resume writing to the new primary once DNS and the instance are ready. Do not assume an individual request succeeded; ensure retries are idempotent.
- ✗
Disable Multi-AZ and rely on manual intervention to switch endpoints.
Why it's wrong here
Disabling Multi-AZ eliminates the synchronous standby replica and automatic failure detection, so any database crash would require you to manually restore from a snapshot or rebuild a new instance before traffic can resume. Manual intervention adds unpredictable downtime and risks human error during an incident, which is the opposite of the automated high availability that Multi-AZ provides. Furthermore, you lose the ability to simply wait out a failover; you'd need to update application configuration and endpoints by hand, violating the design goal of a resilient application.
- ✗
Move reads to application-side caching only, and avoid reopening DB connections.
Why it's wrong here
Application-side caching can reduce read load and allow serving data even if the database is temporarily unreachable, but it cannot handle write traffic or transaction consistency once the primary fails. Avoidance of reopening connections means the application will retain broken pools/sockets; after the failover completes, those connections no longer point to the current writer, so writes continue to fail. You must proactively close stale connections and re-establish new ones against the same endpoint, rather than caching and refusing to reconnect, which would make automatic recovery impossible.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 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 SAA-C03 exam.