How to Capture Failed AWS Lambda Async Events?

AWS Lambda, Dead-Letter Queues

A developer is building an application that invokes AWS Lambda functions asynchronously to process events. The developer notices that a Lambda function fails to process some events at random times. The developer needs to investigate the failed events and capture the events that the Lambda function fails to process. Which solution will meet these requirements?

Add an Amazon EventBridge rule for the Lambda function. Configure the EventBridge rule to react to failed events and to store the events in an Amazon DynamoDB table.
Configure the Lambda function with a dead-letter queue based in Amazon Kinesis. Update the Lambda function's execution role with the required permissions.
Configure the Lambda function with an Amazon Simple Queue Service (Amazon SQS) dead-letter queue. Update the Lambda function's execution role with the required permissions. Source Reference Answer
Configure the Lambda function with an Amazon Simple Queue Service (Amazon SQS) FIFO dead-letter queue. Update the Lambda function's execution role with the required permissions.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests knowledge of AWS Lambda's DLQ configurations; the trap is distinguishing SQS DLQ (correct) from Kinesis (not a DLQ) or FIFO SQS (unnecessary overkill).

For capturing events that an AWS Lambda function fails to process asynchronously, the community confirms that configuring an Amazon SQS dead-letter queue is the correct solution, as it captures failed events for investigation and debugging.

Choosing an SQS FIFO dead-letter queue (D) because it maintains ordering, but the requirement doesn't need FIFO, and standard SQS DLQ is sufficient and simpler.

Community Discussion (5 comments)

tgv 👍 10

The standard SQS dead-letter queue should capture the failed events and let the developer debug them, so C is the right solution. B - There's no such thing as a DLQ in Kinesis. D - SQS FIFO DLQ would be too much overkill for this task because you don't need ordering or deduplication. A - This would involve additional costs and too much complexity to use a DynamoDB table for this.

65703c1 👍 1 Selected: C

C is the correct answer.

KarBiswa 👍 3 Selected: C

https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html#:~:text=You%20can%20configure%20a%20dead%2Dletter%20queue%20on%20the%20function%20to%20capture%20events%20that%20weren%27t%20successfully%20processed.

Abdullah22 👍 3 Selected: C

gpoing with C

CrescentShared 👍 3 Selected: C

Using an SQS queue for a DLQ is simpler than using Amazon Kinesis. Kinesis is a more complex service designed for real-time data streaming, which might be overkill for simply capturing failed Lambda events.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Lambda asynchronous invocations can be configured with a dead-letter queue (DLQ) to capture events that fail processing. Amazon SQS is the standard, recommended service for this purpose, providing a durable and simple way to retain failed events for later investigation. Standard SQS queues are sufficient for this use case, as no ordering or deduplication is required.

Why the Other Options Are Wrong

Option A is overly complex and costly; EventBridge plus DynamoDB is not a native DLQ mechanism for Lambda and adds unnecessary moving parts. Option B is incorrect because Amazon Kinesis does not serve as a dead-letter queue for Lambda, and there is no such DLQ concept in Kinesis. Option D, SQS FIFO DLQ, is overkill since the requirement does not mention ordering or deduplication, and standard SQS DLQ meets the need more efficiently.

Community Comment Notes

Comment 1 correctly points out that there is no Kinesis DLQ and that FIFO would be overkill, directly supporting C. Comment 2 provides an official AWS documentation link confirming that you can configure a dead-letter queue on the function to capture unsuccessful events. Comment 3 reinforces that Kinesis is a more complex streaming service and simpler SQS DLQ is preferable. All community responses unanimously agree on C.

Official Reference

Exam Strategy

When you see 'capture failed events' for Lambda async invocations, think 'dead-letter queue' and remember that Lambda supports SQS and SNS as DLQ destinations. Eliminate Kinesis immediately, and only choose FIFO SQS if the question explicitly requires message ordering or deduplication.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide