SAA-C03 Design Resilient Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the Auto Scaling group desired capacity from 2 to 3 in the same subnet.

  Why it's wrong here

  Increasing the Auto Scaling group's desired capacity to three in the same subnet keeps every EC2 instance within a single Availability Zone, which is the same failure domain shown in the exhibit. If us-west-2a suffers an outage, all three instances fail simultaneously because they share the same physical dependency. Horizontal scaling in one AZ does not add redundancy; it just increases the blast radius of an AZ failure.

  When this WOULD be correct

  If the question asked how to handle increased traffic without changing AZ architecture, increasing desired capacity would be correct to distribute more instances within the existing subnet.

• ✓

  Attach the Application Load Balancer and Auto Scaling group to subnets in a second Availability Zone.

  Why this is correct

  Spanning the load balancer and Auto Scaling group across at least two Availability Zones removes the single-AZ dependency shown in the exhibit. If us-west-2a fails, the remaining AZ can continue serving traffic and Auto Scaling can replace unhealthy instances there. This is the smallest architectural change that directly improves availability.

• ✗

  Replace the Application Load Balancer with a Network Load Balancer.

  Why it's wrong here

  Replacing the Application Load Balancer with a Network Load Balancer does not change the deployment's Availability Zone topology because both load balancer types are zonal—they are provisioned only in the subnets you explicitly attach. If the NLB still uses the original single-AZ subnets, it remains in the same failure domain, and an outage of us-west-2a continues to take down both the load balancer nodes and the target instances. A different Layer 4/7 load balancer type cannot provide cross-AZ resilience on its own; you still must attach subnets in a second AZ.

  When this WOULD be correct

  If the question required handling sudden traffic spikes with minimal latency and the application could tolerate connection draining, a Network Load Balancer might be chosen for its higher throughput and static IP support, but only if the architecture already spans multiple AZs.

• ✗

  Increase the health check grace period so instances stay registered longer.

  Why it's wrong here

  The health check grace period only delays when Auto Scaling starts replacing an instance after it fails its health checks. During a full Availability Zone outage, the Application Load Balancer cannot reach any target in that subnet, so extending the grace period merely postpones the inevitable replacement and leaves the service unavailable longer. It does not introduce a second Availability Zone, nor does it give the ASG a healthy location to fail over to.

  When this WOULD be correct

  A question where instances are being prematurely terminated due to transient health check failures (e.g., brief CPU spikes) and the goal is to avoid unnecessary instance replacement without changing architecture. The correct answer would be to increase the grace period to allow 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.

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