A payments Auto Scaling group has both a target tracking policy, aimed at holding average CPU near a set point, and a step scaling policy on the same CPU metric. Capacity oscillates all afternoon. The team wants the CPU held near that set point. Which change matches the goal?
Select an answer to reveal the explanation.
Short Explanation
Two controllers acting on the same steering wheel can make capacity wander. You want CPU near a set point, which is what target tracking is designed to do. Removing step scaling keeps that behavior; suspending launches and terminations or pinning the group at one instance would stop useful scaling instead.
Full Explanation
Target tracking adjusts capacity to hold average CPU near a target, creating the scale-out and scale-in alarms it needs. A step scaling policy on that same CPU metric makes separate capacity changes, so the two controllers can overshoot and cause the observed oscillation. Removing step scaling while keeping target tracking leaves the policy that matches the goal. Removing target tracking and continuing to add step adjustments abandons set-point behavior; step adjustments apply configured changes rather than continuously aiming to hold CPU near a target. Suspending the Launch and Terminate processes prevents either policy from changing capacity, so the group cannot respond to load. Pinning the group to one instance and deleting both policies also gives up elasticity and cannot reliably hold CPU near the target as demand changes. Exam caveat: the conflict described is between two policies using the same CPU signal; the key is to retain the control behavior that matches the stated goal. Practical check: after removing step scaling, observe desired capacity through a load change and confirm that it settles rather than oscillates.