Batch meter-reading events arrive on Amazon SQS. A Lambda function should process messages in batches and report which messages failed so successful ones are not reprocessed. What should the developer enable?
Select an answer to reveal the explanation.
Short Explanation
SQS can hand Lambda a handful of meter events at once—great for throughput—but one bad message should not force the good ones to replay. Partial batch failure reporting tells SQS exactly which items failed. Blowing away the queue or forcing batch size one throws away that design.
Full Explanation
When batch meter-reading events arrive on Amazon SQS and a Lambda should process messages in batches while reporting which messages failed so successful ones are not reprocessed, configure an SQS event source mapping with batching and implement partial batch failure reporting in the handler response. Returning the failed message identifiers tells the service to retry only those items, preserving progress on good readings. That is essential when one poison reading must not rewind an entire batch of valid utility data and trigger duplicate downstream posts.
Disabling the event source mapping and polling with a single-threaded EC2 worker abandons managed scaling and batch failure APIs. Setting batch size to 1 and deleting the entire queue after any error destroys data and overreacts to a single bad message. Converting the queue to SNS fanout for separate synchronous invokes changes the architecture and loses the SQS batching behavior the question asks you to enable.
Exam caveat: partial batch failure reporting must be enabled on the event source mapping and the handler must return the correct failure structure. Without it, a single failure can retry the whole batch. Handlers should still be idempotent because retries happen.
Operational check: enable ReportBatchItemFailures; return only failed IDs; test a mixed good/bad batch; confirm good messages delete while bad ones retry or DLQ; and monitor batch-failure metrics during meter ingestion storms.