SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a steady-state HTTP API on a fleet of Amazon EC2 instances behind an Application Load Balancer. The operations team needs to reduce cost without degrading performance or availability. They observe that CPU utilization is consistently 8–12% and memory utilization is around 40%. The workload is stateless and can tolerate a brief instance restart during deployment. Which change should a solutions architect recommend to meet the cost-reduction goal?

⚠ Common exam trap

The trap here is assuming that a Savings Plan or Reserved Instance discount is the fastest path to lower cost, when it only discounts capacity the workload does not actually need.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Migrate the workload to a smaller instance type and adjust the Auto Scaling group's desired capacity to match observed peak demand.

The fleet is stateless, load balanced, and running far below capacity, which makes right-sizing the instance type and re-calibrating desired capacity the most direct lever for cost reduction. A launch template update combined with an instance refresh can roll the change out without downtime. Savings Plans and monitoring changes reduce or report cost but never eliminate the waste from consistently idle compute.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable detailed CloudWatch monitoring at one-minute resolution and add a dashboard for CPU and memory metrics.
Why it's wrong here
Detailed monitoring improves the granularity of metric data and speeds up Auto Scaling reactions, but it does not reduce the number or size of running instances. The team already knows utilization is low; more precise telemetry simply confirms the existing observation. This option adds a small monitoring cost and leaves the oversized fleet in place, so it does not satisfy the cost-reduction requirement.
✓
Migrate the workload to a smaller instance type and adjust the Auto Scaling group's desired capacity to match observed peak demand.
Why this is correct
The workload is stateless and consistently underutilized, so right-sizing to a smaller instance type and calibrating desired capacity to actual peak demand removes idle compute. Because the fleet sits behind a load balancer and tolerates brief restarts, the resize can be performed with a launch template update and an instance refresh, preserving availability while lowering the hourly run rate.
✗
Purchase a 3-year All Upfront Compute Savings Plan covering the existing instance family and run the fleet unchanged.
Why it's wrong here
A Compute Savings Plan lowers the effective hourly rate but does not change the fleet's size or shape. Because the instances are already running at 8–12% CPU, the company keeps paying for capacity it never uses. Committing for three years also locks in the current, oversized footprint, so the recommendation fails to address the dominant driver of waste here: idle compute.
✗
Replace the Application Load Balancer with a Network Load Balancer and route traffic directly to the instances.
Why it's wrong here
Changing the load balancer tier alters connection handling and latency characteristics, not the compute cost of the fleet. The EC2 instances continue to run at the same size and count, so the dominant expense is untouched. A Network Load Balancer is also a poor fit for an HTTP API that may rely on layer 7 routing, and it introduces a functional change without delivering savings.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question