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 how to reliably capture Lambda invocation records without impacting your business logic or performance.
In production, this is about knowing exactly which Lambda asynchronous invocation features support granular success and failure tracking via destinations, without requiring manual SDK calls or inefficient polling. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A fintech startup named Payplet Inc. has developed an AWS Lambda function that processes transaction notifications triggered by an Amazon SNS topic. The engineering team needs to implement a mechanism to log every Lambda function invocation into an Amazon SQS queue for auditing purposes. This log should cover every invocation regardless of success or failure without modifying the business logic inside the Lambda function.
The Requirement: #
Design a solution to ensure each Lambda invocation—successful or failed—is recorded as a message in an SQS queue in a decoupled and reliable manner.
The Options #
- A) Configure the SQS queue as a dead-letter queue (DLQ) for the Lambda function.
- B) Modify the Lambda function’s code to invoke the AWS SDK
SendMessageAPI to send invocation details to the SQS queue at the end of the handler. - C) Add two asynchronous invocation destinations to the Lambda function: one for successful invocations and one for failed invocations. Configure the SQS queue as the destination for both outcomes. Create an Amazon CloudWatch alarm on the
DestinationDeliveryFailuresmetric to monitor delivery problems. - D) Add a single asynchronous invocation destination to the Lambda function for capturing only successful invocations, configuring the SQS queue as the destination. Create a CloudWatch alarm on
DestinationDeliveryFailuresfor delivery exceptions.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
The key to robust invocation tracking is leveraging Lambda’s asynchronous invocation destinations for success and failure separately. This avoids cluttering business logic with SDK calls and guarantees message delivery asynchronously. CloudWatch alarms on delivery failures enable proactive monitoring of invocation log reliability.
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 C
The Winning Logic #
Option C perfectly leverages AWS Lambda’s native asynchronous invocation destination feature, which was designed to send invocation records post-invocation, separating success and failure paths. Both success and failure outcomes are routed to the SQS queue, ensuring every invocation message is captured reliably.
- This approach completely decouples invocation logging from the Lambda function’s core business logic, adhering to clean code and separation of concerns principles.
- AWS internally retries sending messages to the destinations and exposes CloudWatch metrics (
DestinationDeliveryFailures) for monitoring undelivered messages, enabling operational visibility and alerting. - Using asynchronous invocation destinations scales better and reduces error surface compared to manual SDK calls inside Lambda handlers.
The Trap (Distractor Analysis) #
- Why not A? Configuring SQS as a DLQ only captures failed asynchronous invocations that exhaust retries. It misses successful invocations entirely and does not log every invocation. This violates the requirement.
- Why not B? While feasible, embedding SDK calls within the Lambda increases complexity, coupling logging to business code, potentially impacting performance and error handling. It also complicates error recovery if sending to SQS fails.
- Why not D? Capturing only successful invocations misses failures, leading to an incomplete audit trail. This partial logging does not meet the requirement for capturing all invocations regardless of outcome.
The Technical Blueprint #
Relevant AWS CLI snippet to set asynchronous destinations for Lambda (success and failure): #
aws lambda put-function-event-invoke-config \
--function-name MyLambdaFunction \
--destination-config '{"OnSuccess":{"Destination":"arn:aws:sqs:region:account-id:queue-name"},"OnFailure":{"Destination":"arn:aws:sqs:region:account-id:queue-name"}}'
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case |
|---|---|---|---|
| A | Low | Low | Works only on failed async invocations; partial logging |
| B | High (manual SDK calls) | Medium (adds execution overhead) | Coupled logging; error prone if SDK call fails |
| C | Medium (configuration required) | Low (asynchronous) | Best practice; decoupled, full coverage, scalable |
| D | Medium (configuration) | Low (asynchronous) | Partial logging; misses failures |
Real-World Application (Practitioner Insight) #
Exam Rule #
When you need reliable logging of all Lambda asynchronous invocations, use asynchronous invocation destinations instead of manual SDK logging or DLQs for completeness.
Real World #
In production, manual SDK calls inside Lambda are often avoided to reduce code complexity and failure blast radius. DLQs are great for retries but not for full invocation auditing. Lambda Destinations save development time and add robust retry/delivery metrics out-of-the-box.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.