Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Amazon SOA-C03 Exam - Topic 4 Question 12 Discussion

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?
B) Define and use Amazon CloudWatch metric math to calculate the SQS queue backlog for each instance in the target tracking policy.
A) Define and use a new custom Amazon CloudWatch metric based on the SQS ApproximateNumberOfMessagesDelayed metric in the target tracking policy.
C) Define and use step scaling by specifying a ChangeInCapacity value for the EC2 instances.
D) Define and use simple scaling by specifying a ChangeInCapacity value for the EC2 instances.

Amazon SOA-C03 Exam - Topic 4 Question 12 Discussion

Actual exam question for Amazon's SOA-C03 exam
Question #: 12
Topic #: 4
[All SOA-C03 Questions]

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?

Show Suggested Answer Hide Answer
Suggested Answer: B

According to the AWS Cloud Operations and Auto Scaling documentation, scaling applications that consume Amazon SQS messages should be driven by queue backlog per instance, not by general system metrics such as network traffic or CPU.

The correct approach is to calculate a custom metric using CloudWatch metric math that divides the SQS metric ApproximateNumberOfMessagesVisible by the number of active EC2 instances in the Auto Scaling group. This ''backlog per instance'' value represents the average number of messages waiting to be processed by each instance.

Then, the CloudOps engineer can create a target tracking policy that automatically scales out or in based on maintaining a desired backlog threshold. This approach ensures dynamic, workload-driven scaling behavior that reacts in near real time to message volume.

Step and simple scaling (Options C and D) require manual thresholds and do not automatically balance the load per instance.

Thus, Option B---using CloudWatch metric math to define queue backlog per instance for target tracking---is the most effective and AWS-recommended CloudOps practice.


by Gracia at Apr 08, 2026, 09:59 PM

Limited Time Offer

25%

Off

Get Premium SOA-C03 Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Tawanna
1 day ago
I agree with B. Calculating backlog gives better insights.
upvoted 0 times
...
Halina
7 days ago
Option D seems too basic. We need something more dynamic.
upvoted 0 times
...
Nell
12 days ago
I'm leaning towards A as well. Delayed messages are a big issue.
upvoted 0 times
...
Miesha
17 days ago
Option C could work too. Step scaling might react faster.
upvoted 0 times
...
Antione
22 days ago
I prefer option B. Metric math sounds more precise for backlog.
upvoted 0 times
...
Curtis
27 days ago
I think option A is the best. Custom metrics can really help track delays.
upvoted 0 times
...
Tammara
1 month ago
D) is too basic for this situation, we need something smarter!
upvoted 0 times
...
Jacki
1 month ago
Wait, how does A) even help with scaling?
upvoted 0 times
...
Lura
1 month ago
C) could work, but it might not be fast enough.
upvoted 0 times
...
Hubert
2 months ago
I disagree, B) might give better insights into the backlog.
upvoted 0 times
...
Izetta
2 months ago
A) seems like the best option for tracking delays.
upvoted 0 times
...
Kanisha
2 months ago
D) seems outdated, we need to be more dynamic!
upvoted 0 times
...
Mabel
2 months ago
Wait, why not just increase the instance size instead?
upvoted 0 times
...
Xuan
2 months ago
C) is too basic for peak traffic, needs more finesse.
upvoted 0 times
...
Joanne
4 months ago
I think B) could give more insight into the backlog.
upvoted 0 times
...
Audra
4 months ago
A) sounds like a solid choice for tracking delays.
upvoted 0 times
...
Valentin
5 months ago
I’m leaning towards option A, but I’m not entirely confident about how the delayed messages metric works in this context.
upvoted 0 times
...
Julio
5 months ago
I feel like step scaling could be a good choice, but I can't recall the exact differences between step and simple scaling.
upvoted 0 times
...
Portia
5 months ago
I think option B sounds familiar; we practiced calculating backlog metrics in a similar question. That might help with scaling.
upvoted 0 times
...
Ona
5 months ago
I remember we discussed using custom CloudWatch metrics, but I'm not sure if that would be the best approach here.
upvoted 0 times
...

Save Cancel