SOA-C02 Cost and Performance Optimization 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 an Auto Scaling group with a step scaling policy based on CPU utilization.

  Why it's wrong here

  Step scaling policies require you to manually define multiple CloudWatch alarms and adjustment steps, and they only react after a threshold is breached, which introduces lag and often leads to over-provisioning because the policy holds the current capacity until the metric drops below a separate scale-in threshold. For ALB-based workloads, CPU utilization is also a poor proxy for actual user request load because many web applications are I/O-bound or network-bound, so request spikes may not immediately show up in CPU usage. This makes step scaling on CPU slower and less cost-effective than directly tracking the request count per target.

• ✓

  Configure an Auto Scaling group with a target tracking scaling policy based on ALB request count per target.

  Why this is correct

  A target tracking scaling policy with the ALBRequestCountPerTarget metric is purpose-built for web workloads behind an ALB because it continuously adjusts capacity to maintain a specified target value (e.g., 1000 requests per instance), automatically creating and managing the required CloudWatch alarms and scaling activities. This policy responds directly to the metric that reflects actual user traffic per instance, so it scales out quickly when request volume increases and scales in when traffic decreases, significantly reducing idle instance capacity. AWS recommends this approach over CPU or memory based scaling for HTTP(S) applications because it aligns scaling with the real bottleneck—request throughput per instance.

• ✗

  Increase the number of EC2 instances in the Auto Scaling group to handle peak load.

  Why it's wrong here

  Manually increasing the number of EC2 instances in the Auto Scaling group to handle peak load is a form of static scaling that permanently raises the minimum, maximum, or desired capacity to a high value. While this ensures the application can survive a known peak, it leaves that extra capacity running 24/7, wasting compute cost when traffic is low, and it provides no automated response if the actual peak exceeds your estimate. This approach also requires constant manual monitoring and reconfiguration as workload patterns change, unlike dynamic scaling policies that adjust capacity automatically.

• ✗

  Set the Auto Scaling group desired capacity to the maximum expected load.

  Why it's wrong here

  Setting the Auto Scaling group's desired capacity to the maximum expected load forces the ASG to launch and maintain that many instances at all times, completely ignoring load variations and disabling the benefit of any attached scaling policies because the desired capacity always overrides them. This guarantees maximum availability but at the highest possible cost, because every instance runs even during zero-traffic periods, and it offers no protection if traffic exceeds your assumed maximum—the ASG cannot scale beyond the configured max. It is the opposite of elasticity and creates a single fixed compute footprint that does not adapt to either seasonality or unpredictable spikes.

Go deeper

Related to this question