SOA-C02 Reliability and Business Continuity Practice Question

An application running on EC2 instances in an Auto Scaling group uses an SQS queue for decoupling. The application experiences increased latency when the queue has a high number of messages. The SysOps Administrator needs to maintain responsiveness. Which solution is the most cost-effective?

⚠ Common exam trap

A common mix-up: candidates confuse static scaling (Option A) or vertical scaling (Option C) with dynamic, demand-based scaling, or mistakenly think that increasing the visibility timeout (Option D) will reduce queue depth, when in fact it only delays message reprocessing.

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

✓

Configure a CloudWatch alarm on the queue depth to trigger Auto Scaling policies.

Using a CloudWatch alarm on the SQS queue depth (ApproximateNumberOfMessagesVisible) to trigger Auto Scaling policies allows the Auto Scaling group to dynamically add EC2 instances only when the queue grows, directly addressing increased latency by scaling out compute capacity. This is the most cost-effective approach as it scales resources based on actual demand, avoiding over-provisioning.

Answer analysis

Option-by-option breakdown

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

✗
Increase the desired capacity of the Auto Scaling group.
Why it's wrong here
Manually raising the desired capacity forces the ASG to maintain a fixed, higher instance count at all times, even during quiet periods. This static approach lacks the feedback loop from SQS queue depth, so you pay for idle capacity whenever demand drops. Dynamic scaling triggered by the queue backlog achieves the same responsiveness without running surplus instances continuously.
✓
Configure a CloudWatch alarm on the queue depth to trigger Auto Scaling policies.
Why this is correct
Create a CloudWatch alarm on the SQS metric ApproximateNumberOfMessagesVisible, the number of messages waiting in the queue, and attach it to a scaling policy for the ASG. When the backlog exceeds a threshold, the alarm enters ALARM state and adds instances to consume messages faster; when the queue drains, it removes instances. This directly couples consumer fleet size to actual demand, providing cost-efficient elasticity that avoids both under-provisioning and idle over-provisioning.
✗
Use a larger instance type for the EC2 instances.
Why it's wrong here
Switching to a larger instance type increases the CPU and memory available to each individual worker, but it does not add more workers pulling from the SQS queue. When the queue backlog is high because the number of consumers is the constraint, a bigger instance still processes only one message at a time under the same polling concurrency. It also increases hourly cost while potentially leaving headroom unused, so scale out, not up, is the correct fix.
✗
Increase the visibility timeout of the SQS queue.
Why it's wrong here
The visibility timeout determines how long a message remains hidden after a consumer receives it, preventing other workers from reading the same message during processing. Increasing it does nothing to raise the rate at which messages are consumed or reduce a growing backlog; it merely delays retries and can cause messages to remain unprocessed longer if a worker fails. The fix for a persistent backlog is more consumers via autoscaling, not a longer visibility window.

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Related to this question