SAA-C03 Design Resilient Architectures Practice Question
A inventory service 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
Many exam-takers confuse Lambda DLQs with SQS DLQs or assume that increasing retries (via reserved concurrency or package size) solves the retention problem, but the key is the explicit configuration to capture events after retries are exhausted.
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 correct AWS-native mechanism to retain failed events after retries are exhausted. When a Lambda function fails to process an event (e.g., due to an unreliable third-party API), the function can be configured to send the failed event payload to an SQS queue or SNS topic for later investigation. This ensures no data loss and aligns with the requirement for a managed, AWS-native solution.
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 Lambda reserved concurrency to zero does not provide any error-handling or event-preservation mechanism; it instantly throttles all invocations so the function never runs. With asynchronous invocation, events that are throttled are not automatically routed to a dead-letter queue unless you explicitly configure one, and in many cases they are simply discarded after retries fail. This option is a control to halt processing, not a strategy to capture or dwell on failed events.
- ✓
A Lambda dead-letter queue or failure destination
Why this is correct
Configuring a Lambda dead-letter queue (DLQ) or an asynchronous failure destination is the correct solution because Lambda will automatically send events that have exhausted built-in retries to a specified SQS queue, SNS topic, or other destination. This preserves the failed event payload and metadata, enabling you to inspect, replay, or alert on the failure. For asynchronous invocations, this is the standard pattern for building resilient, observable serverless workflows.
- ✗
A larger deployment package
Why it's wrong here
Increasing the Lambda deployment package size does not affect how Lambda handles failed asynchronous events. Package size influences cold start latency and memory limits, but the retry policy, DLQ routing, and failure destinations are determined by the function's configuration, not its code artifact size. Therefore, resizing the package cannot help capture or process events that have failed.
- ✗
CloudFront error pages
Why it's wrong here
CloudFront error pages are irrelevant to Lambda invocation failures because CloudFront is a content delivery network that handles HTTP requests and responses, not the internal event flow of Lambda. While you can configure CloudFront to return custom error responses for origin errors, it does not intercept or manage Lambda's asynchronous retries or DLQ delivery. This option confuses the edge delivery layer with the event processing pipeline.
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
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.