SCS-C02 Data Protection 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.

• ✗

  Amazon S3 server access logs

  Why it's wrong here

  These logs record object-level requests made directly to S3 (e.g., GET, PUT, DELETE, LIST) including requester IP, bucket name, key, operation, and response status, but they capture only S3 data-plane activity. They do not capture KMS API calls such as Decrypt because KMS operations occur as a separate control-plane call to the KMS service, not as part of the S3 request itself. Thus they cannot show who or what invoked the KMS Decrypt action when S3 retrieves an SSE-KMS encrypted object.

• ✗

  Amazon VPC Flow Logs

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic to and from elastic network interfaces, not API-level actions such as KMS Decrypt calls. They are tempting because they log network-level communication, which could appear relevant for auditing S3 access, but they lack the ability to record AWS KMS API operations. VPC Flow Logs would be correct only for diagnosing network connectivity issues or inspecting allowed/denied traffic at the subnet or instance level.

• ✓

  AWS CloudTrail

  Why this is correct

  AWS CloudTrail is the only service listed that natively records the KMS API calls, including the Decrypt operation used when S3 fetches an SSE-KMS-encrypted object. Each KMS event in CloudTrail includes the key ARN, the IAM identity of the caller, the source IP address, and the encryption context, which together provide the complete audit trail required for security investigations. By default, KMS data-plane events like Decrypt are captured in the CloudTrail event history, and you can optionally set up a trail to deliver them to an S3 bucket or CloudWatch Logs for long-term retention.

• ✗

  AWS CloudWatch Logs

  Why it's wrong here

  CloudWatch Logs is a log storage, monitoring, and alerting service; it has no built-in mechanism to capture KMS API calls on its own. The only way KMS Decrypt events appear in CloudWatch Logs is if you first configure AWS CloudTrail to deliver its event logs to a CloudWatch Logs log group. Thus, while CloudWatch Logs may be part of a complete auditing pipeline, it is not the service responsible for recording the Decrypt action, making it an incorrect answer for what logs the KMS API calls.

Go deeper

Related to this question