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.

• ✓

  Configure a target tracking scaling policy based on average CPU utilization.

  Why this is correct

  A target tracking scaling policy automatically adjusts the Auto Scaling group's desired capacity based on a CloudWatch metric, such as average CPU utilization, to keep the metric close to a specified target value. For a stateless web app with varying traffic, this provides true elasticity, scaling out to handle spikes and scaling in when demand falls, without manual intervention. Because it directly maps load to capacity, it is the most effective single choice among the listed options.

• ✗

  Enable detailed monitoring for EC2 instances.

  Why it's wrong here

  Enabling detailed monitoring for EC2 instances publishes CloudWatch metrics at 1-minute intervals instead of 5-minute, but this merely provides more frequent data points; it does not, by itself, cause any scaling action. While it can help Auto Scaling policies respond faster because CloudWatch alarms evaluate recent data, the scaling policy is still required to act on the metric. Since the question asks for a solution to handle traffic spikes, detailed monitoring alone is insufficient and adds extra cost without granting automatic scaling.

• ✗

  Use a larger instance type to handle more traffic per instance.

  Why it's wrong here

  Moving to a larger instance type (vertical scaling) increases the capacity of a single instance, but does not make the environment elastic; you still provision for peak traffic at all times. It often leads to inefficient resource utilization during low traffic periods and introduces a single point of failure if only one large instance is used. The correct approach is horizontal scaling with multiple smaller instances, which allows the workload to flexibly adapt to changing demand by adding or removing instances.

• ✓

  Configure the Auto Scaling group to launch instances in multiple Availability Zones.

  Why this is correct

  Configuring the Auto Scaling group to launch instances across multiple Availability Zones ensures that the application remains available if an entire AZ fails, since traffic can be served by instances in other zones. Auto Scaling balances instances across the enabled AZs automatically and replaces any that become unhealthy, promoting fault tolerance. While this does not directly handle traffic spikes, it is a necessary complement to a scaling policy to maintain both elasticity and high availability.

• ✓

  Place the instances behind an Application Load Balancer with health checks.

  Why this is correct

  Placing instances behind an Application Load Balancer (ALB) with health checks enables incoming traffic to be distributed across all healthy instances, while the ALB stops sending traffic to instances that fail health checks. This allows the Auto Scaling group to safely replace unhealthy instances without interrupting user sessions, and it ensures that newly launched instances only start receiving traffic once they have passed the health check. Together with a scaling policy, the ALB is essential for handling spikes reliably, making it a correct component of the solution.

Go deeper

Related to this question