一個基於機器學習的監控服務被設定為 EventBridge API 目的地，以接收 Auto Scaling 事件。CloudWatch 指出 EventBridge 規則正在觸發，但監控服務未收到事件。SysOps 管理員希望以最少的操作工作量來捕獲客戶端錯誤詳細資訊。應該實施哪種解決方案？

正確答案是將 Amazon SQS 標準佇列作為 EventBridge 目標的無效信件佇列，並檢查佇列中的訊息以獲取錯誤詳細資訊。這是因為 EventBridge 支援將無效信件佇列 (DLQ) 配置為目標，以便在事件傳遞失敗時捕獲這些事件。透過將 SQS 佇列設定為 DLQ，管理員可以輕鬆檢查佇列中的訊息，以獲取有關傳遞失敗的錯誤詳細資訊，而無需修改現有應用程式或引入新的複雜組件。 其他選項的缺點： 為事件模式建立 EventBridge 存檔並重播事件：這需要額外的步驟來設定存檔和手動重播，且可能無法即時捕獲錯誤。 建立第二個 EventBridge 規則調用 Lambda 函數：這增加了系統的複雜性，需要編寫和維護 Lambda 程式碼，並且可能引入新的故障點。 設定 EventBridge 規則以將錯誤訊息發佈到 Amazon SNS topic：SNS 主要用於發送通知，而不是作為詳細錯誤訊息的儲存庫，且可能需要額外的訂閱者來處理這些錯誤訊息。