DOP-C02 Incident and Event Response Practice Question

A DevOps engineer is investigating why an Amazon ECS service is not scaling out as expected. The service has a target tracking scaling policy based on average CPU utilization. The CloudWatch alarm shows that CPU utilization has exceeded the target for several minutes, but no scaling activity has occurred. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates often overlook the cooldown period and instead blame IAM permissions or alarm configuration, but the cooldown is a deliberate stabilization mechanism that directly explains why scaling is not occurring despite the alarm being active.

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

✓

The scaling policy has a cooldown period that is still in effect from a previous scaling activity.

Target tracking scaling policies in Amazon ECS have a cooldown period (default 300 seconds) that prevents the policy from initiating additional scaling activities immediately after a previous scaling action. If a recent scaling activity occurred, the cooldown period would still be in effect, causing the policy to ignore the alarm even though CPU utilization has exceeded the target. This is the most likely reason no scaling activity is observed despite the alarm being triggered.

Answer analysis

Option-by-option breakdown

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

✗
The ECS service is configured with a minimum healthy percent that prevents scaling out.
Why it's wrong here
The minimum healthy percent is a deployment configuration parameter used by ECS to control how many tasks must remain available during a rolling update, not a scaling constraint. Automatic scaling adds or removes tasks by adjusting the desired count independently of the deployment lifecycle, so a high minimum healthy percent would only slow or block new task versions during deployments, not prevent scale-out actions.
✗
The ECS service does not have an IAM role that allows it to call CloudWatch.
Why it's wrong here
ECS service auto scaling does not rely on the ECS service's IAM role to call CloudWatch. Instead, Application Auto Scaling uses the service-linked role AWSServiceRoleForApplicationAutoScaling_ECSService, which grants permissions to read CloudWatch alarms and adjust the desired count. The task execution role or task role is used for pulling container images and accessing AWS services from within the container, but neither is involved in the scaling decision path.
✗
The CloudWatch alarm is configured with a period that is too long.
Why it's wrong here
A long CloudWatch alarm period affects how frequently the alarm evaluates metrics, but if the alarm has already entered the ALARM state, the scaling action should be triggered on the next evaluation. The period does not prevent an alarm from firing once the threshold is breached; it only delays detection. In this scenario, an alarm that is already breached should invoke the scaling policy unless another mechanism, such as a cooldown, is suppressing the action.
✓
The scaling policy has a cooldown period that is still in effect from a previous scaling activity.
Why this is correct
A cooldown period is a duration after a scaling activity during which the scaling policy cannot trigger another action, even if the CloudWatch alarm remains in breach. In Application Auto Scaling, this prevents rapid oscillation and lets the newly added tasks take effect. If a previous scale-out or scale-in occurred recently, the outstanding cooldown will block the new scaling request, which exactly matches the symptom of the alarm being breached but no scaling activity occurring.

Go deeper

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question