Decoupling with queues: SAA-C03 study notes and practice questions
What to know about Decoupling with queues for the SAA-C03 exam, from the Design Resilient Architectures domain (26% of the exam guide), then 6 free questions to test it. Part of the SAA-C03 study guide.
Decoupling questions describe components that fail together or drop work when one of them is slow. The fix is a buffer or a router between them, and the scenario’s details tell you which.
The services
Amazon SQS is a queue: producers send messages, consumers poll for them, and each message is processed by one consumer. Messages wait (up to 14 days) until a consumer is ready, so bursts don’t overwhelm the back end.
Amazon SNS is publish/subscribe: one message is pushed to every subscriber (SQS queues, Lambda functions, HTTPS endpoints, email, SMS).
Amazon EventBridge is an event bus: rules match events by their content and route them to targets. It is the native home for AWS service events and SaaS partner events, and it has a scheduler.
Exactly-once processing and strict order within each message group ID; different groups are processed in parallel
Visibility timeout
How long a received message stays hidden (default 30 seconds). Set it longer than processing time, or messages are processed twice
Dead-letter queue
After a maximum receive count, failed messages move aside for inspection instead of blocking or looping
Long polling
ReceiveMessageWaitTimeSeconds up to 20 seconds cuts empty responses and cost
Delay queues
Postpone delivery of new messages up to 15 minutes
Patterns
Fan-out: SNS topic with one SQS queue per consuming service. Each service gets its own copy and can be offline without losing messages.
Scale workers on the queue: an Auto Scaling group tracking backlog per instance (messages visible ÷ running instances), or Lambda with SQS as an event source.
Order per customer with parallelism: FIFO queue with the customer ID as the message group ID.
Common traps
Using SNS alone when a consumer can be offline. SNS doesn’t store messages for later; put a queue behind it.
Choosing a FIFO queue when order doesn’t matter and throughput does. Standard is simpler and scales further.
Fixing duplicate processing with code when the real cause is a visibility timeout shorter than the job.
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 utilization.
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 utilization.
DD. Place an Application Load Balancer in front of the workers, and add a target tracking policy that keeps average CPU utilization 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 utilization 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 utilization 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.
The queue absorbs the burst, and the backlog per instance tells Auto Scaling how many workers the waiting orders need.
An online retailer's order service must notify three other services, billing, shipping and analytics, each time an order is placed.
Each service must receive its own copy of every order and process it at its own pace. The analytics service is sometimes taken offline for maintenance for up to 2 days, and it must not miss any orders while it is down.
Which design meets these requirements?
Choose one answer.
AA. Publish each order to one Amazon SQS standard queue, and have the billing, shipping and analytics services all poll that queue.
BB. Publish each order to an Amazon SNS topic, and subscribe the HTTPS endpoint of each of the three services directly to the topic.
CC. Publish each order to an Amazon SNS topic, and subscribe a separate Amazon SQS queue for each service to the topic.
DD. Have the order service call the API of each of the three services directly, and retry each call until the service responds.
Show the answer and explanation
Answer: C
A. Wrong: SQS stores messages durably, but in a single queue each message is processed by whichever consumer receives and deletes it first. The three services would compete for orders instead of each getting a copy. A separate queue per service, fed by an SNS topic, gives each service its own copy. Learn more: Amazon SQS standard queues (opens in a new tab)
B. Wrong: SNS does send a copy to every subscriber, but it pushes messages and only retries an HTTP/S endpoint for a limited time (at most one hour under a custom delivery policy). After that the message is dropped unless a dead-letter queue is set, so a 2-day maintenance window would lose orders. Learn more: Amazon SNS message delivery retries (opens in a new tab)
C. Right: Correct. This is the SNS-to-SQS fan-out pattern: SNS puts a copy of every order into each subscribed queue, and each service works through its own queue at its own pace. SQS keeps messages for 4 days by default and up to 14 days, so the analytics queue simply builds up while the service is offline. Learn more: Fanout Amazon SNS notifications to Amazon SQS queues (opens in a new tab)
D. Wrong: Direct calls tightly couple the order service to the others. The order service would have to store and retry two days of orders for analytics itself, and a failure in the order service would lose those pending calls. A topic with a queue per service removes that burden. Learn more: Amazon SQS, Amazon SNS, or Amazon EventBridge? (opens in a new tab)
Explanation
Two needs decide this: every service gets its own copy (fan-out), and a consumer can be offline for days without losing messages (durable buffering). An SNS topic with one SQS queue per service provides both, because each queue holds messages for up to 14 days. A shared queue splits the orders, and HTTPS subscriptions are only retried for a limited time.
Each service reads its own queue, so billing, shipping and analytics each get every order and can be offline for days.
A bank's payments platform sends account transactions to a queue for processing by a fleet of workers.
Transactions for the same account must be applied in the order they were sent, but transactions for different accounts should be processed in parallel so that the fleet can scale out. When a send times out, the producer retries it within a few seconds, and a retried transaction must not be applied twice.
Which solution meets these requirements with the LEAST custom code?
Choose one answer.
AA. Use an Amazon SQS FIFO queue, set the message group ID to the account ID, and set the deduplication ID to the transaction ID.
BB. Use an Amazon SQS FIFO queue with one message group ID for all messages, and turn on content-based deduplication for the queue.
CC. Use an Amazon Kinesis data stream with the account ID as the partition key, and run one consumer for the records of each shard.
DD. Use an Amazon SQS standard queue, and record each processed transaction ID in a DynamoDB table so workers skip duplicates.
Show the answer and explanation
Answer: A
A. Right: Correct. A FIFO queue keeps strict order within each message group, and different groups can be processed by different workers at the same time, so each account stays in order while the fleet scales. A send with the same deduplication ID within the 5-minute deduplication interval is not added to the queue again, which covers the producer's quick retries. Learn more: FIFO queue delivery logic in Amazon SQS (opens in a new tab)
B. Wrong: Content-based deduplication would remove retried sends, and order would be kept. However, with a single message group every message is part of one ordered sequence, so only one transaction can be in flight at a time and the fleet cannot process accounts in parallel. Using the account ID as the group ID fixes this. Learn more: Exactly-once processing in Amazon SQS (opens in a new tab)
C. Wrong: Records with the same partition key go to the same shard, so per-account order is kept and shards give parallelism. However, a producer retry after a timeout can write the same transaction twice as two records with different sequence numbers. The consumers would need their own deduplication code, which a FIFO queue's deduplication ID avoids. Learn more: Handle duplicate records in Kinesis Data Streams (opens in a new tab)
D. Wrong: The DynamoDB table would catch duplicates, but it is custom code. More importantly, a standard queue only makes a best-effort attempt to keep order, so transactions for one account could be applied out of sequence. A FIFO queue with per-account message groups guarantees the order. Learn more: Amazon SQS standard queues (opens in a new tab)
Explanation
Three requirements interact: order per account, parallelism across accounts, and no duplicates from producer retries. An SQS FIFO queue with the account ID as the message group ID gives order within each account and parallel processing across accounts, and a deduplication ID drops retries sent within 5 minutes. A single group removes parallelism, Kinesis needs consumer-side deduplication, and a standard queue does not guarantee order.
A media company uses Amazon EC2 workers to transcode video clips from an Amazon SQS standard queue.
Each clip takes between 2 and 4 minutes to process, after which the worker deletes the message. The queue still uses its default settings.
The operations team notices that many clips are transcoded two or three times, which wastes compute, even though no worker has crashed.
Which change will MOST effectively stop the repeated processing?
Choose one answer.
AA. Turn on long polling by setting the queue's receive message wait time to 20 seconds, so workers make fewer empty receive calls.
BB. Set a delivery delay of 5 minutes on the queue, so that each new message stays hidden for longer before workers can receive it.
CC. Add a dead-letter queue with a maximum receive count of 1, so that any message received a second time is moved aside.
DD. Raise the queue's visibility timeout to about 6 minutes, so that a message stays hidden until its clip is finished.
Show the answer and explanation
Answer: D
A. Wrong: Long polling reduces empty responses and the cost of polling an empty queue. It does not change how long a received message stays hidden, so clips would still reappear after 30 seconds and be picked up again. Learn more: Amazon SQS short and long polling (opens in a new tab)
B. Wrong: A delivery delay only hides a message when it is first added to the queue. Once a worker receives it, the 30-second visibility timeout applies as before, so the message still reappears while the clip is being processed. Learn more: Amazon SQS delay queues (opens in a new tab)
C. Wrong: This would stop the second transcode, but only by moving clips that are still being worked on into the dead-letter queue once the visibility timeout expires. Those clips would then need manual handling. It hides the symptom instead of fixing the timeout. Learn more: Using dead-letter queues in Amazon SQS (opens in a new tab)
D. Right: Correct. The default visibility timeout is 30 seconds, so a message becomes visible again long before a 2-to-4-minute job finishes, and another worker picks it up. Setting the timeout above the longest processing time keeps the message hidden until the worker deletes it. Learn more: Amazon SQS visibility timeout (opens in a new tab)
Explanation
When a worker receives an SQS message, it is hidden only for the visibility timeout, which defaults to 30 seconds. Because each clip takes 2 to 4 minutes, messages reappear and are processed again. Setting the timeout longer than the maximum processing time (or extending it per message with ChangeMessageVisibility) stops the duplicates. Long polling and delivery delays do not affect in-flight messages.
An order-processing application reads messages from an Amazon SQS standard queue.
A few malformed messages fail every time a worker tries to process them, so they keep returning to the queue and use up worker time that valid messages need. The team wants these failing messages moved aside automatically after a few attempts, and kept so that a developer can inspect them and replay them later.
What should a solutions architect do?
Choose one answer.
AA. Lower the queue's message retention period to 1 hour, so that messages that keep failing expire and are removed from the queue.
BB. Create another SQS queue as a dead-letter queue, and give the source queue a redrive policy with a maximum receive count of 5.
CC. Change the workers to delete any message that fails processing, and write the message body to Amazon CloudWatch Logs for review.
DD. Increase the queue's visibility timeout to 12 hours, so that failing messages are retried less often and valid messages go first.
B. Right: Correct. After a message has been received the set number of times without being deleted, SQS moves it to the dead-letter queue. The message is kept there for developers to inspect, and it can be redriven back to the source queue once the bug is fixed. Learn more: Using dead-letter queues in Amazon SQS (opens in a new tab)
C. Wrong: This removes the failing messages from the queue, but it needs code changes and deletes a message after a single failure, including one that failed for a passing reason. Replaying from log entries is also manual. A dead-letter queue does this without code.
D. Wrong: A long visibility timeout hides a failed message for longer, but it keeps coming back forever and is never set aside. It also delays the retry of valid messages that failed for a temporary reason. A dead-letter queue is built for this. Learn more: Amazon SQS visibility timeout (opens in a new tab)
Explanation
A dead-letter queue isolates messages that cannot be processed. The source queue's redrive policy sets a maximum receive count; once a message exceeds it, SQS moves the message to the dead-letter queue, where it can be inspected and later redriven. The other options either lose the messages or keep retrying them.
An Amazon EventBridge rule invokes an AWS Lambda function asynchronously for each new insurance claim.
Occasionally the function fails on every attempt and the claim event is lost. The team must keep every failed event for investigation and replay. Investigators need the original event together with the full error the function returned, which often includes a stack trace of 3 to 5 KB.
The team does not want to change the function code.
What should a solutions architect do?
Choose one answer.
AA. Configure an Amazon SQS standard queue as the function's dead-letter queue, and read the failed events and error attributes from it.
BB. Configure an Amazon SQS standard queue as an on-failure destination for the function's asynchronous invocations.
CC. Set the function's maximum retry attempts to 2 and its maximum event age to 6 hours, so Lambda retries failed events for longer.
DD. Wrap the handler in a try/catch block that writes the event and stack trace to Amazon CloudWatch Logs before re-raising the error.
Show the answer and explanation
Answer: B
A. Wrong: A Lambda dead-letter queue does keep failed events, so nothing is lost. However, Lambda sends only the event itself, with the error message as an attribute truncated to the first 1 KB, so a 3-to-5 KB stack trace would be cut off. An on-failure destination includes the full response. Learn more: Capturing records of Lambda asynchronous invocations (opens in a new tab)
B. Right: Correct. When an asynchronous invocation fails all its attempts, Lambda sends an invocation record to the destination. The record contains the original event as the request payload and the function's error response, so investigators get both and can replay the event from the queue. Learn more: Capturing records of Lambda asynchronous invocations (opens in a new tab)
D. Wrong: This changes the function code, which the team wants to avoid. It also misses failures that the handler cannot catch, such as timeouts, and replaying events from log lines is a manual job.
Explanation
Lambda discards an asynchronous event once retries are exhausted unless a dead-letter queue or an on-failure destination is configured. Both keep the event, but only the destination's invocation record includes the full function response; a dead-letter queue keeps just the event and the first 1 KB of the error message. An SQS on-failure destination therefore meets the replay and full-error needs with no code changes.
EventBridge invokes the function asynchronously, so a failed event goes to the on-failure destination with the function's response.
Want more on Decoupling with queues? The 5 full-length practice sets have 15 more Decoupling with queues questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →