SAA-C03 Design Secure Architectures Practice Question

Exhibit

{
  "cloudtrail_samples": [
    {
      "account": "111122223333",
      "eventName": "PutBucketPolicy",
      "eventSource": "s3.amazonaws.com",
      "errorCode": null
    },
    {
      "account": "444455556666",
      "eventName": "PutKeyPolicy",
      "eventSource": "kms.amazonaws.com",
      "errorCode": "AccessDenied"
    }
  ],
  "current_controls": {
    "member_accounts": 12,
    "central_security_account": true,
    "cloudwatch_logs": "not enabled for CloudTrail",
    "eventbridge_rules": "none"
  }
}

Based on the exhibit, the security team wants centralized detection and alerting for both successful and failed attempts to change S3 bucket policies and KMS key policies across multiple accounts. Which approach best meets the requirement?

⚠ Common exam trap

Test-takers frequently confuse S3 server access logging (which logs object-level access) with CloudTrail (which logs management API calls), or assume AWS Config automatically records all API calls, when in fact Config only tracks configuration changes and not failed API attempts.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an organization CloudTrail trail for management events and add EventBridge rules in the security account to alert on PutBucketPolicy and PutKeyPolicy events, including failed calls.

An organization CloudTrail trail captures management events (including PutBucketPolicy and PutKeyPolicy) across all accounts in the organization, and EventBridge rules in the security account can filter for both successful and failed API calls (using the `errorCode` field) to trigger centralized alerts. This provides the required centralized detection and alerting for policy changes across multiple accounts.

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 S3 server access logging on each bucket and archive the logs in the security account.
Why it's wrong here
S3 server access logging records object-level requests against individual buckets, such as GETs and PUTs, not control-plane operations like changes to bucket policies or KMS key policies. Because the logs are written to a destination bucket in discrete object form, they lack the centralized, streamable event structure needed to trigger real-time alerting, and they would require separate log delivery configuration for every bucket. Archiving these logs merely stores historical access data; it does not provide a unified API activity audit trail across all accounts or detect failed PutBucketPolicy/PutKeyPolicy attempts.
✗
Use AWS Config rules only, because Config records every successful and failed API call automatically.
Why it's wrong here
AWS Config records configuration state changes and evaluates resources against rules, but it does not automatically record every API call—and it certainly does not capture failed calls. Config's configuration history reflects the result of successful changes only, and failed API attempts never alter resource state, so they would be invisible to Config. While Config rules can react to configuration drift after a policy change succeeds, they cannot alert on the original PutBucketPolicy or PutKeyPolicy request, including denied attempts, which is why Config alone is insufficient for comprehensive security-event monitoring.
✓
Create an organization CloudTrail trail for management events and add EventBridge rules in the security account to alert on PutBucketPolicy and PutKeyPolicy events, including failed calls.
Why this is correct
An organization CloudTrail trail delivers read/write management events from all accounts in the AWS Organization to a single S3 bucket (and optionally CloudWatch Logs) in the security account, creating a centralized audit trail. CloudTrail records both successful and failed API calls, including PutBucketPolicy and PutKeyPolicy, with event details such as caller identity, source IP, and request parameters. By adding Amazon EventBridge rules that match these specific event names—including `errorCode` fields for failed calls—the security team can trigger near-real-time alerts or automated remediation, making this the most direct and complete solution.
✗
Enable GuardDuty in every account and use its findings as the main source for policy change notifications.
Why it's wrong here
GuardDuty is a threat detection service that analyzes VPC DNS logs, CloudTrail management events, and S3 data events for suspicious activity, but it is not purpose-built to alert on every policy change occurrence. GuardDuty findings focus on anomalies like unusual API calls from a compromised credential or privilege escalation patterns, not a guaranteed, comprehensive record of every PutBucketPolicy or PutKeyPolicy event. Relying on GuardDuty as the primary source for policy change notifications would miss routine changes that do not match its threat-detection heuristics and does not provide the deterministic, event-level audit trail needed for centralized security monitoring.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question