SOA-C02 Reliability and Business Continuity Practice Question
A company runs a web application on EC2 instances in an Auto Scaling group behind an Application Load Balancer. The application is deployed in a single Availability Zone. The SysOps administrator notices that during peak hours, the application becomes slow and some requests fail. CloudWatch metrics show that CPU utilization on the instances reaches 90%, but the Auto Scaling group does not scale out. The administrator has configured a target tracking scaling policy based on average CPU utilization with a target value of 75%. The Auto Scaling group has a minimum of 2, maximum of 10, and desired capacity of 2. What is the MOST likely reason the Auto Scaling group is not scaling out?
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 is configured with a single Availability Zone, and the target tracking policy cannot scale out beyond the capacity of that single AZ.
The most likely reason is that the Auto Scaling group is configured with a single Availability Zone. Target tracking scaling policies operate within the constraints of the configured subnets. If the group is only in one AZ, the subnet may have insufficient IP addresses or the AZ may have reached its instance limit, preventing the group from scaling out beyond that AZ's capacity. Since the group has a maximum of 10, but the AZ capacity is limited, the scaling policy cannot add more instances. This is a common issue: AWS recommends using multiple Availability Zones for Auto Scaling groups to allow scaling across AZs and avoid single points of failure.
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 Auto Scaling group is configured with a single Availability Zone, and the target tracking policy cannot scale out beyond the capacity of that single AZ.
Why this is correct
The Auto Scaling group is constrained to a single Availability Zone, and the target tracking policy cannot add instances if that specific AZ does not have sufficient capacity for the instance type defined in the launch template. Auto Scaling attempts to launch new instances, but because the group does not span multiple AZs, it cannot shift to another AZ when the sole AZ reports InsufficientInstanceCapacity. Quotas such as vCPUs typically apply per-region, but the AZ-level capacity limitation is the specific reason here—even though the group's maximum is 10, scale-out fails because there is no available capacity in that one AZ.
- ✗
The target tracking policy uses a target value of 75%, but the average CPU is above that, so it should scale out.
Why it's wrong here
The entire purpose of a target tracking policy is to add instances when the metric exceeds the target value. Saying that the average CPU is above 75% explains why scaling should occur, not why it is failing to occur. The policy's threshold logic is functioning correctly; the failure is caused by the underlying capacity limitation in the sole Availability Zone, not by any mismatch in the CPU target.
- ✗
The target tracking policy requires detailed monitoring to be enabled on the instances.
Why it's wrong here
Target tracking policies do not require detailed monitoring. They work perfectly well with basic monitoring, which publishes EC2 metrics every five minutes; detailed monitoring simply provides one-minute resolution for faster and smoother scaling decisions. Lack of detailed monitoring may delay the scaling decision, but it will not prevent the policy from issuing a scale-out activity, so this is not the reason the ASG is stuck at two instances.
- ✗
The Auto Scaling group has reached its maximum capacity of 10 instances.
Why it's wrong here
The Auto Scaling group's maximum capacity is 10, and it is currently running only 2 instances, so there is ample headroom to scale out. Reaching the maximum would be a clear explanation for why scaling stops, but the group is far from that limit. The real issue is that the group is bound to a single Availability Zone, which imposes a capacity ceiling that is independent of the configured maximum—so the scale-out is blocked by AZ resource exhaustion, not by the max size setting.
Visual reference
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.