SAA-C03 Design Resilient Architectures Practice Question
An application writes to an Amazon Aurora DB cluster. After a planned Aurora failover, the application experiences several minutes of connection errors.
The logs show the application continues connecting to the specific DB instance endpoint that was the primary before the failover.
What change most directly improves resilience during Aurora failovers?
⚠ Common exam trap
Many exam-takers think using any Aurora endpoint (like the reader endpoint) is sufficient, but they must understand that only the cluster writer endpoint guarantees write availability after a failover, while the reader endpoint is strictly for read traffic.
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
✓
Update the application to use the Aurora cluster writer endpoint for write traffic so it always resolves to the current writer instance.
The Aurora cluster writer endpoint always resolves to the current primary DB instance, even after a failover. By using this endpoint instead of a specific instance endpoint, the application automatically reconnects to the new writer without manual intervention or connection errors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Update the application to use the Aurora cluster writer endpoint for write traffic so it always resolves to the current writer instance.
Why this is correct
During failover, Aurora changes which underlying DB instance is the writer. The cluster writer endpoint (for the cluster) always resolves to the current writer. Using the writer endpoint prevents the application from being pinned to an old instance endpoint that may stop accepting writes after failover.
- ✗
Increase Aurora storage autoscaling so failovers are unnecessary.
Why it's wrong here
Aurora storage autoscaling automatically expands the cluster's storage capacity as data grows; it does not alter the cluster's failover behavior. Failovers are triggered by writer-instance health issues, patching, or an Availability Zone impairment, not by storage pressure. Even with storage scaling enabled, Aurora will still promote a new writer and update the cluster writer endpoint, so the application must follow that endpoint. Storage capacity increases do not make failover unnecessary or prevent the writer DNS mapping from changing.
When this WOULD be correct
A question where an application experiences write failures due to storage capacity limits on an Aurora cluster. The correct solution would be to enable storage autoscaling to automatically increase storage when thresholds are reached, preventing write disruptions.
- ✗
Point both reads and writes to the Aurora reader endpoint to keep the DNS name the same.
Why it's wrong here
The Aurora reader endpoint is a load-balanced DNS name that routes read traffic to available Aurora Replicas, which operate in read-only mode. Sending writes to this endpoint will fail because replicas do not accept write statements, and the underlying instance behind the reader endpoint can change constantly as replicas are added or promoted. While the reader endpoint's DNS name remains stable, its resolution does not guarantee a primary instance, so it is an invalid target for write traffic. Only the cluster writer endpoint ensures that writes always resolve to the current primary instance, irrespective of topology changes.
When this WOULD be correct
In a scenario where the application only performs read operations and needs to distribute load across replicas while maintaining a single DNS name that automatically adjusts to available instances, using the reader endpoint would be correct. For example, a reporting application that queries read replicas and must remain available during failover.
- ✗
Disable Aurora failover capability so the cluster never switches writer instances.
Why it's wrong here
Aurora's failover capability is a built-in high-availability feature that promotes a new writer automatically when the current one becomes unhealthy. There is no practical way to disable this without also stripping away the cluster's Multi-AZ resilience, which would leave writes without a working target during a failure. If you somehow prevented failover, the original writer instance could remain unhealthy or require replacement, and the application would still be pinned to an instance endpoint that might never accept writes again. Disabling failover reduces availability and eliminates the automatic endpoint remapping that the cluster endpoint provides.
When this WOULD be correct
In a scenario where the application cannot tolerate any connection interruption and the database must remain on a specific instance for compliance or licensing reasons, disabling failover might be chosen to avoid automatic failover, accepting the risk of manual recovery.
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.
✓Update the application to use the Aurora cluster writer endpoint for write traffic so it always resolves to the current writer instance.Correct answer▾
Why this is correct
During failover, Aurora changes which underlying DB instance is the writer. The cluster writer endpoint (for the cluster) always resolves to the current writer. Using the writer endpoint prevents the application from being pinned to an old instance endpoint that may stop accepting writes after failover.
✗Increase Aurora storage autoscaling so failovers are unnecessary.Wrong answer — click to see why▾
Why this is wrong here
Increasing Aurora storage autoscaling does not prevent failovers; it only adjusts storage capacity. Failovers occur due to instance-level issues, not storage limits, so this change does not address the application's connection errors after failover.
★ When this WOULD be the correct answer
A question where an application experiences write failures due to storage capacity limits on an Aurora cluster. The correct solution would be to enable storage autoscaling to automatically increase storage when thresholds are reached, preventing write disruptions.
Why candidates choose this
Candidates may mistakenly believe that storage autoscaling can eliminate the need for failovers by preventing resource exhaustion, but failovers are triggered by instance health, not storage.
✗Point both reads and writes to the Aurora reader endpoint to keep the DNS name the same.Wrong answer — click to see why▾
Why this is wrong here
The reader endpoint is intended for read-only traffic and does not handle write operations; pointing writes to it would cause failures. Moreover, the reader endpoint resolves to multiple reader instances, not the current writer, so it does not ensure connectivity to the writer after failover.
★ When this WOULD be the correct answer
In a scenario where the application only performs read operations and needs to distribute load across replicas while maintaining a single DNS name that automatically adjusts to available instances, using the reader endpoint would be correct. For example, a reporting application that queries read replicas and must remain available during failover.
Why candidates choose this
Candidates may think that using a single endpoint simplifies DNS resolution and avoids the connection errors seen in the question, but they overlook that the reader endpoint is not designed for write traffic and does not point to the writer instance.
✗Disable Aurora failover capability so the cluster never switches writer instances.Wrong answer — click to see why▾
Why this is wrong here
Disabling failover capability prevents the cluster from switching to a healthy instance during a failure, which would cause prolonged downtime instead of resolving the connection errors. The question asks for improving resilience, and disabling failover directly undermines that goal.
★ When this WOULD be the correct answer
In a scenario where the application cannot tolerate any connection interruption and the database must remain on a specific instance for compliance or licensing reasons, disabling failover might be chosen to avoid automatic failover, accepting the risk of manual recovery.
Why candidates choose this
Candidates may think that disabling failover eliminates the need for the application to reconnect, thus avoiding connection errors, but they overlook that this removes the cluster's high availability and would cause extended downtime if the primary fails.
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?”
Visual reference
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.