SAA-C03 Practice Question 65: ASG Scaling on Queue Backlog

CPU is simply not the constraint for this workload, so a CPU target can never reflect the backlog. AWS's documented approach for queue-driven Auto Scaling groups is a target tracking policy on *backlog per instance*: take the queue's ApproximateNumberOfMessages, divide by the number of instances in the InService state, and target the backlog each instance can hold while still meeting the latency you are willing to accept, acceptable latency divided by average processing time per message. Because the metric is per instance, it stays proportional as the group grows and shrinks, which is what makes target tracking behave sensibly in both directions.

Option A measures traffic arriving at a load balancer. These workers take jobs from a queue rather than serving requests, so there is no load balancer in the path and the metric would sit at zero.

Option B is the closest wrong answer, and it fails on proportionality. Raw queue length does not by itself determine how many instances are needed (that also depends on processing time and acceptable delay), so a fixed absolute threshold under-scales during a large burst and keeps firing after the group has grown, which is precisely why AWS recommends the per-instance form instead.

Option C sizes for a schedule rather than for demand. Upload bursts here are driven by users, so scheduled capacity is wasted when the bursts do not arrive and insufficient when they arrive early or larger than the historical peak.

Reference: Scaling policy based on Amazon SQS