How to Log Every Lambda Invocation to an SQS Queue?
Short answer
B Create code that uses the AWS SDK to call the SQS SendMessage operation to add the invocation details to the SQS queue. Add the code to the end of the Lambda function.
Question
Key Takeaways
The question requires logging each invocation, meaning success, final failure, and retryable failures must be recorded; Lambda asynchronous destinations only fire on terminal states (success or final failure), so in-code SDK calls are the only way to capture every single invocation attempt.
This question tests the ability to record every AWS Lambda invocation (success, failure, and retryable failure) into an Amazon SQS queue. Community consensus leans toward using the AWS SDK within the function code because Lambda destinations alone cannot capture retryable failures as distinct records.
Common mistake: Many candidates choose option C or D (Lambda destinations) because destinations are the AWS-native, serverless way to route invocation results to SQS. However, destinations do **not** fire on retryable failures, so they miss invocation attempts, violating the 'each invocation' requirement.
Expert Analysis
Understanding the Requirement
The key phrase in the question is 'add a record of each Lambda function invocation'. This means every single invocation attempt — whether it succeeds, fails terminally, or is in a retryable failure state — must produce a record in the SQS queue.
Why Option B is Correct
Option B instructs the developer to add code inside the Lambda function that uses the AWS SDK to call the SQS SendMessage API at the end of the function logic. Because this code runs on every execution of the Lambda function (including retries), it guarantees that a message is sent to SQS for each invocation attempt. This is the only approach that satisfies the 'each invocation' requirement.
Why the Other Options Fail
- Option A (Dead-letter queue): A DLQ only receives messages after all retry attempts are exhausted. It does not log successful invocations or intermediate retry attempts.
- Option C (Two destinations + CloudWatch alarm): Lambda asynchronous invocation destinations fire only on terminal states — final success or final failure. They do not fire on retryable failures. Therefore, retry attempts are not logged. The CloudWatch alarm on
DestinationDeliveryFailuresonly catches cases where the destination itself fails to receive the message, not retryable Lambda failures. - Option D (Single destination for success only): This only captures successful invocations, completely missing failures and retries.
Community Insight
As user Arad correctly points out, asynchronous invocations have three potential states: success, failure, and retryable failure. Destinations only cover the first two terminal states. Users italiancloud2025 and YUICH debated between B and C/D, but the strict wording 'each invocation' makes B the only technically complete answer.
Official Reference
- https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html
- https://docs.aws.amazon.com/lambda/latest/dg/invocation-async#invocation-async-destinations
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question says 'each invocation' or 'every invocation,' think about whether the proposed solution captures retry attempts as well as terminal states. Lambda destinations and DLQs only handle terminal outcomes; in-code SDK calls are needed to log every single execution attempt.
Community Votes
44% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 7
-
Arad 👍 2 Answered BB is the correct answer. When using asynchronous invocations, there are three types of potential states: success, failure and retryable failure. this option only logs first 2, not all. A is wrong because it only logs the failure invocations, not all. C is wrong because it only logs success and failure invocations, not all. D is wrong because it logs only successful invocations, not all.
-
YUICH 👍 2 Answered DRequirements: Lambda function is invoked via Amazon SNS. You need to log each invocation (successful or failed) to an Amazon SQS queue.
-
italiancloud2025 👍 1 Answered CDudo entre la B y la C porque aunque la B no registra todo, los fallos reintentables no son estados definitivos, hay reintento y la C es un poco demasiado esfuerzo, no es eficiente operacionalmente, aunque tampoco se pide eso
-
e886835 👍 1 Answered Busing the AWS SDK within the Lambda function code to call SendMessage to SQS, the developer can ensure that the invocation details are logged in the queue.
-
ShakthiGCP 👍 1 Answered DOne SQS for success is sufficient and when the undelivered message will be monitored via cloudwatch.
Show 2 more comments
-
LingZ 👍 1 Answered BCreate code that uses the AWS SDK to call the SQS SendMessage operation.
-
Dahlia9524 👍 1 Answered CLambda Destination supported for both success and failure
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →