SAA-C03 Design Resilient Architectures Practice Question
An order system receives events and uses a Lambda function to write each order into a database. During traffic spikes, the database sometimes throttles, and Lambda retries lead to occasional message loss in the event flow. The team wants buffering, automatic retries, and a way to isolate messages that repeatedly fail so they can be inspected later. What design change best meets this need?
⚠ Common exam trap
Many candidates assume a direct event-driven flow (like EventBridge to Lambda) is simpler and sufficient, but they overlook the need for buffering and a DLQ to handle throttling and isolate persistent failures, which SQS explicitly provides.
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
✓
Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).
Amazon SQS acts as a durable buffer between the event source and Lambda, absorbing traffic spikes and decoupling the producer from the consumer. The SQS dead-letter queue (DLQ) automatically captures messages that exceed the configured maximum retries, allowing the team to inspect and reprocess them later without loss. This design provides the required buffering, automatic retries via the Lambda event source mapping, and isolation of repeatedly failing messages.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Send events directly from EventBridge to Lambda without any queue to simplify the flow.
Why it's wrong here
Sending events directly from EventBridge to Lambda without an intermediate queue simplifies the architecture but sacrifices durability and backpressure. EventBridge uses asynchronous push-based invocation; when Lambda is throttled or unavailable, the event may be retried a limited number of times (and only via the Lambda async invocation policy, not queue-based redrive) then discarded. Without a queue to hold events during demand spikes, you cannot control the polling rate, and there is no dedicated dead-letter mechanism at the EventBridge integration layer, making it impossible to replay or audit failed order events after execution.
When this WOULD be correct
A question where the requirement is to minimize latency and cost for a low-volume, predictable event flow, and where message loss is acceptable. For example: 'A logging system processes non-critical events that can tolerate occasional drops; the team wants the simplest architecture.'
- ✓
Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).
Why this is correct
Using SQS as a buffer between the event source and Lambda is correct because SQS decouples event producers from the consumer, smoothing traffic spikes by buffering messages until Lambda can poll them. The visibility timeout provides built-in retry logic: if Lambda fails to process a message, it becomes visible again for another attempt, and after a configured Maximum Receives threshold, the message is automatically diverted to a dead-letter queue for later analysis. This pattern ensures that no order event is lost, supports backpressure, and lets you isolate recurring processing failures without disrupting the continuous flow of valid events.
- ✗
Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.
Why it's wrong here
SNS fan-out to multiple Lambda functions is not a suitable alternative here because SNS is a publish/subscribe notification service, not a persistent buffer; it delivers each message exactly once per subscription and immediately discards it after the target's HTTP invocation completes. Without explicit retry logic or a dead-letter queue, any Lambda invocation that fails due to cold start errors, concurrency throttles, or transient faults will silently drop that order event, breaking reliability. SNS also lacks the visibility-timeout-based retry mechanics of SQS, so it cannot smooth bursty traffic or guarantee at-least-once processing.
When this WOULD be correct
A system needs to broadcast the same event to multiple independent downstream services (e.g., notification, analytics, audit) simultaneously, and each service has its own retry and error handling. SNS fan-out is ideal for this parallel distribution.
- ✗
Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.
Why it's wrong here
Triggering Lambda immediately from S3 object uploads is fundamentally a file-processing pattern, not a message-queuing one, and each upload fires an asynchronous invocation with only two automatic retries and no built-in batching buffer. S3 event notifications do not natively integrate with SQS DLQs for the same redrive behavior, so persistently failing messages are simply dropped after retries, and the source order event is gone. This approach also introduces latency and storage costs for ephemeral events and provides no visibility-timeout control, making it unsuitable for a high-throughput, durable order ingestion pipeline.
When this WOULD be correct
For a batch processing system where raw data must be durably stored for compliance and reprocessing, and failures are handled by a separate monitoring process, S3 triggering Lambda immediately is appropriate.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Use Amazon SQS as a buffer between the event source and Lambda, with an SQS dead-letter queue (DLQ).Correct answer▾
Why this is correct
Using SQS as a buffer between the event source and Lambda is correct because SQS decouples event producers from the consumer, smoothing traffic spikes by buffering messages until Lambda can poll them. The visibility timeout provides built-in retry logic: if Lambda fails to process a message, it becomes visible again for another attempt, and after a configured Maximum Receives threshold, the message is automatically diverted to a dead-letter queue for later analysis. This pattern ensures that no order event is lost, supports backpressure, and lets you isolate recurring processing failures without disrupting the continuous flow of valid events.
✗Send events directly from EventBridge to Lambda without any queue to simplify the flow.Wrong answer — click to see why▾
Why this is wrong here
Sending events directly from EventBridge to Lambda without a queue provides no buffering during traffic spikes, so Lambda retries still cause throttling and message loss. It also lacks a dead-letter queue to isolate repeatedly failing messages.
★ When this WOULD be the correct answer
A question where the requirement is to minimize latency and cost for a low-volume, predictable event flow, and where message loss is acceptable. For example: 'A logging system processes non-critical events that can tolerate occasional drops; the team wants the simplest architecture.'
Why candidates choose this
Candidates may think removing the queue simplifies the architecture and reduces latency, overlooking the need for buffering and retry isolation during spikes.
✗Use SNS fan-out to multiple Lambda functions, but keep no retry logic and no DLQ.Wrong answer — click to see why▾
Why this is wrong here
SNS fan-out without retry logic or a DLQ does not provide buffering, automatic retries, or isolation of failed messages, which are explicitly required to handle throttling and prevent message loss.
★ When this WOULD be the correct answer
A system needs to broadcast the same event to multiple independent downstream services (e.g., notification, analytics, audit) simultaneously, and each service has its own retry and error handling. SNS fan-out is ideal for this parallel distribution.
Why candidates choose this
Candidates may think SNS fan-out adds reliability through multiple subscribers, but they overlook that without retries and a DLQ, failed messages are lost, failing to meet the question's requirements for buffering and error isolation.
✗Store events in an S3 bucket and trigger Lambda immediately after each upload, without using DLQs.Wrong answer — click to see why▾
Why this is wrong here
S3 event notifications have no built-in retry logic or dead-letter queue; if Lambda fails, the event is lost after the retry limit, failing to isolate repeatedly failing messages for inspection.
★ When this WOULD be the correct answer
For a batch processing system where raw data must be durably stored for compliance and reprocessing, and failures are handled by a separate monitoring process, S3 triggering Lambda immediately is appropriate.
Why candidates choose this
Candidates may think S3 provides durable storage and automatic event triggers, overlooking the lack of retry and DLQ capabilities needed for handling transient failures and isolating poison messages.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.