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 the Auto Scaling group to launch instances in multiple Availability Zones.

  Why this is correct

  Placing the Auto Scaling group across multiple Availability Zones distributes the EC2 instances between isolated data centers, so the application remains available even if one entire AZ becomes unavailable. The ALB also performs cross-zone load balancing, sending traffic only to healthy instances in the remaining AZs. This configuration is primarily a high-availability measure, not a scaling action, but it underpins the group's ability to replace lost capacity without redirecting all traffic to a single location.

• ✓

  Configure a target tracking scaling policy based on the ALB's RequestCountPerTarget metric.

  Why this is correct

  A target tracking scaling policy uses the Application Load Balancer's RequestCountPerTarget metric to automatically adjust the desired capacity so that the observed value stays close to your chosen target, such as 500 requests per target. This policy continuously evaluates real-time traffic and can add instances within minutes when the per-target count rises, making it effective for reacting to sudden traffic spikes. Because it self-tunes using live load data, it requires no foreknowledge of peak patterns or manual thresholds.

• ✓

  Configure the Auto Scaling group with a dynamic scaling policy.

  Why this is correct

  A dynamic scaling policy, such as a step scaling policy with CloudWatch alarms on CPUUtilization or memory pressure, triggers capacity changes in response to actual demand fluctuations rather than a fixed schedule. When an alarm breaches the threshold, the policy adds or removes instances in defined step adjustments, and each adjustment is subject to a cool-down period to avoid oscillation. This directly addresses unpredictable increases in traffic, whereas scheduled scaling only handles anticipated peaks.

• ✗

  Configure a scheduled scaling policy to add instances during known peak hours.

  Why it's wrong here

  Scheduled scaling only adds instances at preconfigured times, assuming that load patterns are predictable and repeatable. If the company experiences a sudden, unplanned spike outside those scheduled windows, the Auto Scaling group will not react until the next scheduled action, leaving the application without sufficient capacity. Since the question emphasizes reacting to unexpected traffic bursts, this approach fails to meet the requirement.

• ✗

  Use Spot Instances to reduce costs.

  Why it's wrong here

  Using Spot Instances reduces compute costs but does not mitigate sudden traffic spikes, and it introduces the risk of interruption: AWS can reclaim spot capacity with only a two-minute warning, potentially dropping instances and causing downtime. Spot Instances are suitable for stateless, fault-tolerant workloads, but they are inappropriate here because the web application needs consistent, reliable capacity during demand surges. The correct solutions are scaling policies that add on-demand or reserved instances based on real-time load.

Go deeper

Related to this question