SAA-C03 Design Resilient Architectures Practice Question
Exhibit
Application configuration JDBC URL: jdbc:postgresql://mydb-instance-1.abcdefghijkl.us-east-1.rds.amazonaws.com:5432/app Aurora event log 11:15:02 Failover initiated 11:15:04 Writer moved to a different instance 11:18:20 Application still reporting connection refused errors Notes from the team The application uses a connection pool and does not re-resolve the endpoint quickly.
Based on the exhibit, the application sees several minutes of connection errors during an Aurora failover. What is the best change to reduce failover impact?
⚠ Common exam trap
Watch out — candidates often think adding read replicas or scaling application servers will fix failover connectivity, but the real issue is that the application must use the correct endpoint and handle transient disconnections gracefully.
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
✓
Change the application to use the Aurora cluster writer endpoint and retry transient connections.
The Aurora cluster writer endpoint always points to the current primary instance, even after a failover. By using this endpoint and implementing retry logic for transient connection errors, the application can automatically reconnect to the new writer without manual intervention, reducing the impact of the failover from several minutes to seconds.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Change the application to use the Aurora cluster writer endpoint and retry transient connections.
Why this is correct
The current configuration targets a specific instance endpoint, which becomes stale after failover. The Aurora cluster writer endpoint always resolves to the current writer, so the application can reconnect without manual endpoint changes. Adding retries with backoff helps the application survive the short DNS and connection transition during failover.
- ✗
Add an Aurora read replica and keep using the same JDBC URL.
Why it's wrong here
A read replica helps scale read traffic, but it does not solve failover for the writer or the stale-connection problem caused by using a fixed instance endpoint. The application still needs to connect through the cluster writer endpoint.
When this WOULD be correct
This option would be correct in a scenario where the application primarily performs read operations and needs to offload read traffic from the primary database to improve read performance or availability. For example, a reporting application that can tolerate stale reads could use read replicas to distribute load.
- ✗
Increase the EC2 instance size of the application servers.
Why it's wrong here
Increasing the EC2 instance size of the application servers only adds CPU and memory to the compute tier; it does not change how the JDBC driver resolves the Aurora database endpoint or how connection pools handle a failover event. The application is failing because its pooled connections are still pinned to the old writer instance endpoint, which is now a read-only replica or unavailable. Additional app capacity cannot refresh those stale connections or make the application aware that the writer role has moved to another Aurora instance. The correct fix is to use the Aurora cluster writer endpoint, which always resolves to the current writer, and to implement retry logic for transient connection errors during failover.
When this WOULD be correct
This option would be correct in a scenario where the application is experiencing performance degradation due to CPU or memory exhaustion on the application servers, and the database is healthy. For example, if an application's response times increase under load and CloudWatch shows high EC2 CPU utilization, resizing to a larger instance type would alleviate the bottleneck.
- ✗
Switch to a single-AZ RDS PostgreSQL instance for simpler connectivity.
Why it's wrong here
Switching to a single-AZ RDS PostgreSQL instance would actually reduce availability and is a step backward from Aurora's multi-AZ architecture. A single-AZ instance has no automatic failover to another AZ, so any infrastructure failure or maintenance window can cause a full database outage, potentially longer than the transient interruption seen with Aurora. It also does not solve the root cause: the application is connecting to a specific instance endpoint, and RDS single-AZ uses a different DNS name but the same pitfall if the application were to point to a particular instance. The cluster writer endpoint and retry logic are the correct solution because they preserve high availability and let the application automatically follow the writer through failover.
When this WOULD be correct
This option would be correct if the question asked for the simplest, lowest-cost database solution for a non-critical application that can tolerate downtime and does not require high availability or failover support.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Change the application to use the Aurora cluster writer endpoint and retry transient connections.Correct answer▾
Why this is correct
The current configuration targets a specific instance endpoint, which becomes stale after failover. The Aurora cluster writer endpoint always resolves to the current writer, so the application can reconnect without manual endpoint changes. Adding retries with backoff helps the application survive the short DNS and connection transition during failover.
✗Add an Aurora read replica and keep using the same JDBC URL.Wrong answer — click to see why▾
Why this is wrong here
Adding a read replica does not reduce failover impact because the application still uses the same JDBC URL, which points to the writer endpoint. During failover, the writer endpoint may be unavailable, and read replicas cannot handle write operations, so connection errors persist.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the application primarily performs read operations and needs to offload read traffic from the primary database to improve read performance or availability. For example, a reporting application that can tolerate stale reads could use read replicas to distribute load.
Why candidates choose this
Candidates may think that adding a read replica provides high availability or redundancy, but they overlook that the application's JDBC URL still points to the writer endpoint, which is the single point of failure during failover.
✗Increase the EC2 instance size of the application servers.Wrong answer — click to see why▾
Why this is wrong here
Increasing EC2 instance size addresses application-side compute capacity, not database failover connectivity issues. The connection errors stem from DNS propagation delays and endpoint changes during Aurora failover, which are unaffected by application server size.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the application is experiencing performance degradation due to CPU or memory exhaustion on the application servers, and the database is healthy. For example, if an application's response times increase under load and CloudWatch shows high EC2 CPU utilization, resizing to a larger instance type would alleviate the bottleneck.
Why candidates choose this
Candidates may assume that increasing server resources can compensate for any performance issue, including database failover delays, or they might misinterpret 'connection errors' as a symptom of insufficient application capacity rather than a database endpoint issue.
✗Switch to a single-AZ RDS PostgreSQL instance for simpler connectivity.Wrong answer — click to see why▾
Why this is wrong here
Switching to a single-AZ RDS PostgreSQL instance removes high availability and does not address failover impact; it actually increases downtime risk during a failure.
★ When this WOULD be the correct answer
This option would be correct if the question asked for the simplest, lowest-cost database solution for a non-critical application that can tolerate downtime and does not require high availability or failover support.
Why candidates choose this
Candidates may think simplifying the architecture by removing Aurora's complexity will reduce failover issues, but they overlook that single-AZ lacks failover capability entirely.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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.