SOA-C02 SQS Redrive Policy Practice Question
A company is using AWS Lambda functions to process incoming messages from Amazon SQS. The Lambda function sometimes fails due to a transient error, and the message is not processed. The team wants to automatically retry failed messages and send them to a dead-letter queue (DLQ) after three failed attempts. Which configuration meets these requirements?
⚠ Common exam trap
The trap is that candidates often assume the Lambda dead-letter configuration applies to SQS event source mappings. However, for SQS triggers, retries and DLQ routing are managed by the SQS queue's redrive policy, not by Lambda's DLQ settings.
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
✓
Configure the SQS queue with a redrive policy that allows three maximum receives before sending to a DLQ.
When SQS is configured as an event source for Lambda, retries are controlled by the SQS queue's redrive policy. The redrive policy with maxReceiveCount determines how many times a message can be received before it is moved to the DLQ. Setting maxReceiveCount to 3 means after three receive attempts (i.e., three failed processing attempts), the message is sent to the DLQ. Option C is incorrect because Lambda's dead-letter configuration is used for asynchronous invocations, not for SQS event source mappings. For SQS-triggered functions, the DLQ must be configured on the SQS queue itself using a redrive policy, not on the Lambda function.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the Lambda function's reserved concurrency to 1 and enable 'maximumRetryAttempts' to 2.
Why it's wrong here
Reserved concurrency only caps the number of concurrent Lambda executions; it has no effect on how many times an SQS message is retried. 'maximumRetryAttempts' applies exclusively to asynchronous Lambda invocations, not to SQS event source mappings. SQS-based retries are governed by the queue's visibility timeout and redrive policy, so this combination neither limits retries nor sends failed messages to a DLQ.
- ✗
Create an SQS queue with a visibility timeout that allows three retries before sending to a DLQ.
Why it's wrong here
The visibility timeout simply controls how long a message remains invisible to other consumers after it has been received. It does not define a retry count, nor does it trigger a move to a dead-letter queue. To retry a message three times and then route it to a DLQ, you must configure a redrive policy with maxReceiveCount set to 3; the visibility timeout only influences the timing between retries.
- ✗
Configure the SQS queue as an event source for Lambda with a DLQ specified in the Lambda function's dead-letter configuration.
Why it's wrong here
When SQS is configured as the event source for Lambda, the dead-letter configuration on the Lambda function is ignored because Lambda's DLQ feature only applies to asynchronous invocations. The correct behavior for SQS-triggered Lambda functions is to specify a redrive policy on the SQS queue itself, pointing to a destination DLQ. Adding a DLQ to the Lambda function's settings does not affect SQS messages and therefore fails to meet the retry-then-DLQ requirement.
- ✓
Configure the SQS queue with a redrive policy that allows three maximum receives before sending to a DLQ.
Why this is correct
A redrive policy with maxReceiveCount set to 3 ensures that after the message has been received from the queue three times without successful processing, the message is automatically moved to the configured dead-letter queue. This is the standard SQS mechanism for defining retry limits because each receive attempt by the Lambda consumer counts toward maxReceiveCount. The DLQ is configured on the SQS queue itself, not on the Lambda function, and this behavior is specific to SQS event sources.
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
This SOA-C02 question is part of Courseiva's 247-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-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 SOA-C02 exam.