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.

• ✗

  Convert the instance to a Reserved Instance to reduce hourly cost.

  Why it's wrong here

  Reserved Instances are a billing discount that requires a 1- or 3-year commitment for a consistent baseline of usage; they do not add any compute capacity or modify the instance's performance. The reported issue is peak CPU or memory saturation, and converting to a Reserved Instance simply lowers the hourly cost while leaving the instance undersized for the peak window. It is a cost optimization, not a capacity solution, and does nothing to prevent the instance from becoming overloaded.

• ✗

  Replace the instance with a larger instance type and enable detailed monitoring.

  Why it's wrong here

  Selecting a larger instance type could theoretically absorb the peak load, but enabling detailed monitoring (1-minute CloudWatch metrics) incurs additional per-metric charges and has no effect on compute capacity. A bigger single instance also means paying for that larger size 24/7, which is inefficient during off-peak hours when the extra capacity is idle. This approach still relies on one static instance, creating both a cost and a single point of failure issue, rather than dynamically matching capacity to the load.

• ✓

  Create an Auto Scaling group with a scheduled scaling policy to add instances during peak hours.

  Why this is correct

  An Auto Scaling group with a scheduled scaling policy adds EC2 instances before the peak begins and removes them after it ends, aligning running capacity with the predicted demand. This is the correct solution because it handles the peak utilization while avoiding the cost of keeping that extra capacity running all day. You can define the schedule using a cron expression, and the group can also be configured with dynamic policies to absorb unexpected spikes beyond the scheduled capacity.

• ✗

  Increase the instance size to handle peak load at all times.

  Why it's wrong here

  Increasing the instance size to handle the peak load means the instance is massively over-provisioned for the majority of the day when demand is low, wasting money on idle vCPUs and memory. Additionally, this 'scale-up' approach does not improve availability — a single large instance is still a single point of failure, and any future growth beyond that size requires manual intervention. A horizontal 'scale-out' strategy using Auto Scaling is more cost-effective and resilient for predictable peak patterns.

Go deeper

Related to this question