Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in knowing how to properly configure asynchronous failure destinations for Lambda. In production, this is about knowing exactly how Lambda routes invocation errors asynchronously and how SNS topics fit into the DLQ or failure destination model. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
The development team at a fast-growing fintech startup, Finnovate Labs, created a Lambda function called ProcessTransactions. This Lambda is invoked asynchronously whenever a new event is published to an Amazon SNS topic named TransactionInputTopic. Finnovate Labs also maintains a separate SNS topic named AlertTopic intended to receive failure notifications related to various backend services.
The team wants to ensure that whenever the ProcessTransactions Lambda function fails to process an event, a notification is sent to the AlertTopic SNS topic for the DevOps team to investigate.
The Requirement: #
Determine the best approach to configure Lambda and SNS to guarantee the DevOps team receives notifications on the AlertTopic SNS topic whenever ProcessTransactions fails during asynchronous invocation.
The Options #
- A) Configure a subscription on the
AlertTopicSNS topic that filters events to only failures. Set theProcessTransactionsLambda function as the endpoint for this subscription. - B) Configure an asynchronous failure destination on the
ProcessTransactionsLambda function. Specify the Amazon Resource Name (ARN) of theAlertTopicSNS topic as the destination ARN. - C) Configure a trigger for the
ProcessTransactionsLambda function with theAlertTopicSNS topic as the source, filtering only failure messages. - D) Configure a delivery policy on the
AlertTopicSNS topic including a filter policy for failure events. Specify the Lambda function as the input endpoint.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
When configuring Lambda for asynchronous invocation, failures are not retried by the caller. Instead, you must explicitly configure a failure destination (such as SNS, SQS, or EventBridge). Option B leverages the Lambda feature to send failure events directly to an SNS topic, ensuring reliable notification without manually managing subscriptions or triggers.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
AWS Lambda supports configuring asynchronous invocation destinations for success and failure events. When a Lambda is invoked asynchronously (such as by SNS), failures do not immediately propagate back to the publisher. Instead, you define a failure destination so that Lambda automatically sends failure records to that destination.
In this case, the AlertTopic SNS topic must receive notifications of ProcessTransactions function failures. Option B correctly sets the SNS topic ARN as the asynchronous failure destination on the Lambda function itself. When the Lambda invocation fails, Lambda will publish the failure event (including payload and error info) directly to this SNS topic.
This is the recommended and cleanest approach supported by Lambda’s asynchronous invocation model because:
- It is natively supported by Lambda, requiring no complicated subscriptions or triggers.
- It does not confuse the flow by trying to reverse triggers or filter policies incorrectly on SNS.
- It reliably delivers failure events even when retries exhaust.
The Trap (Distractor Analysis): #
-
Why not A?
Setting the Lambda function itself as an endpoint for theAlertTopicSNS subscription is backwards.AlertTopicis supposed to send notifications, not invoke the Lambda. Also, you cannot configure SNS subscription filter policies for Lambda invocation failures this way; SNS subscriptions do not have visibility into Lambda invocation success/failure. -
Why not C?
Configuring theAlertTopicSNS as a trigger for the Lambda function reverses the logical flow. You want alerts when Lambda fails, not to trigger Lambda from the alert topic. Also, filter policies on topic triggers cannot filter for Lambda invocation failures. -
Why not D?
Delivery policies and filter policies control message delivery behavior and filtering for subscribers but do not trigger messages on Lambda failure events. Without configuring Lambda’s async failure destination, theAlertTopicSNS topic does not automatically receive failure notifications.
The Technical Blueprint #
# Configure Lambda async failure destination to an SNS topic
aws lambda update-function-event-invoke-config \
--function-name ProcessTransactions \
--destination-config '{"OnFailure":{"Destination":"arn:aws:sns:us-east-1:123456789012:AlertTopic"}}'
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Medium (SNS sub setup) | Ineffective for failures | Misuses SNS subscription for failure callbacks |
| B | Low (Lambda config) | Direct, automatic | Correct async failure notification via Lambda destinations |
| C | Medium (SNS trigger) | Invalid workflow | Triggers Lambda, not for failure alerts |
| D | Low (policy config) | Does not trigger failures | Delivery policy governs message delivery, not failure events |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick Lambda async failure destination when you see asynchronously invoked Lambda failure notification.”
Real World #
“In production, teams frequently integrate failure destinations with SNS, SQS, or EventBridge to build robust, decoupled failure handling pipelines allowing automated alerting and remediation.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.