SAA-C03 Design Resilient Architectures Practice Question
A serverless order-ingestion API writes directly to a database. During traffic spikes, the database occasionally throttles, Lambda retries create duplicate order records, and some requests time out. Which two changes best improve buffering and safe retry behavior? Select two.
⚠ Common exam trap
Many candidates think SNS (Option C) is a suitable replacement for SQS because both are messaging services, but SNS lacks buffering and retry mechanics, making it inappropriate for smoothing traffic spikes and handling failures gracefully.
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
✓
Put an Amazon SQS queue between the API and the database-processing function.
Option B is correct because inserting an Amazon SQS queue between the API and the database-processing function decouples ingestion from database writes, allowing the queue to absorb traffic spikes and buffer requests while the consumer processes them at a rate the database can sustain, which directly addresses throttling and timeouts. Option D is correct because making the database write idempotent using a unique request token or order ID ensures that Lambda retries of the same message do not create duplicate order records, which is the standard safe-retry pattern for at-least-once delivery systems like SQS. Option A is not appropriate because increasing the Lambda timeout while continuing direct database writes does nothing to buffer spikes or prevent duplicate records, and longer timeouts can worsen throttling pressure. Option C is not appropriate because SNS is a pub/sub fan-out service, not a durable buffering queue, and immediate delivery to all subscribers does not provide the backpressure or retry buffering needed here. Option E is not appropriate because disabling retries sacrifices reliability and does not solve the underlying throttling or duplicate-write problem.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the Lambda timeout and keep writing directly to the database.
Why it's wrong here
A longer timeout lets a throttled write wait, but the Lambda still writes directly to the database, so throttling and duplicate retries persist and no buffering is introduced. It tempts because timeouts do cause failures, yet decoupling through a queue with idempotent consumers is what absorbs spikes.
When this WOULD be correct
If the question were about handling a slow database that occasionally takes longer than the default Lambda timeout (e.g., 3 seconds) but never throttles, and idempotency is already handled, increasing the timeout would prevent timeouts.
- ✓
Put an Amazon SQS queue between the API and the database-processing function.
Why this is correct
Amazon SQS decouples ingestion from database writes, absorbing traffic spikes as a buffer while the processing function consumes at a controlled rate. It also enables safe retries via visibility timeouts and dead-letter queues, preventing duplicate order records and timeouts.
- ✗
Replace SQS with SNS so every request is delivered immediately to all subscribers.
Why it's wrong here
SNS fans out to many subscribers rather than buffering messages, so it provides no queue-based holding capacity and cannot smooth database throttling. It tempts because SNS is a managed pub/sub service, but it suits broadcast notification, whereas SQS is correct for durable buffering and safe retry.
When this WOULD be correct
A question where the goal is to fan out a single event to multiple downstream services (e.g., order placed triggers email, SMS, and analytics) and immediate delivery is acceptable, with no need for buffering or retry control.
- ✓
Make the database write idempotent by using a unique request token or order ID.
Why this is correct
Idempotency via a unique request token or order ID lets the database reject duplicate inserts when Lambda retries after throttling, satisfying the safe retry requirement. The token makes each write uniquely identifiable, so repeated attempts produce one record rather than duplicates.
- ✗
Disable retries so failed writes are never duplicated.
Why it's wrong here
Disabling retries removes the duplicate records but also discards genuinely failed writes, so no safe retry remains and throttled requests are lost. It tempts as a blunt fix for idempotency, yet the correct approach keeps retries and makes writes idempotent, for example via a deduplication key.
When this WOULD be correct
In a scenario where duplicate processing is unacceptable and the system can tolerate occasional data loss (e.g., non-critical logging), and retries are handled externally (e.g., by a queue with DLQ), disabling Lambda retries prevents duplicate records.
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.
✓Put an Amazon SQS queue between the API and the database-processing function.Correct answer▾
Why this is correct
Amazon SQS decouples ingestion from database writes, absorbing traffic spikes as a buffer while the processing function consumes at a controlled rate. It also enables safe retries via visibility timeouts and dead-letter queues, preventing duplicate order records and timeouts.
✗Increase the Lambda timeout and keep writing directly to the database.Wrong answer — click to see why▾
Why this is wrong here
Increasing Lambda timeout does not address database throttling or duplicate records; it only allows the function to wait longer, but the database will still throttle under load, and retries will still create duplicates.
★ When this WOULD be the correct answer
If the question were about handling a slow database that occasionally takes longer than the default Lambda timeout (e.g., 3 seconds) but never throttles, and idempotency is already handled, increasing the timeout would prevent timeouts.
Why candidates choose this
Candidates think that giving Lambda more time will solve the throttling issue, but they overlook that the root cause is database capacity, not Lambda execution time.
✗Replace SQS with SNS so every request is delivered immediately to all subscribers.Wrong answer — click to see why▾
Why this is wrong here
SNS pushes messages to all subscribers immediately without buffering or throttling, so it does not help with database throttling or retry management; it would still overwhelm the database and cause duplicate processing.
★ When this WOULD be the correct answer
A question where the goal is to fan out a single event to multiple downstream services (e.g., order placed triggers email, SMS, and analytics) and immediate delivery is acceptable, with no need for buffering or retry control.
Why candidates choose this
Candidates may confuse SNS with SQS, thinking any messaging service provides buffering, or they may overvalue 'immediate delivery' without considering the need for decoupling and retry safety.
✗Disable retries so failed writes are never duplicated.Wrong answer — click to see why▾
Why this is wrong here
Disabling retries entirely would cause order writes to fail permanently during throttling, losing data and increasing timeouts, which contradicts the need for safe retry behavior.
★ When this WOULD be the correct answer
In a scenario where duplicate processing is unacceptable and the system can tolerate occasional data loss (e.g., non-critical logging), and retries are handled externally (e.g., by a queue with DLQ), disabling Lambda retries prevents duplicate records.
Why candidates choose this
Candidates may think that disabling retries directly solves the duplication problem without considering that it also eliminates the ability to recover from transient failures, leading to data loss.
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
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.