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.

• ✗

  Enable S3 server access logging on the bucket in account B and check the logs.

  Why it's wrong here

  S3 server access logging in account B captures object-level request logs, but these logs are best-effort plaintext files delivered to a target bucket. They include source IP, bucket name, operation, and a requester field, but that requester field typically shows the external account's canonical user ID rather than the full IAM user ARN. Without the specific IAM user or role ARN, you cannot identify which principal in account A performed the cross-account access. Additionally, server access logs are not enabled by default and can be delayed, making them a poor choice for this forensic investigation.

• ✓

  Enable CloudTrail in account B and check the S3 event history for the bucket.

  Why this is correct

  CloudTrail in account B, the bucket owner account, is the authoritative audit trail for S3 API calls made against the bucket. When you enable CloudTrail with S3 data events for the bucket, every cross-account request from account A generates an event that includes the full userIdentity ARN of the calling IAM user or role. The event record also contains the source IP address, the event name (e.g., GetObject), and the bucket ARN, allowing you to trace exactly which IAM identity performed the suspected exfiltration. This is the only option that gives you the complete identity-level detail required for the investigation.

• ✗

  Enable CloudTrail in account A and check the S3 event history.

  Why it's wrong here

  CloudTrail in the accessing account (account A) does not record S3 data events for a bucket owned by a different account. The S3 service generates the CloudTrail event in the account that owns the bucket because access is authenticated and authorized against that bucket's resource policy. Account A's CloudTrail will only show the IAM calls that granted permissions, but not the actual GetObject/PutObject operations on account B's bucket. Even if the trail is configured for data events, cross-account data events are delivered to the resource owner's trail.

• ✗

  Enable CloudWatch Logs in account A and check the S3 access logs.

  Why it's wrong here

  CloudWatch Logs is a managed log aggregation and monitoring service, not a source for S3 access logs. S3 does not natively push access logs to CloudWatch Logs; you would need to enable S3 server access logging and then build a pipeline (e.g., Lambda, Kinesis, or CloudWatch Logs agent) to ingest those logs. More importantly, even if the server access logs were in CloudWatch Logs, they still lack the IAM user ARN and would not identify the specific principal in account A. Enabling CloudWatch Logs in account A also does not capture the cross-account request, since the logs are generated by account B's bucket.

Go deeper

Related to this question