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.

• ✗

  Switch to a target tracking scaling policy based on request count per target.

  Why it's wrong here

  A target tracking scaling policy based on request count per target keeps the average request count near a set value, so it scales out quickly during spikes. However, it does not change the underlying instance purchasing option; every launched instance is still On-Demand, so you pay the full per-hour rate for all capacity. It improves responsiveness and can even reduce idle capacity, but it cannot deliver the substantial cost savings that a mixed Spot/On-Demand strategy provides, making it a scalability fix, not a cost fix.

• ✗

  Implement scheduled scaling to add capacity during known peak hours.

  Why it's wrong here

  Scheduled scaling adds or removes capacity at fixed times you define in advance, which works well for predictable patterns like nightly batch jobs or business-hours traffic. The scenario describes variable, unpredictable demand, so you would either under-provision and still see throttling or over-provision and pay for unused instances. You would still be launching On-Demand instances at scheduled peak times, missing the opportunity to use lower-cost Spot capacity, so it does not meaningfully reduce cost while handling spikes reliably.

• ✓

  Configure the Auto Scaling group to use a mixed instances policy with Spot Instances for a portion of the capacity and On-Demand for the remainder.

  Why this is correct

  A mixed instances policy lets an Auto Scaling group launch both Spot and On-Demand Instances, with the ability to define a percentage split (e.g., 50% On-Demand and 50% Spot) across multiple instance types. Spot Instances can be 60–90% cheaper than On-Demand, so running a portion of the spike capacity on Spot delivers significant cost savings. The On-Demand portion maintains a stable baseline, while the Spot portion absorbs burst capacity; if Spot capacity is reclaimed, the group can optionally fall back to On-Demand, preserving availability and making this the most cost-effective, resilient choice for variable traffic.

• ✗

  Purchase Reserved Instances for the minimum expected capacity to get a discount.

  Why it's wrong here

  Purchasing Reserved Instances locks you into a commitment for a fixed amount of capacity, which you must pay for whether or not you use it, typically over a 1- or 3-year term. While this reduces the hourly rate for that baseline capacity, it does nothing to reduce the cost of unpredictable spikes because the additional capacity needed at peak times would still be launched as On-Demand or Spot instances. You would have to over-provision RIs to cover the spikes, leading to waste when traffic is low, or under-provision and still pay expensive On-Demand rates during peaks—either way, this option fails to control cost under variable load.

Go deeper

Related to this question