SOA-C02 Reliability and Business Continuity 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.

• ✗

  Launch all EC2 instances in a single Availability Zone to reduce latency

  Why it's wrong here

  Placing every EC2 instance in one Availability Zone concentrates all traffic into a single failure domain, so any failure affecting that AZ (e.g., loss of power, networking, or cooling) will simultaneously take down the entire application stack. Even if inter-instance latency is marginally lower, the goal of high availability is to survive individual AZ outages, so distributing instances across at least two AZs is a fundamental prerequisite. AWS recommends a minimum of two AZs for any production workload, regardless of the resulting network round-trip time.

• ✗

  Use t2.micro instances to reduce cost

  Why it's wrong here

  The t2.micro instance type is a burstable, low-cost offering with limited baseline CPU and memory, making it unsuitable for most production workloads and likely to become a bottleneck under normal traffic, which can lead to throttling, latency spikes, or instance stalls. High availability is not achieved by choosing a cheaper instance but by ensuring redundant capacity and resilient configuration; undersizing can actually decrease availability because instances may fail health checks or crash under load. Cost optimization is separate from resilience—right-sizing based on workload requirements is essential, but it is not a substitute for a multi-AZ architecture.

• ✓

  Configure the ALB with health checks for the target group

  Why this is correct

  The ALB continuously sends health-check requests (e.g., HTTP GET to a specified path) to each instance in its target group; an instance that fails a set number of consecutive checks is marked unhealthy and automatically deregistered, so the ALB stops forwarding new traffic to it and reroutes incoming requests to healthy instances. Configuring health checks with appropriate interval, timeout, and threshold values detects underlying application or instance failures early, enabling rapid failover and improving overall fault tolerance. This is a critical control point; without meaningful health checks, even a perfectly scaled fleet will serve errors to a portion of requests.

• ✗

  Disable health checks to reduce load on the ALB

  Why it's wrong here

  Disabling health checks on the ALB removes the automated detection that distinguishes healthy instances from failed ones, so the load balancer will continue routing traffic in the same proportion to instances with broken processes, causing users to see intermittent 5xx errors and impairing the ability of the Auto Scaling group to replace unhealthy capacity. The ALB's health-check traffic is negligible relative to the operational intelligence it provides; the cost of a few bytes per interval is vastly outweighed by the impact of continuing to send production traffic to dead instances. In practice, health checks should be fine-tuned, not eliminated, to avoid treating a merely slow instance as unhealthy while still catching hard failures.

• ✓

  Configure the Auto Scaling group to launch instances in at least two Availability Zones

  Why this is correct

  Configuring the server group to span at least two Availability Zones (by specifying a VPCZoneIdentifier with subnets in each AZ) ensures that if an entire AZ fails, healthy capacity still exists in the other zone, and the Auto Scaling group can keep the desired instance count by launching new instances in the surviving AZ. This is a core component of an elastic, highly available architecture, as it eliminates the availability zone as a single point of failure. The combination of an ALB that distributes traffic across both AZs and an Auto Scaling group that maintains minimum capacity across multiple AZs is what allows an application to withstand an AZ-wide outage without manual intervention.

Go deeper

Related to this question