Course menuDVA-C03

Exams / DVA-C03 / Study guide / Lambda invocation, errors and destinations

Lambda invocation, errors and destinations: DVA-C03 study notes and practice questions

What to know about Lambda invocation, errors and destinations for the DVA-C03 exam, from the Development with AWS Services domain (30% of the exam guide), then 2 free questions to test it. Part of the DVA-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

Lambda event questions in Domain 1 cover how events reach a function and how errors travel back. The exam gives a trigger and a failure pattern, then asks which setting or destination stops lost events, duplicate work or repeated side effects.

Three invocation models

  • Synchronous: the caller waits for the result. Errors go straight back to the caller, and Lambda does not retry. The caller owns the retry, usually with backoff. The synchronous payload limit is 6 MB.
  • Asynchronous: Lambda queues the event and returns 202 at once. Lambda retries a failed invocation twice by default. The maximum event age and the retry count can be set, and failed events can go to an on-failure destination or a dead-letter queue. The asynchronous payload limit is 1 MB.
  • Event source mapping (polling): Lambda polls SQS, Kinesis, DynamoDB Streams or Amazon MSK and invokes the function with batches. S3, SNS and API Gateway push events instead, so batch settings do not apply to them.

Failure handling by source

Source Failure tool
Asynchronous invocation Retry settings, maximum event age, on-failure destination, DLQ
Kinesis or DynamoDB Streams Bisect on error, maximum retries, maximum record age, on-failure destination
SQS Redrive policy with a DLQ on the source queue, and partial batch responses

Destinations are for asynchronous invocations and stream sources. For SQS, the dead-letter queue is set on the source queue itself.

SQS batches

  • Turn on ReportBatchItemFailures. The handler catches errors per message, collects the failed message IDs and returns them in batchItemFailures. Lambda deletes the successful messages and makes only the listed ones visible again.
  • A handler that re-raises the error fails the whole batch, so every message is retried.
  • The queue’s visibility timeout must be at least the function timeout. AWS recommends six times the function timeout to avoid mid-processing reappearances.

Filtering and pausing

  • Event filtering on an event source mapping sends only matching records to the function. For SQS, filtering can check fields in the JSON body. Non-matching messages are removed without an invocation.
  • To pause processing without deleting the trigger, set reserved concurrency to 0. Throttled asynchronous events are retried for a period, then discarded.

Common traps

  • Duplicate emails or charges after an asynchronous function fails. Set retries to zero if repeats are unsafe, and use an on-failure destination to keep the event.
  • A DLQ on an asynchronous function when the team needs the response status and error. A failure destination keeps those details.
  • Expecting batch settings to affect S3 or SNS triggers.
  • A visibility timeout shorter than the function timeout, which causes duplicate processing.
  • Sending large payloads to an asynchronous invocation. Write the data to S3 and pass the location.

Try the 2 practice questions

An Amazon SNS topic invokes a Lambda function asynchronously for each order message.

When the function fails on all of its retries, the team wants a record of each failed event that includes the function's response, such as its status code and error payload, so that the failures can be analyzed later.

What should the developer configure?

Choose one answer.

  1. A. A dead-letter queue on the function, using an Amazon SQS queue as the target.
  2. B. A longer function timeout, together with more retries configured on the topic.
  3. C. CloudWatch Logs for the function, with a daily search of the logs for error messages.
  4. D. An on-failure destination for asynchronous invocation, such as an Amazon SQS queue.
Show the answer and explanation

Answer: D

  • A. Wrong: A dead-letter queue receives the event itself, plus a few attributes such as the start of the error message. It does not include the response details, such as the status code or the error payload.
  • B. Wrong: A longer timeout records nothing about failures, and more retries only repeat the attempt. Neither keeps the response the team wants to analyze.
  • C. Wrong: Logs keep whatever the function prints, but they do not keep the failed event for replay, and they are not a structured record of each failure.
  • D. Right: Correct. The destination receives a record for each failed event that includes the request payload, the response status and the error payload. Learn more: Capturing records of Lambda asynchronous invocations (opens in a new tab)

Explanation

For asynchronous invocations, a failure destination receives a record of the failed event that includes the response status and the error payload. A dead-letter queue keeps the event and a few attributes only, so it misses the response details the team needs.

A Lambda on-failure destination compared with a dead-letter queue An event source such as SNS, EventBridge or S3 invokes a Lambda function asynchronously. When every retry fails, an on-failure destination SQS queue receives a record with the event, the response status code and the error payload. A dead-letter queue, shown for comparison, keeps only the event and a few attributes. Event source SNS, EventBridge, S3 async invoke Lambda function all retries fail SQS queue on-failure destination Dead-letter queue event only record: event, status, error payload
The on-failure destination keeps the function's response with the event. A dead-letter queue keeps only the event.

Study

Question 2

Medium · choose 2 ·Link to this question (question 2)

A data team wants one Lambda function to process incoming records in batches, tuning the batch size and the batching window, and to retry failed batches.

Several services could feed the function.

Which TWO of these sources can feed Lambda through an event source mapping, in which Lambda polls the source itself? (Choose two.)

Choose two answers.

  1. A. Amazon S3 bucket event notifications
  2. B. Amazon SQS standard or FIFO queues
  3. C. Amazon SNS topics with a Lambda subscription
  4. D. Amazon DynamoDB table streams
  5. E. Amazon API Gateway REST API methods
Show the answer and explanation

Answers: B, D

  • A. Wrong: S3 pushes each event to Lambda, and the trigger is configured on the bucket. Lambda does not poll the bucket, so there is no event source mapping to tune.
  • B. Right: Correct. Lambda polls the queue and invokes the function with batches of messages, deleting each message once it has been processed successfully. Learn more: Lambda event source mappings (opens in a new tab)
  • C. Wrong: SNS pushes each message to the subscribed function. Lambda does not poll the topic, so batch size and batching window do not apply.
  • D. Right: Correct. Lambda polls the stream through an event source mapping and reads records in order for each shard, using the batch size and batching window settings. Learn more: Lambda event source mappings (opens in a new tab)
  • E. Wrong: API Gateway invokes the function directly for each request. There is nothing to poll, and no batching is involved.

Explanation

Lambda polls some sources through event source mappings, including SQS, Kinesis, DynamoDB streams and Amazon MSK. Services such as S3, SNS and API Gateway push events to the function instead, so batch size and batching window do not apply to them.

Study

Want more on Lambda invocation, errors and destinations? The 5 full-length practice sets have 9 more Lambda invocation, errors and destinations questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Lambda invocation, errors and destinations

More Development with AWS Services topics