這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-011
在訂單處理系統中,希望讓訂單受理 API 與庫存更新處理達成鬆耦合。即使庫存更新處理暫時停擺,也不會遺失訂單訊息,並能於稍後處理,下列哪個架構最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：A. 由 API 將訊息送至 SQS 佇列,庫存更新 Lambda 從 SQS 取出處理
解析
使用 SQS 可讓訂單受理與庫存更新非同步且鬆耦合。即使處理端暫時停擺,訊息仍能保留於佇列中。
各選項解析
A. 由 API 將訊息送至 SQS 佇列,庫存更新 Lambda 從 SQS 取出處理
正解。SQS 適合非同步處理與緩衝。
B. 僅以 API Gateway 的 CORS 設定加以控制
CORS 為瀏覽器存取控制,並非提升非同步處理可靠性的功能。
C. 由 API 同步呼叫庫存更新 Lambda
同步呼叫時,庫存更新端的故障容易影響訂單受理。
D. 由 API 將訂單內容輸出至 CloudWatch Logs 即可
CloudWatch Logs 並非處理佇列。
實際使用情境
Amazon SQS 是用於將訊息傳送端(生產者)與接收端(消費者)在時間與實體上加以分離的全受管佇列服務。當訂單受理 API 接收請求時即將訊息投入 SQS,庫存更新工作者則作為獨立行程依自身步調取出訊息處理,如此即便庫存更新端暫時停擺,訊息仍可在佇列中保留最多 14 天。標準佇列(Standard Queue)不保證順序,提供至少一次傳遞;FIFO 佇列則保證順序與精確一次處理。 替代方案包括 SNS(pub/sub)與 EventBridge(事件匯流排),但 SNS 用於通知扇出,EventBridge 用於路由與結構描述管理,而由工作者主動拉取訊息的輪詢式作業佇列,以 SQS 最為直觀適配。運維面上有兩個定石:消費端的可見性逾時(Visibility Timeout)需設定得長於處理時間;對於超過重試次數的訊息,務必設定死信佇列(Dead Letter Queue, DLQ)加以隔離。 SAA-C03 中,題幹若出現鬆耦合(decoupling)、非同步處理、容錯性等關鍵字,SAS 為第一候選。誤答選項常將論點偷換為「工作者端以同步 HTTP 呼叫」「直接寫入 DynamoDB」「以 Auto Scaling 擴增 EC2」等與鬆耦合無關的方向。SNS 與 SQS 的使用區分(通知派送 vs 工作者佇列)亦為高頻論點。