Question 64 of 302
Using SQS Queues with Dead Letter Queues for At-Least-Once Processing and Retries
Your order-processing system uses EventBridge rules to send events to a Lambda function that updates order status. Over the last week, some events fail with a transient database timeout, and the Lambda retries intermittently but then the events are lost (no alerts after failures). You want at-least-once processing, bounded retries, and a way to inspect unprocessable events for later reprocessing.
Which architecture change best meets these requirements?
Quick Answer
The design works by inserting a durable buffer, SQS, between the event source and the Lambda function, which changes the failure story completely: instead of a failed Lambda invocation simply losing the event when retries run out, the event sits safely in the queue and is redelivered according to the queue's own retry behavior. The redrive policy adds the missing piece of control by capping how many times a message can be retried before it's automatically moved to a dead-letter queue, which is what turns unbounded, silent retries into bounded ones with a visible landing place for anything that still can't be processed, solving both the events-getting-lost problem and the lack of alerting, since the DLQ becomes something that can be monitored and inspected. Making the Lambda function idempotent is what makes at-least-once delivery safe to rely on, since SQS and the retry mechanism can redeliver a message more than once, and idempotency ensures processing it twice doesn't corrupt order status. Each piece answers a distinct requirement: SQS provides durability, the redrive policy bounds retries and preserves failures, and idempotency makes repeated delivery harmless. When a scenario asks for reliable, inspectable processing with bounded retries after events start disappearing on failure, that combination of a queue, a redrive policy to a DLQ, and idempotent handling is the pattern to reach for.
⚠ Common exam trap
It's easy for candidates to think increasing Lambda timeout or relying on asynchronous invocation retries alone is sufficient, but they overlook the need for a DLQ to capture and inspect events that persistently fail, which is a key requirement for operational visibility and reprocessing.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Send EventBridge events to an SQS queue, configure a redrive policy to move messages to a dead-letter queue (DLQ) after a defined receive count, and make the Lambda processing idempotent.
It introduces an SQS queue between EventBridge and Lambda, which provides a durable buffer for events. The redrive policy moves events to a dead-letter queue (DLQ) after a defined number of failed processing attempts, ensuring bounded retries and preserving unprocessable events for later inspection and reprocessing. Making the Lambda idempotent guarantees at-least-once processing even if duplicate events occur.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Send EventBridge events to an SQS queue, configure a redrive policy to move messages to a dead-letter queue (DLQ) after a defined receive count, and make the Lambda processing idempotent.
Why this is correct
EventBridge-to-SQS provides buffering and decoupling; SQS redrive with a DLQ bounds retries and preserves failed events for analysis and replay.
- ✗
Invoke Lambda directly from EventBridge in asynchronous mode, and increase the Lambda timeout to reduce failures.
Why it's wrong here
Direct asynchronous invocation lacks a DLQ-style retention mechanism for failed events and retries can be unpredictable.
When this WOULD be correct
This option would be correct if the question required minimal cost and complexity for a non-critical system where occasional event loss is acceptable, and there was no need for DLQ or reprocessing.
- ✗
Use SNS topics with Lambda subscriptions, but remove all retry and DLQ configuration to minimize duplicate events.
Why it's wrong here
Removing retries and DLQ leads to message loss and provides no systematic way to capture unprocessable events.
When this WOULD be correct
In a scenario where the requirement is exactly-once processing with no duplicates and no need for retries or inspection of failed events, and the system can tolerate event loss on failure.
- ✗
Store failed events only in CloudWatch logs, and have operators manually copy log entries back into the database for reprocessing.
Why it's wrong here
Logs are not a reliable data store for event replay and operationally burdens incident response while risking inconsistencies.
When this WOULD be correct
This option would be correct in a scenario where the requirement is to have a simple, low-cost solution for debugging and manual intervention, with no need for automated retries or DLQ, and where the volume of failures is very low and acceptable to handle manually.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Send EventBridge events to an SQS queue, configure a redrive policy to move messages to a dead-letter queue (DLQ) after a defined receive count, and make the Lambda processing idempotent.Correct answer▾
Why this is correct
EventBridge-to-SQS provides buffering and decoupling; SQS redrive with a DLQ bounds retries and preserves failed events for analysis and replay.
✗Invoke Lambda directly from EventBridge in asynchronous mode, and increase the Lambda timeout to reduce failures.Wrong answer — click to see why▾
Why this is wrong here
Asynchronous Lambda invocation from EventBridge has limited retry (0-2 attempts) and no DLQ support, so events lost after transient failures cannot be inspected or reprocessed, failing the requirement for bounded retries and inspectability.
★ When this WOULD be the correct answer
This option would be correct if the question required minimal cost and complexity for a non-critical system where occasional event loss is acceptable, and there was no need for DLQ or reprocessing.
Why candidates choose this
Candidates may think asynchronous invocation automatically handles retries and durability, overlooking that EventBridge async targets have no DLQ and limited retry, and that increasing timeout doesn't prevent loss from other transient failures.
✗Use SNS topics with Lambda subscriptions, but remove all retry and DLQ configuration to minimize duplicate events.Wrong answer — click to see why▾
Why this is wrong here
Removing retry and DLQ configuration prevents at-least-once processing and makes it impossible to inspect unprocessable events, directly contradicting the requirements.
★ When this WOULD be the correct answer
In a scenario where the requirement is exactly-once processing with no duplicates and no need for retries or inspection of failed events, and the system can tolerate event loss on failure.
Why candidates choose this
Candidates may think SNS with Lambda is simpler and that removing retries reduces duplicates, but they overlook the need for reliability and failure inspection.
✗Store failed events only in CloudWatch logs, and have operators manually copy log entries back into the database for reprocessing.Wrong answer — click to see why▾
Why this is wrong here
Storing failed events only in CloudWatch logs and manually reprocessing them does not provide automated retries, bounded retries, or a systematic way to inspect and reprocess unprocessable events, violating the requirements for at-least-once processing and automated reprocessing.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the requirement is to have a simple, low-cost solution for debugging and manual intervention, with no need for automated retries or DLQ, and where the volume of failures is very low and acceptable to handle manually.
Why candidates choose this
Candidates may think that logging failures is sufficient for auditing and that manual reprocessing is acceptable, underestimating the need for automated retry and DLQ mechanisms to ensure reliability and reduce operational overhead.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your order-processing system uses EventBridge rules to send events to a Lambda function that updates order status. Over the last week, some events fail with a transient database timeout, and the Lambda retries intermittently but then the events are lost (no alerts after failures). You want at-least-once processing, bounded retries, and a way to inspect unprocessable events for later reprocessing. Which architecture change best meets these requirements?
medium- ✓ A.Send EventBridge events to an SQS queue, configure a redrive policy to move messages to a dead-letter queue (DLQ) after a defined receive count, and make the Lambda processing idempotent.
- B.Invoke Lambda directly from EventBridge in asynchronous mode, and increase the Lambda timeout to reduce failures.
- C.Use SNS topics with Lambda subscriptions, but remove all retry and DLQ configuration to minimize duplicate events.
- D.Store failed events only in CloudWatch logs, and have operators manually copy log entries back into the database for reprocessing.
Why A: It introduces an SQS queue between EventBridge and Lambda, which provides at-least-once processing through message visibility timeouts and retries. The redrive policy moves messages to a dead-letter queue (DLQ) after a defined receive count, ensuring bounded retries and preserving unprocessable events for later inspection and reprocessing. Making the Lambda idempotent prevents duplicate side effects from at-least-once delivery.
Variation 2. An order system receives events and uses a Lambda function to write each order into a database. During traffic spikes, the database sometimes throttles, and Lambda retries lead to occasional message loss in the event flow. The team wants buffering, automatic retries, and a way to isolate messages that repeatedly fail so they can be inspected later. What design change best meets this need?
easy- A.Send events directly from EventBridge to Lambda without any queue to simplify the flow.
- ✓ B.Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).
- C.Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.
- D.Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.
Why B: B is correct because Amazon SQS acts as a durable buffer between the event source and Lambda, absorbing traffic spikes and providing automatic retries via its visibility timeout mechanism. By attaching a dead-letter queue (DLQ) to the SQS queue, messages that repeatedly fail processing can be isolated for later inspection, preventing data loss and enabling debugging.
Variation 3. An order system receives events and uses a Lambda function to write each order into a database. During traffic spikes, the database sometimes throttles, and Lambda retries lead to occasional message loss in the event flow. The team wants buffering, automatic retries, and a way to isolate messages that repeatedly fail so they can be inspected later. What design change best meets this need?
easy- A.Send events directly from EventBridge to Lambda without any queue to simplify the flow.
- ✓ B.Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).
- C.Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.
- D.Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.
Why B: Amazon SQS acts as a durable buffer between the event source and Lambda, absorbing traffic spikes and decoupling the producer from the consumer. The SQS dead-letter queue (DLQ) automatically captures messages that exceed the configured maximum retries, allowing the team to inspect and reprocess them later without loss. This design provides the required buffering, automatic retries via the Lambda event source mapping, and isolation of repeatedly failing messages.
Last reviewed: Jun 11, 2026
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.