How Should Order Collection and Fulfillment Scale Without Data Loss?
Short answer
D Provision two Amazon SQS queues, have each EC2 Auto Scaling group poll its own queue, and scale each group on the number of messages in its queue.
Question
Key Takeaways
It tests loose coupling with SQS plus queue-depth-based scaling; the trap is option C, which sounds identical but claims the queues themselves 'send notifications' to trigger scaling, which SQS does not do.
This SAA-C03 question tests how to decouple a fast order-collection tier from a slower order-fulfillment tier so both can scale independently without losing data during peak traffic. The correct design uses two Amazon SQS queues and scales each Auto Scaling group by queue depth, making D the answer.
Common mistake: Option C is the most common wrong choice because it prescribes the right architecture (two SQS queues, EC2 instances polling them) but the wrong scaling trigger — SQS does not push notifications that scale Auto Scaling groups, and the queues need CloudWatch alarms or target tracking policies instead.
Expert Analysis
Why the Answer Is Correct
Option D is correct because it separates the two workloads with Amazon SQS, so messages are durably buffered while the fulfillment fleet catches up instead of being lost when instances are added or terminated by a scaling event. Each tier polls its own queue, which is the canonical producer/consumer decoupling pattern on AWS. Scaling on the number of messages in each queue (via a target tracking policy on the SQS backlog per instance, or a CloudWatch alarm on ApproximateNumberOfMessagesVisible) ties capacity directly to outstanding work rather than to a proxy metric. That lets the fast collection tier and the slower fulfillment tier each scale on their own backlog, meeting the requirement that both scale adequately during peak hours. SQS also removes the tight conversational coupling that would otherwise force collection to wait on fulfillment.
Why the Other Options Are Wrong
Option A only monitors CPUUtilization and pins each Auto Scaling group's minimum capacity to its peak value, which replaces elasticity with permanent over-provisioning and costs money while providing no message buffering if fulfillment falls behind. Option B adds an Amazon SNS topic that 'creates additional Auto Scaling groups on demand', which is not a supported scaling mechanism — SNS notifies subscribers, it does not provision or scale Auto Scaling groups, and CPU is still a poor proxy for queue backlog. Option C is the strongest distractor because it also deploys two SQS queues, but it says to scale the groups 'based on notifications that the queues send'; SQS is a pull-based service that does not emit notifications that resize capacity, so the trigger described simply does not exist as written.
Community Comment Notes
All three visible voters land on D, and their reasoning matches the official design doctrine. As sOI852POL put it, the intent is to use SQS so that "data is not lost because of a scaling event" and to "scale based on number of messages on the queue." 8621a7c and aragon_saa both keep it short — "Go with D" and "Answer is D" — so the consensus offers no contrary technical argument to weigh against the analysis above.
Official Reference
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-monitoring-using-cloudwatch.html
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question stresses that 'data must not be lost because of a scaling event' and the two tiers run at different speeds, look for a durable buffer (SQS) plus a scaling metric tied to backlog, not CPU. Eliminate any option whose scaling trigger is a notification or service action that AWS does not actually perform.
Frequently Asked Questions
Why is option C wrong when it also uses two SQS queues?
How does SQS prevent data loss during a scaling event?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
sOI852POL 👍 4 Answered DSQS to ensure data is not lost because of a scaling event, scale based on number of messages on the queue.
-
aragon_saa 👍 2 Answered DAnswer is D
-
8621a7c 👍 2 Answered DGo with D
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →