SAA-C03 Design Resilient Architectures Practice Question
A content publishing system uses Lambda functions that call an unreliable third-party API. Failed events must be retained for later investigation after retries are exhausted. What should be configured? The architecture review board prefers a managed AWS-native control.
⚠ Common exam trap
Watch out — candidates often confuse Lambda's synchronous invocation retry behavior (which is controlled by the caller) with asynchronous invocation retries (which are managed by Lambda itself and require a DLQ or failure destination for post-retry capture).
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
✓
A Lambda dead-letter queue or failure destination
Lambda dead-letter queues (DLQs) or failure destinations are the managed AWS-native way to capture events that have exhausted all retry attempts from an asynchronous invocation. When the Lambda function fails after the configured number of retries (default 3), the event is automatically sent to an SQS queue or SNS topic (DLQ) or to a specified destination (e.g., SQS, SNS, EventBridge) for later investigation and reprocessing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Lambda reserved concurrency set to zero
Why it's wrong here
Setting reserved concurrency to zero throttles the function, so every invocation is rejected with a ThrottlingError before the function's code executes; this is a capacity guardrail, not a data-retention mechanism. For asynchronous invocations, Lambda's built-in retry attempts will fail, but without a separately configured DLQ or failure destination those events are eventually discarded and not preserved for analysis. Moreover, a zero-reserved-concurrency configuration also prevents any legitimate traffic from being processed, so it is not a viable error-handling strategy.
- ✗
A larger deployment package
Why it's wrong here
The Lambda deployment package size directly impacts container initialization and cold start latency but has zero bearing on how the service handles function execution failures. Event delivery and retry behavior are determined by the invocation type and the function's failure destination or DLQ settings, not by the contents or size of the uploaded artifact. Increasing the package size would not add an error queue, and could actually exacerbate timeout-related failures by making cold starts slower, but it can never capture an event that failed.
- ✗
CloudFront error pages
Why it's wrong here
CloudFront error pages are used to customize HTTP error responses at the edge for content delivered through a distribution, such as displaying a friendly 404 page. CloudFront is not involved in Lambda's asynchronous event pipeline; standard Lambda functions are invoked directly by services like S3, SNS, or EventBridge, and CloudFront cannot see or handle those internal failures. Lambda@Edge functions are tied to CloudFront events, but even they do not intercept or dead-letter the asynchronous invocation retry process, so this option is irrelevant.
- ✓
A Lambda dead-letter queue or failure destination
Why this is correct
A dead-letter queue (SQS/SNS) or a failure destination is the correct mechanism because Lambda, after exhausting its default two retries, can route the original event payload to a configured target. A DLQ preserves the raw event and allows a separate process to consume, inspect, and reprocess it, while a failure destination offers richer metadata, such as the request ID and response context, and can send to SQS, SNS, Lambda, or EventBridge. This gives a durable record of failed async invocations and decouples error handling from the main processing function.
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 935-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.