SOA-C03 practice question 8 of 10

Optimization] A company uses an Amazon Simple Queue Service (Amazon SQS) queue and Amazon EC2 instances in an Auto Scaling group with target tracking…

Choose your answer, then check it against the explanation and the full breakdown below.

Domain Cost and Performance Optimization

Optimization] A company uses an Amazon Simple Queue Service (Amazon SQS) queue and Amazon EC2 instances in an Auto Scaling group with target tracking for a web application. The company collects the ASGAverageNetworkIn metric but notices that instances do not scale fast enough during peak traffic. There are a large number of SQS messages accumulating in the queue. A CloudOps engineer must reduce the number of SQS messages during peak periods. Which solution will meet this requirement?

Answer options

Correct Answer:

Explanation

The core issue is that the Auto Scaling group (ASG) is scaling based on network input (ASGAverageNetworkIn), which is not a direct measure of the application's workload backlog residing in the SQS queue. The most effective way to scale a fleet of workers processing messages from an SQS queue is to scale based on the number of messages waiting to be processed.

The recommended AWS pattern for this scenario is to use a target tracking scaling policy with a custom metric. This custom metric is created using Amazon CloudWatch metric math to calculate the backlog per instance (ApproximateNumberOfMessagesVisible / GroupInServiceInstances). This ensures that the ASG adds or removes instances to keep the backlog per instance at a target value, directly aligning scaling actions with the actual workload.

Why Incorrect

A. The ApproximateNumberOfMessagesDelayed metric tracks messages intentionally delayed using a timer, not the active backlog of messages ready for processing. The correct metric for the backlog is ApproximateNumberOfMessagesVisible.

C. Step scaling is a valid scaling policy, but it does not solve the fundamental problem of using an inappropriate metric (ASGAverageNetworkIn) as the scaling trigger. The trigger itself must be changed first.

D. Simple scaling is an outdated policy type that is generally not recommended. It has a cooldown period that can hinder responsiveness, and like step scaling, it doesn't fix the core issue of using the wrong metric.

References

1. AWS Documentation - Scaling based on Amazon SQS: This official guide explicitly details the solution. It states

"To use an SQS queue as a scaling metric for your Auto Scaling group

create a CloudWatch metric that captures the SQS queue's backlog... Then

create a target tracking scaling policy that configures your Auto Scaling group to scale based on the custom metric." It provides the exact metric math formula: ApproximateNumberOfMessagesVisible / GroupInServiceInstances.

Source: Amazon EC2 Auto Scaling User Guide

"Scaling based on Amazon SQS".

2. AWS Documentation - Target tracking scaling policies: This document explains the mechanism of target tracking and its benefits. It notes

"With target tracking scaling policies

you select a scaling metric and set a target value... For example

you can configure a target tracking scaling policy to keep the average number of messages in your SQS queue per EC2 instance at 100."

Source: Amazon EC2 Auto Scaling User Guide

"Target tracking scaling policies for Amazon EC2 Auto Scaling".

3. AWS Documentation - Using metric math: This document describes how to create new time series by applying mathematical expressions to existing CloudWatch metrics

which is the technique required for this solution.

Source: Amazon CloudWatch User Guide

"Using metric math".

Question 8 of 10

Question breakdown

Tests: Choose an appropriate scaling metric for queue-based workloads
Difficulty: Medium

Key idea: Workers that consume from SQS should scale on backlog per instance, calculated with metric math as visible messages divided by in-service instances, and used in a target tracking policy.

How to reach the answer

The symptom is a growing SQS queue while the group scales on network input.
The root cause is the scaling metric, which does not reflect the queued work.
Backlog per instance (ApproximateNumberOfMessagesVisible / GroupInServiceInstances) measures the real workload.
Target tracking can use a metric math expression directly, so it adjusts capacity to hold the backlog at a target value.
Changing only the policy type (step or simple) leaves the wrong metric in place.

Each option

AIncorrect. ApproximateNumberOfMessagesDelayed counts messages held back by delay settings, not messages waiting to be processed.
BCorrect. Metric math backlog per instance in target tracking ties capacity directly to queue depth.
CIncorrect. Step scaling changes how the group responds, not what metric drives it, so the mismatch remains.
DIncorrect. Simple scaling has the same metric problem and waits for cooldowns, so it responds more slowly.

Common trap: Option A names an SQS metric and looks queue-aware, but 'Delayed' is the wrong metric; the backlog is the visible messages.

In practice: Batch and worker fleets that drain SQS queues are routinely scaled on backlog per instance, so processing keeps up during traffic spikes.

Remember: Scale SQS consumers on ApproximateNumberOfMessagesVisible divided by in-service instances, using target tracking.

Official documentation: Scaling policy based on Amazon SQS · Target tracking scaling policies for Amazon EC2 Auto Scaling

Drafted with AI assistance and checked against the answer key.

Keep practicing

Take the free SOA-C03 practice test

Ten exam-style questions with answers and explanations, plus the exam facts and study guides.

Start the free practice test