SCS-C02 Security Logging and Monitoring Practice Question

A security engineer notices that CloudTrail logs for a production account are not being delivered to the S3 bucket. The bucket policy allows CloudTrail to write objects. What is the MOST likely cause?

⚠ Common exam trap

A common mix-up: candidates assume the only permission needed for CloudTrail to deliver logs is `s3:PutObject`, overlooking the prerequisite `s3:GetBucketAcl` permission that CloudTrail requires to validate the bucket policy before any log delivery can start.

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 bucket policy does not grant s3:GetBucketAcl to CloudTrail.

CloudTrail requires the `s3:GetBucketAcl` permission on the destination S3 bucket to verify that the bucket policy grants CloudTrail the necessary write access. Without this permission, CloudTrail cannot confirm its ability to deliver logs, even if the bucket policy explicitly allows `s3:PutObject`. This is a prerequisite check performed by CloudTrail before any log delivery occurs.

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 S3 bucket does not have versioning enabled.
Why it's wrong here
For a CloudTrail destination bucket, versioning is an optional safeguard, not a delivery requirement. CloudTrail constructs a new, unique object name for each log file, so the absence of versioning does not matter; S3 simply overwrites an object if the same key is uploaded. When logs are missing, lack of versioning cannot be the root cause because CloudTrail can write successfully to a non-versioned bucket and versioning only helps you recover overwritten or deleted logs after the fact.
✗
The S3 bucket uses SSE-KMS encryption.
Why it's wrong here
Using SSE-KMS on the destination bucket does not block CloudTrail delivery; CloudTrail fully supports KMS-managed keys as long as the trail's S3 bucket policy and the KMS key policy allow the required actions (for example, s3:PutObject and kms:GenerateDataKey). If the KMS key permissions were misconfigured, the failure would occur at encryption time, but the scenario points to a static bucket policy gap. An S3 bucket with SSE-KMS is therefore not intrinsically wrong; it would only be a factor if the key policy were missing the CloudTrail and S3 service permissions.
✓
The bucket policy does not grant s3:GetBucketAcl to CloudTrail.
Why this is correct
CloudTrail does not merely write objects; it first calls s3:GetBucketAcl to confirm it is allowed to deliver to that bucket and to verify bucket ownership. A bucket policy that omits s3:GetBucketAcl causes CloudTrail's initial validation to fail, and delivery is not set up even though the s3:PutObject action may be allowed. This access check is distinct from an S3 write permission, which is why the correct fix is to add an ACL-read allowance, not just PutObject.
✗
The S3 bucket contains existing objects before CloudTrail delivery started.
Why it's wrong here
A pre-existing object does not create a conflict with CloudTrail as long as its key does not collide with a future CloudTrail log file. CloudTrail's log file names use a path and filename that include an event-time timestamp and a random hash, making collisions with pre-existing data effectively impossible. If delivery had never started, the bucket would appear empty of CloudTrail logs even if it has unrelated objects; those objects do not block CloudTrail's ability to create new objects.

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

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question