SAA-C03 Design Secure Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Enable CloudTrail management events and configure an EventBridge rule to send notifications for PutBucketPolicy and PutKeyPolicy API calls, while also delivering CloudTrail logs to a dedicated S3 bucket for retention.

  Why this is correct

  CloudTrail management events capture control-plane API calls, including PutBucketPolicy and PutKeyPolicy, recording the request parameters, principal, source IP, and timestamp. An EventBridge rule can match these event names and invoke an SNS topic or Lambda function to notify the security team within seconds of the call. Delivering the raw CloudTrail logs to a dedicated S3 bucket creates a tamper-evident, centrally retained audit trail for post-incident analysis and compliance reporting, whereas simply watching resource state via Config would not provide the same event-level specificity.

• ✗

  Rely on AWS Config resource snapshots only; use the snapshots to infer policy changes and generate alerts from the daily compliance summary reports.

  Why it's wrong here

  AWS Config resource snapshots are point-in-time configuration states, and comparing them over time can reveal that a policy changed, but the daily compliance summary report is not an event-driven alert and introduces a delay that an attacker could exploit by reverting the change before detection. Moreover, snapshots lack the API-call metadata (identity, source IP, API name) needed for a meaningful security investigation, and they cannot show the exact moment of change. Relying solely on Config snapshots and daily reports is therefore both too slow and too coarse for real-time security alerting.

• ✗

  Enable S3 access logging on the affected buckets only; treat these logs as sufficient evidence for KMS key policy modifications.

  Why it's wrong here

  S3 server access logs are data-plane records that capture requests like GET, PUT, LIST, and DELETE on objects and buckets, but they do not include KMS control-plane operations such as PutKeyPolicy, which are API calls made to the AWS KMS service. Those KMS policy changes are recorded in CloudTrail, not in S3 access logs, so these logs cannot serve as sufficient evidence of key policy modifications. Additionally, S3 access logs are delivered on a best-effort basis with potential delays and might not capture all events, making them unsuitable for reliable security alerting.

• ✗

  Turn on CloudWatch Logs for the S3 bucket and KMS key; alert on any log line containing the word 'policy' to detect changes.

  Why it's wrong here

  CloudWatch Logs for an S3 bucket and KMS key does not automatically ingest API policy-change events; you would still need CloudTrail to generate those events and a subscription filter to send them into CloudWatch Logs. Even if logs were present, searching for the literal word 'policy' is a brittle heuristic that would miss events using different service-specific identifiers or might trigger on unrelated text, producing both false negatives and false positives. A structured event-driven approach with EventBridge matching the exact PutBucketPolicy and PutKeyPolicy event names is far more precise than log scraping.

Go deeper

Related to this question