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…
Full set: 219 questionsDomain Cost and Performance Optimization
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.
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.
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 breakdown
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
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
Reviewed by David Mercer.
Keep practicing
Take the free SOA-C03 practice test
Ten exam-style questions with answers and explanations, plus the exam facts and study guides.
More questions
Other SOA-C03 practice questions
- Question 1Optimization] A CloudOps engineer is using AWS Compute Optimizer to generate recommendati…
- Question 2A company's developers manually install software modules on Amazon EC2 instances to deplo…
- Question 3A company requires the rotation of administrative credentials for production workloads on…
- Question 4Application A runs on Amazon EC2 instances behind a Network Load Balancer (NLB). The EC2 …
- Question 5A company uses an organization in AWS Organizations to manage multiple AWS accounts. The …
- Question 6A global gaming company is preparing to launch a new game on AWS. The game runs in multip…
