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.

• ✗

  Replace the existing instances with larger instance types to handle peak load.

  Why it's wrong here

  Replacing the existing instances with larger instance types (vertical scaling) only increases the maximum compute capacity per instance; it does not automatically reduce capacity when demand drops, so you still pay for the larger instances during low-traffic periods. Additionally, you may hit instance size limits within the family, and a single large instance also creates a larger blast radius if it fails. This approach ignores the dynamic nature of web traffic and can significantly increase costs without improving operational agility.

• ✓

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

  Why this is correct

  A target tracking scaling policy is the correct approach because it lets Amazon EC2 Auto Scaling automatically adjust the desired instance count to keep average CPU utilization near a predefined target value (e.g., 50%). CloudWatch alarms monitor the metric, and the policy scale out or scale in by incrementing or decrementing capacity based on the measured deviation from the target. This automated, reactive method handles peak load efficiently and reduces instances during low traffic, directly reducing costs without manual intervention.

• ✗

  Manually scale down the number of instances during off-peak hours.

  Why it's wrong here

  Manually scaling down instances during off-peak hours is operationally brittle because it depends on a human to remember and execute the change at the right time, which is error-prone and does not respond to unpredictable traffic spikes. Manual processes also add operational overhead and can conflict with other changes, such as instance refresh or deployments, leading to downtime or insufficient capacity. A better solution is to automate scaling based on actual demand signals, such as CPU utilization or request count, rather than relying on a fixed schedule.

• ✗

  Purchase Reserved Instances for the baseline capacity.

  Why it's wrong here

  Purchasing Reserved Instances for baseline capacity provides a significant hourly cost discount, but it is a billing commitment, not a scaling mechanism. Reserved Instances do not automatically adjust the number of running instances; you still need Auto Scaling to launch and terminate instances in response to load. While RIs are a smart financial tool for predictable, steady-state capacity, they do not solve the peak load issue by themselves—you still need a dynamic scaling policy to handle fluctuating traffic while maximizing RI coverage.

Go deeper

Related to this question