How to store failed Lambda asynchronous invocations with least overhead?

Why the Answer Is Correct

Option C is correct because AWS Lambda natively supports configuring a dead-letter queue (DLQ) for asynchronous invocations. When Lambda exhausts retries, the failed event is sent to the specified SQS queue or SNS topic. This is a built-in feature, so there is no need to build custom filtering or routing logic, keeping operational overhead low.

Using the DLQ as an event source for the Lambda function makes it easy to retry the failed messages later. The SQS queue holds the discarded events, and when it is configured as an event source, Lambda can process those messages again automatically. This matches the goal of storing failed messages and retrying them with minimal manual intervention.

Community comments reinforce this point. One comment notes that async Lambda invocations allow a DLQ to be created from the Lambda function, while sync invocations require the DLQ to be created by SQS. Another comment provides the official AWS documentation link, confirming that the DLQ is the standard solution for this scenario.

Why the Other Options Are Wrong

Option A is wrong because setting up CloudWatch Logs log groups, filtering, and then importing messages into Lambda is not a native dead-letter mechanism. It requires custom code and extra moving parts, which increases operational overhead significantly.

Option B is wrong because EventBridge sending messages to SNS to initiate Lambda again does not provide a durable dead-letter store with native retry semantics. SNS is a push notification service, not a queue designed for holding failed events for later replay.

Option D is wrong because while SQS can store failed messages and trigger Lambda, it is not the least operational overhead approach for asynchronous Lambda invocations. Lambda already offers a built-in DLQ feature that sends failed events directly to SQS or SNS without requiring the developer to design a separate EventBridge/SQS integration.

Community Comment Notes

Community members overwhelmingly voted for C, with 100% of the votes agreeing. A high-liked comment clarifies the key difference: for async invocations, Lambda can create the DLQ; for sync invocations, SQS must create it. This distinction is a common exam point.

Another comment includes the official AWS documentation link for Lambda async invocation DLQs, reinforcing that the feature is designed exactly for this use case. The comments do not suggest any hidden trap or alternative answer, so C is confident.