SAA-C03 Design Resilient Architectures Practice Question
An order processing workflow uses Amazon SQS as the decoupling layer between a producer and a consumer Lambda function. The consumer intermittently fails due to a downstream dependency. The team has observed that certain “poison” messages keep being retried repeatedly and prevent other messages from being processed efficiently. Which SQS configuration most directly addresses this issue?
⚠ Common exam trap
It's easy for candidates to confuse increasing the visibility timeout or switching to FIFO as solutions for poison messages, but neither addresses the root cause of isolating messages that repeatedly fail processing.
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 a redrive policy with a dead-letter queue (DLQ) and set an appropriate visibility timeout greater than the maximum processing time.
Configuring a redrive policy with a dead-letter queue (DLQ) allows messages that exceed a specified maximum receive count to be moved to the DLQ, isolating poison messages. Setting the visibility timeout greater than the maximum processing time ensures the consumer has enough time to process each message before it becomes visible again, preventing premature retries. This directly addresses the issue of poison messages blocking the queue and degrading throughput.
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 SQS queue’s retention period to 10 years and rely on application retries to eventually succeed.
Why it's wrong here
Retention affects how long messages remain available, but it doesn’t isolate repeatedly failing messages.
- ✗
Increase visibility timeout to a very large value and avoid dead-letter queues to keep ordering stable.
Why it's wrong here
Long visibility time can delay failures, but it does not provide dead-letter isolation for poison messages.
- ✓
Configure a redrive policy with a dead-letter queue (DLQ) and set an appropriate visibility timeout greater than the maximum processing time.
Why this is correct
A DLQ isolates poison messages after a receive count threshold, and correct visibility timeout prevents premature retries.
- ✗
Switch the queue to FIFO and remove retries in the Lambda event source mapping entirely.
Why it's wrong here
FIFO and disabling retries do not reliably solve poison message isolation without DLQ-based redriving.
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 SAA-C03 question is part of Courseiva's 302-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 SAA-C03 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 SAA-C03 exam.