SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Refer to the exhibit.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-trail-bucket/AWSLogs/123456789012/*"
    }
  ]
}

Refer to the exhibit. A security engineer created this S3 bucket policy to allow CloudTrail to deliver logs from account 123456789012 to the bucket my-trail-bucket. However, CloudTrail logs are not being delivered. What is the most likely reason?

⚠ Common exam trap

The trap here is that candidates focus on the obvious s3:PutObject action and overlook the required s3:GetBucketAcl permission, which is a subtle but critical prerequisite for CloudTrail log delivery.

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

✓

The policy is missing s3:GetBucketAcl permission.

CloudTrail requires both s3:PutObject and s3:GetBucketAcl permissions on the destination S3 bucket to validate that the bucket policy grants the necessary access. Without s3:GetBucketAcl, CloudTrail cannot confirm the bucket's ACL allows log delivery, causing delivery to fail.

Answer analysis

Option-by-option breakdown

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

✗
The Principal should be the CloudTrail service principal for the specific region.
Why it's wrong here
The CloudTrail service principal is always cloudtrail.amazonaws.com, and it is not region-qualified; AWS service principals are global identifiers, not per-region. Changing the Principal to a region-specific value would not only be syntactically invalid but would also prevent CloudTrail from authenticating to the bucket. Therefore, this option is incorrect.
✗
The Action should be s3:PutObjectAcl instead of s3:PutObject.
Why it's wrong here
CloudTrail uses s3:PutObject to upload log files to the bucket; s3:PutObjectAcl is for changing an object's ACL, which CloudTrail does not perform when delivering logs. Adding PutObjectAcl would be unnecessary and irrelevant, while removing PutObject would break log delivery. Thus the action is correctly stated as s3:PutObject.
✗
The resource ARN does not include the bucket name.
Why it's wrong here
The resource ARN in the exhibit explicitly includes the bucket name, typically as arn:aws:s3:::bucket-name/AWSLogs/account-id/*, so this alleged flaw does not exist. If the bucket name were missing from the ARN, the statement would not match any objects and CloudTrail could not write logs. The actual issue lies elsewhere, namely the missing s3:GetBucketAcl permission.
✓
The policy is missing s3:GetBucketAcl permission.
Why this is correct
CloudTrail requires not only write permission via s3:PutObject but also s3:GetBucketAcl to inspect the bucket's ACL and confirm it is not publicly writable. Without this permission, CloudTrail aborts log delivery even if the bucket policy allows PutObject, which is why this option identifies the real defect. Granting both actions fixes the configuration.

Visual reference

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

SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question