These questions are independently created for study purposes. They are not official AWS exam questions, actual exam questions, leaked questions, or exam dumps.
SAA-011
In an order processing system, you want to decouple the order intake API from the inventory update process. Which configuration allows order messages to be retained and processed later even if the inventory update process is temporarily down?
Choices
Explanation and answer
Read the explanation and correct answer (spoiler — try answering first)
Correct answer: A. Send messages from the API to an SQS queue and have the inventory update Lambda process the queue.
Explanation
SQS lets you decouple order intake from inventory updates asynchronously. Even if the consumer is temporarily down, messages remain retained in the queue.
Per-choice explanations
A. Send messages from the API to an SQS queue and have the inventory update Lambda process the queue.
Correct. SQS is well suited to asynchronous processing and buffering.
B. Rely solely on the CORS configuration of API Gateway.
Incorrect. CORS controls browser access and does not improve the reliability of asynchronous processing.
C. Invoke the inventory update Lambda synchronously from the API.
Incorrect. Synchronous invocation means a failure on the inventory side propagates to order intake.
D. Only write the order content to CloudWatch Logs from the API.
Incorrect. CloudWatch Logs is not a processing queue.
Practical Use
Amazon SQS is a fully managed queue service that separates message producers and consumers in time and location. When the order intake API receives a request, it places a message on SQS, and the inventory update worker runs as a separate process that pulls messages at its own pace. Even if the inventory side is temporarily unavailable, messages are retained in the queue for up to 14 days. Standard queues offer at-least-once delivery without ordering guarantees, while FIFO queues provide ordering and exactly-once processing. Alternatives include SNS (pub/sub) and EventBridge (event bus). SNS is intended for notification fan-out and EventBridge is intended for routing and schema management. For a polling-based job queue where workers pull messages, SQS is the most direct fit. Two operational rules of thumb on the consumer side are to set the visibility timeout longer than the processing time, and to always configure a Dead Letter Queue (DLQ) so that messages exceeding the retry limit are moved aside. On SAA-C03, when the question mentions decoupling, asynchronous processing, or fault tolerance, SQS becomes the first candidate. Distractors typically substitute other concerns such as "call the worker synchronously over HTTP," "write directly to DynamoDB," or "scale EC2 with Auto Scaling." The choice between SNS and SQS (notification fan-out vs. a worker queue) is also a frequent point of confusion.