SOA-C02 Monitoring, Logging, and Remediation Practice Question
A SysOps administrator notices that an Amazon EC2 instance's CPU utilization is consistently above 90% during business hours. The instance is part of an Auto Scaling group with a simple scaling policy based on average CPU utilization. However, the Auto Scaling group is not launching new instances. What is the most likely cause?
⚠ Common exam trap
Candidates often assume high CPU utilization always triggers a scale-out immediately, forgetting that simple scaling policies enforce a cooldown period that can delay subsequent scaling actions, even when the metric remains elevated.
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 is in a cooldown period after a previous scaling activity.
The simple scaling policy in Auto Scaling has a cooldown period (default 300 seconds) that prevents the group from launching or terminating instances immediately after a previous scaling activity. If the policy triggered a scale-out event recently, the cooldown period is still active, so even though CPU utilization remains above 90%, no new instances are launched until the cooldown expires. This is the most likely cause because the cooldown is designed to stabilize metrics and avoid thrashing.
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 scaling policy is in a cooldown period after a previous scaling activity.
Why this is correct
The cooldown period is a timer that initiates after a simple scaling policy performs an activity, during which all subsequent scaling requests from that policy are ignored until the timer expires—by default 300 seconds. Because the group recently acted, the alarm-driven scale-out request is suppressed even though CPU utilization remains elevated, preventing a rapid series of changes while the newly launched instance passes standard health checks and the alarm evaluation period resets. Once the cooldown timer expires, the policy can immediately respond to any new breach of the CPU utilization threshold.
- ✗
The Auto Scaling group has a minimum size equal to the current number of instances.
Why it's wrong here
The Auto Scaling group's minimum size establishes a hard lower limit for the group's desired capacity; it prevents the group from scaling in below that number, but it places no upper bound on the desired capacity. Even if the current instance count equals the minimum, a dynamic scaling policy can still increase the desired capacity to a larger number (for example, from 2 to 3) because this action is not constrained by the minimum setting. Therefore, a minimum size matching the current number of instances cannot be the reason a scale-out alarm is not triggering additional capacity.
- ✗
The Auto Scaling group has a scheduled scaling action that is overriding the dynamic policy.
Why it's wrong here
Scheduled scaling actions are configured to execute at specific pre-defined times (for example, every morning at 9:00) and they adjust the desired capacity directly for those moments only. They are evaluated exclusively at their designated schedule and do not permanently override or suppress dynamic scaling policies, which continue to react to alarm state changes throughout the day. Unless the scheduled action is currently executing, it has no bearing on why a target tracking or simple scaling policy fails to add instances in response to high CPU utilization.
- ✗
The instance is not healthy and is being terminated by the Auto Scaling group.
Why it's wrong here
An unhealthy instance is identified by Amazon EC2 Auto Scaling through EC2 status checks, Elastic Load Balancing health checks, or custom health checks, and the group will replace it by terminating the unhealthy instance and launching a new one to maintain the desired capacity. The instance described in the question is still running and showing high CPU, which suggests it is passing its status checks rather than being in the Terminating state, and even if it were unhealthy, the Auto Scaling group would not wait for cooldown before launching a replacement—it would correct the capacity immediately. This termination-and-replacement process is unrelated to a scaling policy being suppressed, so it does not explain the missing scale-out activity.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.