SCS-C02 Security Logging and Monitoring Practice Question

A company wants to ensure that all API calls made to their AWS account are logged and immutable. They have enabled AWS CloudTrail and are delivering logs to an S3 bucket. The security team requires that logs cannot be deleted or modified by anyone, including the root user. What should they do?

⚠ Common exam trap

SCS-C02 often tests the confusion between MFA Delete, versioning, and Object Lock — candidates must know that only Object Lock Compliance mode is truly immutable against root, while MFA Delete and bucket policies are not.

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

✓

Enable S3 Object Lock with Compliance retention mode on the bucket.

S3 Object Lock in Compliance mode prevents any principal — including the root user and AWS itself — from deleting or overwriting an object version until its retention period expires. This is the only option that provides true WORM (write once, read many) immutability for CloudTrail logs. It satisfies the requirement that logs cannot be deleted or modified by anyone, including root.

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 Object Lock with Compliance retention mode on the bucket.
Why this is correct
S3 Object Lock in Compliance mode enforces a write-once-read-many retention period that no principal, including the AWS account root user, can shorten or bypass, so CloudTrail log objects cannot be deleted or altered for the mandated duration.
✗
Enable MFA Delete on the S3 bucket.
Why it's wrong here
MFA Delete only adds a second authentication factor for deleting object versions or suspending versioning; it does not prevent a root user who controls the MFA device from deleting logs. It is the right choice for guarding versioned objects against accidental or compromised-credential deletion.
✗
Enable S3 Versioning on the bucket.
Why it's wrong here
Versioning preserves prior object versions but does not prevent deletion or overwriting; a principal with s3:DeleteObject can still remove objects or add delete markers. It is tempting because versioning underpins retention and recovery, and would be correct when the requirement is recoverability rather than enforced immutability.
✗
Add a bucket policy that denies s3:DeleteObject for all principals.
Why it's wrong here
A bucket policy denying s3:DeleteObject blocks deletion but leaves s3:PutObject open, so objects can still be overwritten and altered. It is tempting because explicit deny policies are the usual mechanism for restricting bucket actions, and would be correct if the requirement were only preventing deletion by specific principals.

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