Exams / SAA-C03 / Decoupling with queues / Question 1
SAA-C03 practice question: Decoupling with queues (1 of 6)
Design Resilient Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
A concert ticketing company's web tier sends each order directly to a fleet of payment workers on Amazon EC2. When popular events go on sale, the workers are overwhelmed, requests time out, and orders are lost. Each order is independent of the others and takes up to 90 seconds to process. The company wants no orders to be lost during these spikes, and it wants the number of workers to grow and shrink with the number of orders that are waiting. Which solution meets these requirements with the LEAST operational overhead?
Choose one answer.
- AA. Write orders to an Amazon Kinesis data stream, have the workers read it with the Kinesis Client Library, and scale them on average CPU utilisation.
- BB. Send orders to an Amazon SQS standard queue with a visibility timeout longer than 90 seconds, and scale the workers on the queue backlog per instance.
- CC. Publish orders to an Amazon SNS topic with the workers' HTTPS endpoint subscribed, and scale the workers on average CPU utilisation.
- DD. Place an Application Load Balancer in front of the workers, and add a target tracking policy that keeps average CPU utilisation at 50%.
Show the answer and explanation
Answer: B
- A. Wrong: Kinesis keeps the orders, but each shard is read by only one worker at a time, so adding workers does not help unless the company also adds shards. The workers must also track checkpoints, and CPU utilisation does not show how many orders are waiting. Kinesis suits ordered streams read by several consumers, not a pool of independent jobs. Learn more: KCL concepts (opens in a new tab)
- B. Right: Correct. The queue holds each order durably until a worker deletes it, so sale spikes are buffered rather than dropped, and any free worker can take the next order. Scaling on backlog per instance adds workers when orders pile up and removes them when the queue drains. A visibility timeout longer than the processing time keeps an order hidden while it is being worked on. Learn more: Scaling policy based on Amazon SQS (opens in a new tab)
- C. Wrong: SNS pushes each message to the endpoint and retries only for a limited time. If the workers are still overwhelmed when the delivery policy runs out, SNS discards the message unless a dead-letter queue is attached. A pull-based queue lets workers take orders at their own pace. Learn more: Amazon SNS message delivery retries (opens in a new tab)
- D. Wrong: A load balancer spreads requests across workers but does not store requests that they cannot accept. New instances take minutes to launch, so orders arriving in a sudden spike still time out. A queue is needed to absorb the burst. Learn more: What is Amazon Simple Queue Service? (opens in a new tab)
Explanation
A queue decouples the web tier from the workers: bursts wait in SQS instead of being dropped, and each independent order can go to whichever worker is free. Scaling on backlog per instance (queue messages divided by running workers) matches the fleet to the orders waiting, which CPU utilisation does not. A Kinesis stream limits parallel readers to the number of shards, and push-based options (SNS over HTTPS, a load balancer) have nowhere to keep orders the workers cannot accept.
Study
Keep practising
Answer questions with a score at the end, or practise just this topic with the explanation after each one. No sign-up needed.