AWS SAA-C03 Exam Questions

D. Use Amazon API Gateway with Amazon Kinesis Data Analytics

Why:

• Kinesis Data Analytics - Real-time data processing for streaming location data during peak hours
• API Gateway - Provides REST API access to the data points
• Real-time analytics - Suitable for tracking bicycles in real-time

Why not others:

• A (Athena + S3) - Batch processing, not suitable for real-time tracking
• B (API Gateway + Lambda) - No analytics capability
• C (QuickSight + Redshift) - Visualization tool, not for real-time data ingestion

B. Set up an S3 Lifecycle policy to transition objects to S3 Glacier Deep Archive after 2 years.
B. 設定 S3 生命週期政策，在 2 年後將物件轉換到 S3 Glacier Deep Archive。

Why:
為什麼：

• Immediate retrieval requirement – Keeping data in S3 Standard for the first 2 years ensures it is immediately retrievable and highly available.
  立即擷取需求－前 2 年將資料保留在 S3 標準級別中，可確保資料能被立即擷取並具備高可用性。

• Cost optimization – After 2 years, the immediate access requirement ends. Moving data to S3 Glacier Deep Archive (the lowest cost storage class) minimizes costs for the remaining 23+ years.
  成本最佳化－2 年後，立即存取的需求結束。將資料移至 S3 Glacier Deep Archive（成本最低的儲存類別）可將剩餘 23 年以上的保留成本降至最低。

Why not others:
為什麼不是其他選項：

• A (Immediate Deep Archive) – Retrieval from Deep Archive takes 12-48 hours, violating the requirement for data to be “immediately retrievable.”
  A（立即轉入 Deep Archive）－從 Deep Archive 擷取資料需要 12 到 48 小時，違反了資料需「立即擷取」的要求。

• C (Intelligent-Tiering) – Archive Access tiers in Intelligent-Tiering are not immediately retrievable (they act like Glacier). Also, a simple lifecycle policy is more direct for a fixed time-based rule.
  C（智慧分層）－智慧分層中的封存存取層無法立即擷取（類似 Glacier）。此外，對於固定的時間規則，簡單的生命週期政策更為直接。

• D (Immediate One Zone-IA) – S3 One Zone-IA stores data in a single Availability Zone. It is less resilient than S3 Standard and does not meet the strict “highly available” requirement (Multi-AZ resilience).
  D（立即轉入 One Zone-IA）－S3 One Zone-IA 僅將資料儲存在單一可用區域。其恢復能力低於 S3 標準級別，且無法滿足嚴格的「高可用性」需求（多可用區域韌性）。

D. Provision two Amazon Simple Queue Service (Amazon SQS) queues… Scale the Auto Scaling groups based on the number of messages in each queue.
D. 佈建兩個 Amazon Simple Queue Service (Amazon SQS) 佇列… 根據每個佇列中的訊息數量來擴展 Auto Scaling 群組。

Why:
為什麼：

• Decoupling with SQS prevents data loss – The scenario states fulfillment is slower than collection. SQS acts as a buffer, ensuring orders (messages) are stored durably until the fulfillment instances are ready to process them, preventing loss during scaling events.
  使用 SQS 解耦可防止資料遺失－情境指出履行速度慢於收集速度。SQS 作為緩衝區，確保訂單（訊息）被持久儲存，直到履行執行個體準備好處理它們，從而防止在擴展事件期間遺失資料。

• Scaling based on Backlog (Message Count) – Scaling based on the “ApproximateNumberOfMessagesVisible” metric ensures that as the queue grows (backlog increases), more EC2 instances are added to handle the load. This is the standard pattern for decoupling heavy processing workloads.
  基於積壓量（訊息數量）進行擴展－根據「可見訊息預估數量（ApproximateNumberOfMessagesVisible）」指標進行擴展，可確保當佇列增長（積壓增加）時，會增加更多 EC2 執行個體來處理負載。這是解耦繁重處理工作負載的標準模式。

Why not others:
為什麼不是其他選項：

• A (CPU Scaling & Static Capacity) – Setting minimum capacity to peak value is not cost-effective (no true auto-scaling). Also, CPU utilization is not the best metric for worker nodes that might be idle while waiting for work or I/O bound.
  A（CPU 擴展與靜態容量）－將最小容量設定為尖峰值並不具成本效益（並非真正的自動擴展）。此外，對於可能在等待工作時處於閒置狀態或受 I/O 限制的工作節點而言，CPU 使用率並非最佳指標。

• B (Creating additional ASGs) – Creating new Auto Scaling groups dynamically via SNS is an architectural anti-pattern. You should scale the size of the existing group, not provision new infrastructure groups.
  B（建立額外的 ASG）－透過 SNS 動態建立「新的」Auto Scaling 群組是一種架構上的反模式（anti-pattern）。你應該擴展「現有」群組的大小，而不是佈建新的基礎設施群組。

• C (Scaling based on notifications) – SQS does not push “notifications” directly to Auto Scaling groups for scaling. Scaling policies rely on CloudWatch metrics (like message count numbers), not event notifications.
  C（基於通知進行擴展）－SQS 不會直接推播「通知」給 Auto Scaling 群組來進行擴展。擴展政策依賴的是 CloudWatch 指標（如訊息計數數值），而非事件通知。

A. Use Amazon Athena for one-time queries. Use Amazon QuickSight to create dashboards for KPIs.
A. 使用 Amazon Athena 進行一次性查詢。使用 Amazon QuickSight 建立 KPI 儀表板。
E. Use blueprints in AWS Lake Formation to identify the data that can be ingested into a data lake. Use AWS Glue to crawl the source, extract the data, and load the data into Amazon S3 in Apache Parquet format.
E. 使用 AWS Lake Formation 中的藍圖來識別可攝取到資料湖中的資料。使用 AWS Glue 爬取來源、擷取資料，並將資料以 Apache Parquet 格式載入 Amazon S3。
Why: 為什麼：

• Option E (Ingestion): AWS Lake Formation blueprints provide a managed, low-overhead template to ingest data from databases and logs into a data lake (S3). AWS Glue crawlers automatically discover the schema. Converting to Apache Parquet is a best practice for performance and cost optimization in analytics.
  選項 E (攝取)： AWS Lake Formation 藍圖提供了一個託管的、低負擔的範本，用於將資料從資料庫和日誌攝取到資料湖 (S3) 中。AWS Glue 爬蟲會自動發現架構。轉換為 Apache Parquet 是分析中效能和成本最佳化的最佳實務。
  
• Option A (Analysis): Amazon Athena is a serverless query service that analyzes data directly in Amazon S3 using standard SQL. It is ideal for “one-time queries” without managing infrastructure. Amazon QuickSight is a fully managed BI service for visualizations (KPIs). Both align with the “least operational overhead” requirement.
  選項 A (分析)： Amazon Athena 是一種無伺服器查詢服務，可使用標準 SQL 直接分析 Amazon S3 中的資料。它非常適合無需管理基礎設施的「一次性查詢」。Amazon QuickSight 是用於視覺化 (KPI) 的完全託管 BI 服務。兩者都符合「最少營運負擔」的要求。
  Why not others: 為什麼不是其他選項：
  
• Option B: Amazon Kinesis Data Analytics is primarily for processing and analyzing streaming data in real-time, not for running ad-hoc SQL queries on consolidated data stored in S3.
  選項 B： Amazon Kinesis Data Analytics 主要用於即時處理和分析串流資料，而不是用於對儲存在 S3 中的整合資料執行臨機操作 SQL 查詢。
  
• Option C: Creating custom AWS Lambda functions involves writing and maintaining code, which incurs higher operational overhead compared to using managed services like Lake Formation and Glue. Moving individual records to Redshift is also less efficient for a data lake architecture than batch loading.
  選項 C： 建立自訂 AWS Lambda 函數涉及編寫和維護程式碼，與使用 Lake Formation 和 Glue 等託管服務相比，這會產生更高的營運負擔。對於資料湖架構而言，將個別記錄移動到 Redshift 的效率也低於批次載入。
  
• Option D: Amazon OpenSearch Service is a search engine, not a primary tool for general business intelligence dashboards compared to QuickSight. Converting to JSON is generally less efficient for analytics queries than columnar formats like Parquet.
  選項 D： 與 QuickSight 相比，Amazon OpenSearch Service 是一個搜尋引擎，而不是一般商業智慧儀表板的首選工具。對於分析查詢，轉換為 JSON 通常比 Parquet 等列式格式效率低。
  

A. Store the credentials as secrets in AWS Secrets Manager. Use multi-Region secret replication for the required Regions. Configure Secrets Manager to rotate the secrets on a schedule.
A. 將憑證作為機密儲存在 AWS Secrets Manager 中。針對所需區域使用多區域機密複寫。設定 Secrets Manager 依排程輪換機密。
Why: 為什麼：

• Native Rotation & Replication: AWS Secrets Manager is a managed service designed specifically for protecting secrets. It provides built-in integration with Amazon RDS to automatically rotate credentials without requiring custom code. The multi-Region replication feature allows you to keep secrets synchronized across regions, meeting the requirement with the least operational overhead.
  原生輪換與複寫： AWS Secrets Manager 是一項專為保護機密而設計的託管服務。它提供與 Amazon RDS 的內建整合，可自動輪換憑證，無需自訂程式碼。多區域複寫功能允許您跨區域同步機密，以最少的營運負擔滿足需求。
  Why not others: 為什麼不是其他選項：
  
• Option B: While AWS Systems Manager Parameter Store can store secrets (SecureString), it does not have the native, built-in capability to automatically rotate RDS credentials out-of-the-box like Secrets Manager does. It typically requires setting up a custom Lambda function to handle the rotation logic.
  選項 B： 雖然 AWS Systems Manager Parameter Store 可以儲存機密 (SecureString)，但它不具備像 Secrets Manager 那樣開箱即用的原生自動輪換 RDS 憑證的能力。它通常需要設定自訂 Lambda 函數來處理輪換邏輯。
  
• Option C: Using Amazon S3 to store secrets is not a security best practice compared to a dedicated secrets manager. Furthermore, building a custom rotation pipeline using EventBridge and Lambda involves significant development and maintenance overhead.
  選項 C： 與專用機密管理員相比，使用 Amazon S3 儲存機密並非安全最佳實務。此外，使用 EventBridge 和 Lambda 建立自訂輪換管道涉及大量的開發和維護負擔。
  
• Option D: This approach reinvents the wheel. Using DynamoDB for secret storage and writing custom Lambda functions to interact with the RDS API for rotation is highly complex and introduces unnecessary operational overhead compared to the managed solution provided by Secrets Manager.
  選項 D： 這種方法是重新造輪子。與 Secrets Manager 提供的託管解決方案相比，使用 DynamoDB 儲存機密並編寫自訂 Lambda 函數與 RDS API 互動以進行輪換非常複雜，並會引入不必要的營運負擔。
  

A. Create an Amazon Cognito identity pool to generate secure Amazon S3 access tokens for users when they successfully log in.
A. 建立一個 Amazon Cognito Identity Pool，以便在使用者成功登入時為其生成安全的 Amazon S3 存取權杖 (tokens)。
C. Create an Amazon S3 VPC endpoint in the same VPC where the company hosts the application.
C. 在託管應用程式的同一個 VPC 中建立一個 Amazon S3 VPC endpoint。
Why:
為什麼：

• Option A (Authorization): Amazon Cognito User Pools are used for authentication (verifying identity). To authorize access to AWS services like S3, you need an Amazon Cognito Identity Pool, which exchanges the user pool tokens for temporary AWS credentials (IAM roles) that have permissions to write to S3.
  選項 A (授權)： Amazon Cognito User Pool 用於驗證（確認身分）。若要授權存取 S3 等 AWS 服務，您需要一個 Amazon Cognito Identity Pool，它會將 User Pool 代幣交換為具有寫入 S3 權限的臨時 AWS 憑證 (IAM 角色)。
  
• Option C (Network Security): The application is hosted in a private subnet, meaning it has no direct internet access. A VPC Endpoint for Amazon S3 (Gateway Endpoint) allows the application to connect directly to S3 over the AWS private network without traversing the public internet or requiring a NAT Gateway. This is the most secure and performant method for this architecture.
  選項 C (網路安全)： 應用程式託管在私有子網中，這意指它沒有直接的網際網路存取權限。Amazon S3 的 VPC 端點 (Gateway Endpoint) 允許應用程式透過 AWS 私有網路直接連線到 S3，無需經過公用網際網路或需要 NAT Gateway。對於此架構而言，這是最安全且效能最高的方法。
  Why not others:
  為什麼不是其他選項：
  
• Option B: Cognito User Pools alone issue OIDC/JWT tokens (ID and Access tokens) which are used to authenticate with the application or API Gateway, but they are not valid AWS credentials (Access Key/Secret Key) required to make API calls directly to the S3 service.
  選項 B： 僅 Cognito User Pool 會發出 OIDC/JWT 代幣（ID 和存取代幣），這些代幣用於驗證應用程式或 API Gateway，但它們不是直接呼叫 S3 服務 API 所需的有效 AWS 憑證（存取金鑰/秘密金鑰）。
  
• Option D: A NAT Gateway would allow the application to access S3 via the public internet, which is less secure than a private endpoint. Furthermore, S3 bucket policies cannot validate that a request was “initiated from Amazon Cognito” in the way described; authorization is done via the credentials used to sign the request.
  選項 D： NAT Gateway 將允許應用程式透過公用網際網路存取 S3，這比私有端點更不安全。此外，S3 bucket 策略無法以所描述的方式驗證請求是否「由 Amazon Cognito 發起」；授權是透過用於簽署請求的憑證來完成的。
  
• Option E: Since the application is mediating the upload (or the user is uploading using credentials vending by the app), and the app is in a private subnet using a VPC endpoint, the source IP seen by S3 would be the private IP of the VPC Endpoint (or NAT Gateway if used). Restricting to users’ public IP addresses would fail if the application is the uploader, or would be brittle if users have dynamic IPs.
  選項 E： 由於應用程式正在調解上傳（或使用者使用應用程式提供的憑證進行上傳），且應用程式位於使用 VPC 端點的私有子網中，因此 S3 看到的來源 IP 將是 VPC 端點的私有 IP（如果使用 NAT Gateway，則為 NAT Gateway 的 IP）。如果應用程式是上傳者，限制為使用者的公用 IP 位址將會失敗；如果使用者擁有動態 IP，這種做法也會很脆弱。
  

D. Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets.
D. 訂閱 RDS 事件通知，並將資料傳送到一個 Amazon Simple Notification Service (Amazon SNS) 主題，該主題再扇出 (fan out) 到多個 Amazon Simple Queue Service (Amazon SQS) 佇列。使用 AWS Lambda 函數來更新目標。
Why: 為什麼：

• Fanout Pattern: This scenario requires sending the same data (sold listing) to multiple target systems. The standard AWS pattern for one-to-many messaging is using Amazon SNS to “fan out” messages to multiple Amazon SQS queues. Each target system can then process its own queue independently and reliably using Lambda or other consumers. This decouples the systems and ensures that if one consumer fails, it doesn’t affect others.
  扇出模式 (Fanout Pattern)： 此情境需要將相同的資料（已售出的清單）傳送到多個目標系統。AWS 針對一對多訊息傳遞的標準模式是使用 Amazon SNS 將訊息「扇出」到多個 Amazon SQS 佇列。每個目標系統隨後可以使用 Lambda 或其他取用者獨立且可靠地處理自己的佇列。這解耦了系統，並確保如果一個取用者失敗，它不會影響其他取用者。
  Why not others: 為什麼不是其他選項：
  
• Option A & B: Sending to a single SQS queue (whether Standard or FIFO) is a point-to-point pattern. It is designed for a single consumer (or load-balanced consumers) to process a message once. It does not naturally support broadcasting the same message to multiple different downstream systems unless you build complex application logic to duplicate messages.
  選項 A & B： 傳送到單個 SQS 佇列（無論是標準或 FIFO）是一種點對點模式。它設計用於讓單個取用者（或負載平衡的取用者）處理一次訊息。除非您建立複雜的應用程式邏輯來複製訊息，否則它本身並不支援將相同的訊息廣播到多個不同的下游系統。
  
• Option C: The order is reversed and technically invalid for fanout. You don’t fan out from SQS to SNS. You fan out from SNS to SQS. SQS is a queue (pull-based), while SNS is a pub/sub topic (push-based).
  選項 C： 順序顛倒了，且在技術上對扇出而言是無效的。您不會從 SQS 扇出到 SNS。您是從 SNS 扇出到 SQS。SQS 是一個佇列（基於拉取），而 SNS 是一個發布/訂閱主題（基於推送）。
  

B. Place the JSON documents in an Amazon S3 bucket. Create an AWS Lambda function that runs the Python code to process the documents as they arrive in the S3 bucket. Store the results in an Amazon Aurora DB cluster.
B. 將 JSON 文件放置在 Amazon S3 bucket 中。建立一個 AWS Lambda 函數，在文件到達 S3 bucket 時執行 Python 程式碼以處理文件。將結果儲存在 Amazon Aurora DB 叢集中。
Why: 為什麼：

• Serverless & Operational Overhead: The requirement specifically asks to “maximize scalability” and “minimize operational overhead”. AWS Lambda is serverless, meaning no server management, patching, or scaling configuration is required by the user. It scales automatically to handle thousands of executions per day. S3 triggers Lambda natively. Amazon Aurora Serverless (or even Provisioned) provides a managed, high-performance database. This combination offers the lowest operational overhead.
  無伺服器與營運負擔： 需求特別要求「最大化擴展性」並「最小化營運負擔」。AWS Lambda 是無伺服器的，意味著使用者無需進行伺服器管理、修補或擴展設定。它會自動擴展以處理每天數千次的執行。S3 原生觸發 Lambda。Amazon Aurora Serverless（甚至 Provisioned）提供了託管的高效能資料庫。這種組合提供了最低的營運負擔。
  Why not others: 為什麼不是其他選項：
  
• Option A, C, D: All these options involve managing EC2 instances (either directly or via ECS EC2 launch type). EC2 requires OS patching, scaling group configuration, and ongoing management, which represents significantly higher operational overhead compared to Lambda. EBS Multi-Attach (Option C) is a complex solution for shared storage and not suitable for this simple processing pattern.
  選項 A, C, D： 所有這些選項都涉及管理 EC2 執行個體（直接管理或透過 ECS EC2 啟動類型）。EC2 需要作業系統修補、擴展群組設定和持續管理，與 Lambda 相比，這代表了明顯更高的營運負擔。EBS Multi-Attach（選項 C）是針對共用儲存的複雜解決方案，不適合此簡單的處理模式。
  

A. Edit the job to use job bookmarks.
A. 編輯作業以使用作業書籤 (job bookmarks)。
Why: 為什麼：

• Job Bookmarks: AWS Glue Job Bookmarks track data that has already been processed during a previous run of an ETL job. By enabling this feature, Glue persists state information and will only process new data (incremental loading) in subsequent runs, preventing the reprocessing of old files.
  作業書籤 (Job Bookmarks)： AWS Glue 作業書籤會追蹤在先前的 ETL 作業執行期間已處理過的資料。透過啟用此功能，Glue 會保留狀態資訊，並且在後續執行中僅處理新資料（增量載入），從而防止重新處理舊檔案。
  Why not others: 為什麼不是其他選項：
  
• Option B: Deleting source data is a destructive operation and is generally not a valid strategy for tracking processing state. It prevents any future audit or re-processing if needed.
  選項 B： 刪除來源資料是一種破壞性操作，通常不是追蹤處理狀態的有效策略。如果需要，它會阻止任何未來的稽核或重新處理。
  
• Option C: Reducing the number of workers to 1 only impacts the performance/concurrency of the job; it has no effect on what data is selected for processing.
  選項 C： 將工作者數量減少到 1 只會影響作業的效能/並行性；它對選擇什麼資料進行處理沒有影響。
  
• Option D: FindMatches is a Machine Learning transform used for deduplicating records (finding similar records that refer to the same entity) within a dataset, not for tracking file processing state.
  選項 D： FindMatches 是一種機器學習轉換，用於在資料集內刪除重複記錄（尋找指向同一實體的相似記錄），而不是用於追蹤檔案處理狀態。
  

C. Use AWS Lambda to process the photos. Store the photos in Amazon S3. Retain DynamoDB to store the metadata.
C. 使用 AWS Lambda 處理照片。將照片儲存在 Amazon S3 中。保留 DynamoDB 以儲存中繼資料。
Why: 為什麼：

• Serverless Scaling: The requirement mentions “concurrent users vary significantly”. AWS Lambda provides automatic scaling that matches demand exactly, handling peaks without pre-provisioning. Amazon S3 is the ideal scalable object storage for “photos”, while DynamoDB is perfect for “metadata”. This architecture is fully serverless and elastic.
  無伺服器擴展： 需求提到「並行使用者數量變化顯著」。AWS Lambda 提供與需求完全匹配的自動擴展，無需預先配置即可處理峰值。Amazon S3 是用於「照片」的理想可擴展物件儲存，而 DynamoDB 非常適合「中繼資料」。此架構是完全無伺服器且彈性的。
  Why not others: 為什麼不是其他選項：
  
• Option A: DynamoDB is a NoSQL database designed for small, structured data (metadata). It is not designed or cost-effective for storing large binary objects (BLOBs) like photos directly. S3 is the correct service for images.
  選項 A： DynamoDB 是一種 NoSQL 資料庫，專為小型結構化資料（中繼資料）而設計。直接儲存照片等大型二進位物件 (BLOB) 並非其設計初衷，也不具成本效益。S3 是用於影像的正確服務。
  
• Option B: Amazon Kinesis Data Firehose is for streaming data delivery (e.g., logs, clickstreams) to destinations like S3 or Redshift. It is not an interactive image processing service for a user-facing application.
  選項 B： Amazon Kinesis Data Firehose 用於將串流資料（例如日誌、點擊流）傳送到 S3 或 Redshift 等目的地。它不是用於使用者面向應用程式的互動式影像處理服務。
  
• Option D: “Increase to three” is a static vertical/horizontal scaling approach that does not adapt automatically to “significant variations” in traffic. It might be over-provisioned at night and under-provisioned during peaks. Using EBS for shared photo storage among instances is also less scalable and harder to manage than S3.
  選項 D： 「增加到三個」是一種靜態的垂直/水平擴展方法，無法自動適應流量的「顯著變化」。它可能在夜間配置過度，而在峰值期間配置不足。與 S3 相比，使用 EBS 在執行個體之間共用照片儲存的可擴展性較差且更難管理。