SOA-C02 Reliability and Business Continuity Practice Question
A SysOps administrator is troubleshooting an issue where an Auto Scaling group is not launching EC2 instances despite having a scaling policy that should trigger when CPU utilization exceeds 80%. The CloudWatch alarm shows that the metric is breaching the threshold, but no instances are launched. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates often focus on the scaling policy type or alarm state, overlooking the fundamental capacity constraint of the Auto Scaling group's maximum size.
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 Auto Scaling group has reached its maximum size.
When an Auto Scaling group reaches its maximum size, it cannot launch new instances even if a scaling policy is triggered. The CloudWatch alarm breaching the threshold indicates the scaling condition is met, but the group's capacity limit prevents any new instance launches. This is a common misconfiguration where the max size is set too low relative to the desired or current capacity.
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 incorrectly configured to use a simple scaling policy instead of a step scaling policy.
Why it's wrong here
Both simple scaling policies and step scaling policies can trigger a scale-out event when the associated CloudWatch alarm reaches the ALARM state. The difference lies in how the adjustment is determined—step scaling supports multiple step adjustments based on alarm breach magnitude, while simple scaling uses a single adjustment. Using simple instead of step would still launch new instances, so it does not explain why no instances are being added.
- ✗
The health check grace period is too long.
Why it's wrong here
The health check grace period controls how long an Auto Scaling group waits after an instance launches before it begins checking that instance's health status. This setting has no bearing on the decision to launch new instances; it only delays the time before an unhealthy instance can be terminated. A longer grace period would not prevent the scaling policy from initiating a scale-out activity.
- ✓
The Auto Scaling group has reached its maximum size.
Why this is correct
The Auto Scaling group has reached its maximum size, which is a hard limit that prevents any scale-out activity from adding new instances. When a scale-out policy is triggered while the group is already at MaxSize, the scaling process simply skips or fails the launch because it would exceed the group's maximum capacity. This is the most direct explanation for the alarm breaching but no new instances appearing.
- ✗
The CloudWatch alarm is in insufficient data state.
Why it's wrong here
The CloudWatch alarm is described as breaching, meaning it is in the ALARM state and actively triggering the scaling policy. Insufficient data is a separate alarm state where there is not enough metric data to evaluate the threshold, and in that state the alarm would not fire. Since the alarm is not in INSUFFICIENT_DATA, this option cannot be the reason scaling is not occurring.
Go deeper
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.