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.
Inserting an SQS queue between the API Gateway and the Lambda function decouples the ingestion from the database write. During traffic spikes, SQS buffers the requests, allowing the Lambda function to poll at a controlled rate, which prevents database throttling. Additionally, SQS provides built-in retry logic with a visibility timeout, so failed messages are automatically retried without creating duplicate order records.
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 may hide transient failures, but it does not add buffering or prevent duplicate writes.
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
SQS buffers bursts and decouples producers from consumers, so the database can be processed at a steadier rate.
- ✗
Replace SQS with SNS so every request is delivered immediately to all subscribers.
Why it's wrong here
SNS fanout is useful for notifications, but it does not provide durable work queue buffering for a throttled consumer.
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 ensures repeated deliveries or retries do not create duplicate orders when the same request is processed again.
- ✗
Disable retries so failed writes are never duplicated.
Why it's wrong here
Disabling retries reduces duplicates, but it also turns transient failures into permanent lost orders.
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
SQS buffers bursts and decouples producers from consumers, so the database can be processed at a steadier rate.
✗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 302-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.