SAA-C03 Design Resilient Architectures Practice Question
Exhibit
application.properties: spring.datasource.url=jdbc:mysql://10.0.12.55:3306/orders spring.datasource.username=appuser spring.datasource.password=**** RDS event log: 2026-04-12T03:14:22Z db-1 - Failover started 2026-04-12T03:15:01Z db-1 - Primary unavailable 2026-04-12T03:16:10Z app-server-2 - SQLRecoverableException: Communications link failure Current deployment: Amazon RDS for MySQL, Multi-AZ enabled Application instances in two AZs Connection string uses an IP address that was entered manually
Based on the exhibit, the application team wants the database to keep the same connection endpoint during failover and to reconnect automatically after the primary instance becomes unavailable. Which change best meets the requirement?
⚠ Common exam trap
Many exam-takers assume a static IP or a load balancer can provide a stable endpoint, but AWS RDS does not support static IPs for Multi-AZ failover, and NLB cannot front RDS instances—the only reliable way is to use the RDS DNS endpoint with retry logic that re-resolves DNS after a connection loss.
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
✓
Replace the IP address with the RDS DNS endpoint and add client retry logic that re-resolves DNS after connection loss.
Using the RDS DNS endpoint ensures that the application connects to the current primary instance, even after a failover. When the primary becomes unavailable, RDS promotes a standby (or read replica) to a new primary and updates the DNS record to point to the new instance's IP. By adding client retry logic that re-resolves DNS after a connection loss, the application automatically picks up the new IP and reconnects without manual intervention, meeting both requirements of a stable endpoint and automatic reconnection.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep the IP address and increase the JDBC connection timeout so the application waits longer during failover.
Why it's wrong here
A longer timeout can reduce the number of immediate failures that the application sees, but it does not solve the core problem. The hardcoded IP address can still point to the old primary after failover, so the client may continue to connect to the wrong target until the configuration is changed.
- ✓
Replace the IP address with the RDS DNS endpoint and add client retry logic that re-resolves DNS after connection loss.
Why this is correct
RDS Multi-AZ failover preserves the database endpoint name, not the underlying IP address. When the standby is promoted, AWS updates the DNS record to point to the new primary. Using the RDS endpoint allows the application to follow that change, and retry logic helps the client recover from the short disconnect that occurs during failover.
- ✗
Create an additional read replica and point the application to it so failover is faster.
Why it's wrong here
A read replica is a separate, read-only copy used to offload read traffic and is never the automatic failover target for a Multi-AZ primary. When RDS performs a failover, it promotes the standby instance in the secondary Availability Zone, not a read replica, so pointing the application at a replica would not survive a primary failure. Furthermore, replicas exhibit replication lag, so the application would see stale data and would be unable to accept writes, breaking core write operations. This option also ignores the underlying issue: the hardcoded IP address remains stale after failover, whereas the correct solution is to use the RDS DNS endpoint with reconnect logic.
- ✗
Place a Network Load Balancer in front of the database and use the load balancer target IP to avoid DNS changes.
Why it's wrong here
A Network Load Balancer operates at Layer 4 and forwards traffic to registered targets, but Amazon RDS does not support placing an NLB in front of a managed database instance. RDS already provides a stable DNS endpoint that updates automatically during Multi-AZ failover, so inserting an NLB adds an unnecessary network hop and introduces a target IP that still changes when the primary instance fails. The NLB's static IP would not solve the problem because the balancer itself would need to resolve the RDS instance's current IP—exactly the value that changes on promotion. This architecture is unsupported, requires custom health checks, and does not replace the native DNS-based failover mechanism that RDS provides; the correct fix is to use the RDS endpoint and retry on connection loss.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 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 →
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.