The answer is to replace the IP address with the RDS DNS endpoint and add client retry logic that re-resolves DNS after connection loss. This works because the RDS DNS endpoint always resolves to the current primary instance’s IP, so after a failover, Amazon RDS automatically updates the DNS record to point to the new primary. Without retry logic that re-resolves DNS, the application would cache the old IP and fail to reconnect; the retry mechanism ensures the client fetches the updated DNS record upon connection loss, enabling automatic failover reconnection. On the SAA-C03 exam, this scenario tests your understanding of how RDS Multi-AZ failover works at the network layer—specifically that the endpoint is static but the underlying IP changes. A common trap is assuming a static IP or a connection pool without DNS re-resolution will suffice. Memory tip: “DNS + Retry = Failover Friendly” — the endpoint stays the same, but your code must ask for directions again after a crash.
SAA-C03 Design Resilient Architectures Practice Question
This SAA-C03 practice question tests your understanding of design resilient architectures. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "best"
Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
Clue: "primary"
Why it matters: Asks for the main purpose or function, not a secondary benefit. Eliminate answers that describe side-effects or partial functions.
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
A
Keep the IP address and increase the JDBC connection timeout so the application waits longer during failover.
Why wrong: 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.
B
Replace the IP address with the RDS DNS endpoint and add client retry logic that re-resolves DNS after connection loss.
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.
C
Create an additional read replica and point the application to it so failover is faster.
Why wrong: A read replica is not the normal automatic failover target for a writable application database. Pointing the application at a replica can also introduce replication lag and change the write semantics of the system.
D
Place a Network Load Balancer in front of the database and use the load balancer target IP to avoid DNS changes.
Why wrong: Managed RDS failover is not implemented by placing a load balancer in front of the database. This adds complexity without providing the native endpoint stability that RDS Multi-AZ already supports through DNS.
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.
Option B is correct because 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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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.
Clue confirmation
The clue words "best", "primary" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
Create an additional read replica and point the application to it so failover is faster.
Why it's wrong here
A read replica is not the normal automatic failover target for a writable application database. Pointing the application at a replica can also introduce replication lag and change the write semantics of the system.
✗
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
Managed RDS failover is not implemented by placing a load balancer in front of the database. This adds complexity without providing the native endpoint stability that RDS Multi-AZ already supports through DNS.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates 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.
Detailed technical explanation
How to think about this question
RDS Multi-AZ deployments use a DNS CNAME record that automatically updates to point to the new primary instance's IP after a failover. The application must be configured to use the RDS DNS endpoint (e.g., mydb.xxxxxx.rds.amazonaws.com) and implement retry logic with DNS re-resolution—typically by setting the JDBC connection string to use the hostname and enabling the 'jdbc:mysql://' driver's DNS caching timeout (e.g., via the 'dnsCacheTTL' property) to a low value, or by using a connection pool that re-resolves on failure. This ensures that the application can recover within seconds of a failover, without manual intervention.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A healthcare organisation deploys an application with a public-facing web tier and a private database tier. The database subnet has no public IP and only accepts connections from the web tier's security group. Questions like this test whether you can design cloud network isolation using VNets/VPCs, subnets, and security group rules.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Design Resilient Architectures — This question tests Design Resilient Architectures — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Replace the IP address with the RDS DNS endpoint and add client retry logic that re-resolves DNS after connection loss. — Option B is correct because 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.
What should I do if I get this SAA-C03 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "best", "primary". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.