Enable failed batch item reporting on the Lambda function and add an SQS dead-letter queue
A company releases a new application in a new AWS account. The application includes an AWS Lambda function that processes messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function stores the results in an Amazon S3 bucket for further downstream processing. The Lambda function needs to process the messages within a specific period of time after the messages are published. The Lambda function has a batch size of 10 messages and takes a few seconds to process a batch of messages. As load increases on the application's first day of service, messages in the queue accumulate at a greater rate than the Lambda function can process the messages. Some messages miss the required processing timelines. The logs show that many messages in the queue have data that is not valid. The company needs to meet the timeline requirements for messages that have valid data. Which solution will meet these requirements?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The root cause is the batch failure pattern, not insufficient capacity: with ReportBatchItemFailures enabled, Lambda returns only the messages that actually failed instead of the whole batch, so valid messages are not reprocessed or blocked (D). A dead-letter queue then isolates the permanently invalid messages after the retry limit. Increasing the batch size (A, C) would worsen the problem because a single bad message would fail more messages per batch, and switching to a FIFO queue (A) would reduce throughput and add deduplication overhead rather than solve the failure pattern.
Because one invalid message causes an entire batch of ten to fail and return to the queue, the invalid messages are repeatedly retried and block valid messages in the same batch, which is the classic snowball effect. Keeping the batch size unchanged, configuring the Lambda function to report failed batch items so only the unprocessed messages are returned to the queue, and adding a dead-letter queue moves the poison messages aside after the retry limit so that valid messages continue to be processed within their required timeline.
Increasing the batch size (A and C)—hk0308 correctly notes that the data shows valid and invalid messages are mixed in the same batch, so a larger batch means one bad message fails and re-delivers more good messages, making the backlog worse. Switching from a standard queue to a FIFO queue (A)—VerRi explained the snowball anti-pattern: one failure in a batch fails the whole batch, blocking other tasks; FIFO also adds deduplication and ordering overhead that reduces throughput rather than meeting the timeline.
Community Discussion (8 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The logs show the queue contains messages with invalid data, and the function processes them in batches of ten. By default, when a batch fails the entire batch is returned to the queue, so a single malformed message repeatedly fails the nine valid messages batched with it, and the queue grows faster than it drains. Enabling ReportBatchItemFailures on the Lambda function makes the invocation return only the messages that actually failed, so valid messages in the same batch are processed normally and stay within their timeline. Configuring a dead-letter queue then moves messages that keep failing past the retry limit out of the queue so they stop consuming processing capacity. Together these address the failure pattern directly while leaving the batch size unchanged.Why the Other Options Are Wrong
A increases the batch size and switches the queue to FIFO. FIFO adds deduplication and ordering overhead that reduces throughput, and the problem is not ordering; a larger batch also means a single invalid message fails and re-delivers more valid messages, worsening the backlog. B reduces the batch size and requests throughput and concurrency increases, which treats the symptom as a capacity problem even though the evidence shows invalid data is the cause, so the added capacity is consumed by repeatedly retrying poison messages. C increases the batch size and adds S3 Transfer Acceleration, which is unrelated to SQS processing, and adds a dead-letter queue but leaves the whole-batch failure behavior in place. D is correct.Community Comment Notes
Community voted D (93). c3518fc linked the AWS guidance on avoiding the snowball anti-pattern in serverless architectures, which prescribes partial batch failure responses plus a dead-letter queue. hk0308 and VerRi both argued against the batch-size-increasing options because mixing valid and invalid messages in a batch means a larger batch fails more good messages.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →