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 team wants the control to be enforceable during normal operations.
⚠ Common exam trap
Many candidates confuse Lambda's synchronous invocation error handling (where DLQs are not supported) with asynchronous invocation, or mistakenly think that increasing function resources (like deployment package size) can improve reliability against external API failures.
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
A Lambda dead-letter queue (DLQ) or failure destination allows you to capture events that have exhausted all retry attempts from an asynchronous invocation. This ensures failed events are retained in Amazon SQS or SNS for later investigation, providing enforceable control during normal operations without impacting the function's ability to process successful events.
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 disables the function's execution capacity entirely, so every invoke immediately receives a throttling error. While this can be used as an emergency off switch, it does not configure any mechanism to retain or route events that fail those invocations. Asynchronous events that cannot be processed are still subject only to Lambda's default retry policy and will be discarded when those retries are exhausted, unless a separate DLQ or failure destination is attached.
- ✗
A larger deployment package
Why it's wrong here
A larger deployment package only increases the peak memory and disk footprint of the function, which can lengthen cold start durations and affect timeout-based execution. It has no bearing on whether Lambda's runtime captures or routes failed asynchronous invocations. Failed events are preserved only by the invocation configuration (DLQ or failure destination), not by the size of the code bundle uploaded to S3. Therefore, resizing the deployment package does not address the requirement to capture failed events.
- ✗
CloudFront error pages
Why it's wrong here
CloudFront is a content delivery network that sits in front of HTTP endpoints and can serve custom error pages when an origin returns a status such as 503 or 500. Lambda asynchronous function errors, however, occur inside the managed Lambda service during event processing, not as an HTTP response that passes through CloudFront. CloudFront has no visibility into, or control over, Lambda's async retry attempts, so it cannot be used to capture or store events that Lambda failed to process.
- ✓
A Lambda dead-letter queue or failure destination
Why this is correct
A Lambda dead-letter queue (an SQS queue or SNS topic) or an asynchronous failure destination is the AWS-recommended way to retain events that exhaust Lambda's two built-in retries. After the retry attempts fail, Lambda writes the event payload to the configured SQS/SNS or invokes a destination like another Lambda, EventBridge, or SNS, enabling a separate process to analyze or replay the failed event. To use it, the function must have a resource-based policy granting Lambda permissions to send to the DLQ/destination, and the configuration must be set on the function's event-invoke settings.
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.