An AWS Lambda function is invoked asynchronously to process events. Occasionally, the Lambda function falls to process events. A developer needs to collect and analyze these failed events to fix the…

Question

Options

• AAdd logging statements for all events in the Lambda function. Filter AWS CloudTrail logs for
• BConfigure the Lambda function to start an AWS Step Functions workflow with retries for failed
• CAdd a dead-letter queue to send messages to an Amazon Simple Queue Service (Amazon SQS)
• DAdd a dead-letter queue to send messages to an Amazon Simple Notification Service (Amazon

• A
  5% (1)
• B
  5% (1)
• C
  74% (14)
• D
  16% (3)

Explanation

Configuring a dead-letter queue (DLQ) backed by Amazon SQS is the built-in AWS mechanism for capturing failed asynchronous Lambda invocations - it requires only a configuration change in the Lambda console, zero code changes, and the failed event payloads land in SQS where they can be inspected, replayed, or analyzed.

Why the distractors fail:

• A (CloudTrail): CloudTrail logs API calls, not event payloads - you'd see that Lambda was invoked but not the data that caused the failure, and filtering logs is manual, high-effort work.
• B (Step Functions): Adds retry orchestration but requires building a workflow, which is significant development effort - far from the "least effort" requirement.
• D (SNS): SNS can also be a DLQ target, but SNS is a push (fan-out) service - messages are delivered to subscribers and then discarded. SQS queues messages durably, making them easy to retrieve and analyze at your own pace, which is the better fit for failure analysis.

Memory tip: Think "Dead letters go to a mailbox (SQS queue) so you can read them later - not to a megaphone (SNS) that shouts them once and forgets."

No community discussion yet for this question.