SAA-C03 Design Resilient Architectures Practice Question
A company runs an application behind an Application Load Balancer (ALB). An Auto Scaling group (ASG) is configured with desired capacity 2, but it is attached only to subnets in a single Availability Zone. The ALB is healthy because it is configured across multiple Availability Zones.
When the Availability Zone that contains the ASG subnets experiences an outage, what change most directly improves resilience and allows capacity to be restored automatically?
⚠ Common exam trap
A common mix-up: candidates assume a multi-AZ ALB automatically makes the entire architecture resilient, overlooking that the ASG must also be configured with subnets in multiple AZs to launch replacement instances after an AZ failure.
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 ASG to use subnet IDs that span at least two Availability Zones so it can launch replacement instances after an AZ outage.
An Auto Scaling group (ASG) can only launch instances into the subnets explicitly assigned to it. If those subnets reside in a single Availability Zone (AZ) and that AZ fails, the ASG has no capacity to launch replacement instances, even though the ALB is multi-AZ. By configuring the ASG with subnet IDs spanning at least two AZs, the ASG can automatically launch instances in a healthy AZ, restoring capacity and resilience.
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 ASG to use subnet IDs that span at least two Availability Zones so it can launch replacement instances after an AZ outage.
Why this is correct
If the ASG is attached to subnets in multiple Availability Zones, when instances in the failed AZ become unhealthy/terminate, Auto Scaling can launch new instances in the remaining AZs to restore the desired capacity. This directly addresses the root cause: the ASG cannot create capacity outside the AZs it is configured for.
- ✗
Reduce the ALB health check interval to speed up detection of unhealthy targets.
Why it's wrong here
Reducing the ALB health check interval may detect instance health failures sooner, but it does not change where Auto Scaling is allowed to launch instances. If the ASG is still limited to a single AZ’s subnets, capacity cannot be restored in other AZs.
When this WOULD be correct
This option would be correct in a scenario where the ASG already spans multiple AZs and the goal is to reduce recovery time after a failure. For example, an application requires faster failover to healthy instances, and the question asks how to minimize the time to mark instances as unhealthy.
- ✗
Enable connection draining on the ALB so existing requests complete before targets are terminated.
Why it's wrong here
Connection draining helps during controlled events such as deployments or scale-in, where you want in-flight requests to finish. It does not enable the ASG to launch replacements in other Availability Zones after an AZ outage.
When this WOULD be correct
In a scenario where an ALB is deregistering unhealthy targets and you need to ensure existing user sessions finish without interruption before the targets are terminated, enabling connection draining would be the correct answer.
- ✗
Increase the ASG desired capacity from 2 to 6 to compensate for the missing subnets.
Why it's wrong here
Increasing the ASG desired capacity from 2 to 6 does not change the subnets or Availability Zones the ASG is configured to use. Auto Scaling can only launch instances into the subnets explicitly attached to the ASG, so if those subnets all reside in the Availability Zone that failed, the extra capacity requests will still fail to launch instances. The desired capacity increase would only be helpful if the ASG had spare capacity in unaffected AZs to scale into, which is exactly the missing configuration.
When this WOULD be correct
In a scenario where the ASG already spans multiple AZs but experiences increased load, increasing desired capacity (e.g., from 2 to 6) would help handle the traffic and maintain performance. This would be correct if the question focused on scaling to meet demand rather than AZ failure 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 ASG to use subnet IDs that span at least two Availability Zones so it can launch replacement instances after an AZ outage.Correct answer▾
Why this is correct
If the ASG is attached to subnets in multiple Availability Zones, when instances in the failed AZ become unhealthy/terminate, Auto Scaling can launch new instances in the remaining AZs to restore the desired capacity. This directly addresses the root cause: the ASG cannot create capacity outside the AZs it is configured for.
✗Reduce the ALB health check interval to speed up detection of unhealthy targets.Wrong answer — click to see why▾
Why this is wrong here
Reducing the ALB health check interval speeds up detection of unhealthy targets but does not address the root cause: the ASG is confined to a single AZ. Without instances in other AZs, the ASG cannot launch replacements during an AZ outage.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the ASG already spans multiple AZs and the goal is to reduce recovery time after a failure. For example, an application requires faster failover to healthy instances, and the question asks how to minimize the time to mark instances as unhealthy.
Why candidates choose this
Candidates may think that faster health checks will automatically restore capacity by quickly detecting unhealthy instances, but they overlook that the ASG must have subnets in other AZs to launch replacements.
✗Enable connection draining on the ALB so existing requests complete before targets are terminated.Wrong answer — click to see why▾
Why this is wrong here
Connection draining helps complete in-flight requests before terminating instances, but it does not improve resilience or automatically restore capacity after an AZ outage. The issue is the ASG's lack of multi-AZ subnets, not request handling during termination.
★ When this WOULD be the correct answer
In a scenario where an ALB is deregistering unhealthy targets and you need to ensure existing user sessions finish without interruption before the targets are terminated, enabling connection draining would be the correct answer.
Why candidates choose this
Candidates may confuse connection draining with a resilience feature, thinking it helps maintain availability during failures, when it actually only manages graceful termination of existing connections.
✗Increase the ASG desired capacity from 2 to 6 to compensate for the missing subnets.Wrong answer — click to see why▾
Why this is wrong here
Increasing desired capacity does not address the root cause: the ASG is confined to a single AZ. During an AZ outage, all instances in that AZ become unavailable, and the ASG cannot launch replacements because no subnets exist in other AZs. Higher desired capacity does not help if there are no subnets to launch into.
★ When this WOULD be the correct answer
In a scenario where the ASG already spans multiple AZs but experiences increased load, increasing desired capacity (e.g., from 2 to 6) would help handle the traffic and maintain performance. This would be correct if the question focused on scaling to meet demand rather than AZ failure recovery.
Why candidates choose this
Candidates may think that adding more instances (higher desired capacity) provides a buffer against failures, but they overlook the fact that the ASG cannot launch instances in other AZs if it is only configured with subnets in one AZ. The temptation is to solve capacity issues with numbers rather than architectural redundancy.
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
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.