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.

• ✓

  Subnets in at least two Availability Zones with health checks enabled

  Why this is correct

  Deploying an Auto Scaling group across subnets in at least two Availability Zones (AZs) is the core of high availability. Each AZ is an isolated failure domain, so if one AZ fails, the ASG continues to run instances in the other AZ(es). Coupled with ELB or ASG health checks, the group automatically detects unhealthy instances—whether due to EC2 failure or AZ impairment—and replaces them, maintaining desired capacity and absorbing request traffic. This design avoids any single point of failure at both the compute and network layers.

• ✗

  All instances in one larger subnet

  Why it's wrong here

  A subnet is scoped to a single Availability Zone; placing all instances in one larger subnet does not make them resilient to an AZ failure. A larger subnet simply provides a bigger IP address range, but all of those instances share the same physical infrastructure and failure domain. If that AZ goes down, every instance in that subnet becomes unreachable, and there is no capacity elsewhere to fail over to. Thus, traffic is continuously lost with no automatic recovery mechanism.

• ✗

  A Network Load Balancer in one subnet

  Why it's wrong here

  An Application Load Balancer or Network Load Balancer is a regional service, but its nodes run in specific subnets. Placing the load balancer in only one subnet confines its entry points to a single AZ; if that AZ fails, the load balancer nodes become unavailable, and traffic cannot be distributed to backend instances even if those instances are healthy in other AZs. For true resilience, the load balancer must be enabled in subnets across at least two AZs so that DNS and routing can continue to direct traffic to surviving nodes.

• ✗

  A single EC2 instance with detailed monitoring

  Why it's wrong here

  Detailed monitoring (1-minute CloudWatch metrics) gives you more granular visibility into an instance's CPU, network, and disk usage, but it does absolutely nothing to provide redundancy or automatic failover. A single EC2 instance remains a single point of failure: if the instance crashes, reboots, or becomes unavailable, there is no second instance to serve requests. Monitoring may alert you to the outage, but it cannot replace the failed instance or reroute traffic, so the application is still down until manual intervention occurs.

Go deeper

Related to this question