How to Handle Partial Batch Failures in Lambda with SQS
A company has an AWS Lambda function that processes messages from an Amazon SQS queue. The function is invoked with a batch size of 10. Some messages are failing repeatedly, causing the function to retry them up to the maximum retry count and then they are sent to a dead-letter queue (DLQ). The company wants to improve the resilience of the application by handling partial batch failures more efficiently. What should a solutions architect do?
Quick Answer
The correct answer is to implement reportBatchItemFailures in the Lambda function and enable partial batch response for the SQS event source mapping. This approach directly addresses Lambda SQS partial batch failure handling by allowing the function to return a list of failed message IDs, so only those specific messages are retried instead of the entire batch of ten. On the AWS Certified Solutions Architect Professional SAP-C02 exam, this scenario tests your understanding of event source mapping configurations and the difference between standard retry behavior and partial batch responses. A common trap is assuming that reducing the batch size or increasing retries solves the problem, but those approaches waste throughput and delay processing of successful messages. The key insight is that without reportBatchItemFailures, a single failure causes the whole batch to be retried or sent to the dead-letter queue, which is inefficient. Memory tip: think “report the failures, not the whole batch” — the function reports which items failed, and SQS retries only those.
⚠ Common exam trap
Candidates often think decreasing batch size to 1 is the simplest fix, but that ignores the throughput impact and the fact that AWS provides a native partial batch failure mechanism that is more efficient and scalable.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implement reportBatchItemFailures in the Lambda function and enable partial batch response for the SQS event source mapping.
Implementing reportBatchItemFailures in the Lambda function and enabling partial batch response for the SQS event source mapping allows the function to signal which specific messages within a batch failed. This prevents the entire batch from being retried or sent to the DLQ, and only the failed messages are retried individually, improving resilience and efficiency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Move the messages to a DLQ immediately after the first failure.
Why it's wrong here
Sending messages to a DLQ after the first failure discards transient errors that a retry could resolve, reducing resilience rather than improving it. Immediate DLQ routing suits poison-message isolation once retries are exhausted, not partial batch failure handling, which requires reporting individual failed message IDs.
- ✓
Implement reportBatchItemFailures in the Lambda function and enable partial batch response for the SQS event source mapping.
Why this is correct
ReportBatchItemFailures lets the function return only the identifiers of failed messages, so Lambda deletes successful ones and retries just the failures. This avoids reprocessing the entire batch of ten, directly satisfying the requirement to handle partial batch failures efficiently and reduce duplicate DLQ entries.
- ✗
Decrease the batch size to 1 so that each invocation processes a single message.
Why it's wrong here
Reducing batch size to 1 does not implement partial batch failure reporting; it merely shrinks each batch so fewer messages are affected per retry, increasing invocation count and cost. The correct fix is returning batchItemFailures from the handler so only failed messages are retried, which is what ReportBatchItemFailures exists for.
- ✗
Increase the batch size to 100 to process more messages per invocation.
Why it's wrong here
Increasing batch size to 100 worsens the problem: without partial batch response handling, one failing message causes the entire batch of up to 100 to be retried, amplifying duplicate processing. Larger batches suit high-throughput, idempotent workloads, not selective retry of individual failed messages.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAP-C02 question from scratch — 984 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SAP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company is using an AWS Lambda function to process records from an Amazon Kinesis stream. The function stores results in an Amazon DynamoDB table. The team notices that the Lambda function sometimes fails due to throttling from DynamoDB. Which TWO actions should the team take to improve the continuous processing of records? (Choose TWO.)
easy- A.Increase the number of shards in the Kinesis stream to reduce data per Lambda invocation.
- B.Configure reserved concurrency for the Lambda function to limit its maximum concurrency.
- C.Increase the concurrency limit for the Lambda function to allow more parallel executions.
- ✓ D.Switch the DynamoDB table to on-demand capacity mode.
- ✓ E.Enable DynamoDB auto scaling for the table to adjust read/write capacity automatically.
Why D: Switching the DynamoDB table to on-demand capacity mode eliminates the need to provision read/write capacity, allowing the table to automatically scale to handle any throttling caused by sudden spikes in Lambda writes. This directly addresses the throttling issue without requiring manual capacity management.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAP-C02 exam.