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.

• ✗

  The trail is not logging data events.

  Why it's wrong here

  Data events are not captured by default, but CloudTrail logs management events automatically for every trail. If the trail is not configured to record data events, you simply won't see S3 object-level API calls in the delivered logs; this does not block CloudTrail from writing the management event log files it is generating. Because the delivery failure affects all event categories, including management events, the absence of data-event logging is not the root cause.

• ✓

  The S3 bucket uses SSE-KMS encryption and the trail does not have permission to use the KMS key.

  Why this is correct

  When an S3 bucket uses SSE-KMS encryption, CloudTrail must have permission to call the KMS key to encrypt each delivered log file. Specifically, CloudTrail needs kms:Decrypt and kms:GenerateDataKey actions in the key policy. If those permissions are missing, CloudTrail cannot write the encrypted log objects and stops delivering logs, producing a delivery failure shown on the trail configuration page.

• ✗

  The S3 bucket is in a different AWS account.

  Why it's wrong here

  CloudTrail is designed to deliver logs to an S3 bucket in another AWS account as long as the destination bucket has a bucket policy that grants CloudTrail's delivery role s3:PutObject (and optionally s3:GetBucketAcl). Cross-account delivery is a common architecture for centralizing logs, so the bucket being in a different account is not an inherent blocker. If the cross-account permissions were misconfigured, that could cause a failure, but the symptom described here is most consistent with an SSE-KMS permission problem, not a cross-account one.

• ✗

  The bucket policy is missing a Deny statement.

  Why it's wrong here

  The bucket policy for a CloudTrail destination should contain an Allow statement that grants CloudTrail permission to write objects (s3:PutObject) to the bucket. The absence of a Deny statement cannot cause log delivery to fail because access is denied by default unless an Allow explicitly grants it; a missing Allow would be the problem. Adding a Deny might block delivery, but lacking one does not prevent CloudTrail from writing.

Go deeper

Related to this question