SCS-C02 Security Logging and Monitoring 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.

• ✗

  Create a new CloudTrail trail for each account and configure S3 bucket policies to allow cross-account access.

  Why it's wrong here

  Creating per-account trails with cross-account S3 bucket policies does not prevent an account from disabling its own CloudTrail, because each account retains full control over its trail configuration and can delete or stop logging independently. This approach is tempting because it centralises log storage into a single bucket, which is a common pattern for aggregating logs across accounts. It would be correct if the goal were only to consolidate logs for analysis, without the immutability and prevention-of-disabling requirements specified in the stem.

• ✗

  Enable S3 MFA Delete on each account's log bucket and require MFA for IAM users.

  Why it's wrong here

  Enabling S3 MFA Delete on the log bucket requires multi-factor authentication to delete or overwrite objects, but it does nothing to protect the CloudTrail trail configuration itself. A user with permissions such as cloudtrail:StopLogging, cloudtrail:DeleteTrail, or cloudtrail:UpdateTrail can still disable or modify the trail, thereby stopping the flow of logs. Requiring MFA for IAM users is a standard authentication hardening measure, but it does not restrict a privileged user from performing the CloudTrail administrative actions that would compromise log delivery. This approach fails to address the core requirement of preventing the trail from being disabled.

• ✗

  Use CloudWatch Logs to aggregate logs and set a retention policy of 10 years.

  Why it's wrong here

  Using CloudWatch Logs to aggregate CloudTrail logs and setting a 10-year retention policy merely stores the logs in a managed service that does not offer an immutable, tamper-evident storage class. Any IAM principal with logs:DeleteLogGroup, logs:DeleteLogStream, or logs:PutRetentionPolicy permissions can alter or delete the log data, and a compromised account could simply stop delivering CloudTrail logs to CloudWatch Logs in the first place. Unlike an S3 bucket protected by a restrictive bucket policy and versioning, CloudWatch Logs provides no native mechanism to prevent deletion of log groups or log streams, and it also doesn't prevent an attacker from disabling the CloudTrail trail. Thus, this option fails both at protecting log integrity and at ensuring continuous logging.

• ✓

  Apply an SCP to deny cloudtrail:StopLogging and cloudtrail:DeleteTrail, and create an organization trail that delivers logs to a central S3 bucket with a bucket policy that prevents deletion.

  Why this is correct

  Applying an SCP to the organization root or to all member accounts that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail ensures that even an IAM admin or the root user in a member account cannot disable or delete the trail. An organization trail automatically delivers CloudTrail logs from every account to a designated central S3 bucket, and the bucket policy can explicitly Deny actions such as s3:DeleteBucket, s3:DeleteBucketPolicy, and s3:DeleteObject for all principals, making the log data tamper-proof. This combination provides a centralized, immutable audit record while removing the ability of individual account administrators to interfere with logging. It directly satisfies the requirement to prevent disabling and to protect the integrity of the logs.

Go deeper

Related to this question