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 GuardDuty

  Why it's wrong here

  Amazon GuardDuty is a machine-learning-based threat detection service that consumes sources such as VPC Flow Logs, DNS query logs, and CloudTrail management events to generate security findings. It does not create or persist its own audit record of every KMS API call; instead, it may output an alert if a pattern suggests misuse, such as a compromised principal using a key from an unusual location. Because GuardDuty findings are derived and time-framed, they lack the complete queryable event history (including actor, action, and response) that a compliance audit of KMS usage requires. Thus, while GuardDuty can complement CloudTrail, it cannot replace it as the authoritative audit log.

• ✗

  AWS Config

  Why it's wrong here

  AWS Config tracks configuration changes to resources, not API-level access attempts against a KMS key. The requirement is to audit every KMS API call—including unauthorised ones—which only AWS CloudTrail can capture by recording data-plane and control-plane events. Config is tempting because it can evaluate whether a KMS key has been rotated or has a policy allowing public access, but it cannot log a failed Decrypt request; for that compliance audit need, CloudTrail is the correct service.

• ✓

  AWS CloudTrail

  Why this is correct

  AWS CloudTrail is the only service here that natively captures every KMS API operation as an audit event, including both management-plane calls like CreateKey and PutKeyPolicy and data-plane cryptographic calls such as Encrypt, Decrypt, and GenerateDataKey when data events are enabled. Each log entry contains the requesting IAM principal, source IP, request parameters, and response elements, and even records access-denied events from failed authorization attempts, giving security teams a complete, tamper-evident trail for compliance investigations. Because CloudTrail delivers events to an S3 bucket and optionally to CloudWatch Logs, it provides the durable, centralized audit history required by regulators, whereas the other options do not capture KMS API calls directly.

• ✗

  Amazon CloudWatch Logs

  Why it's wrong here

  Amazon CloudWatch Logs is a log storage and monitoring service that only receives log records from sources that are configured to publish to it; it is not an event source that intercepts AWS KMS API calls on its own. A KMS request will never appear in CloudWatch Logs unless another service, such as a CloudTrail trail configured with a CloudWatch Logs destination, forwards it, meaning CloudWatch Logs alone cannot satisfy an audit requirement. It also does not parse or index IAM actor and KMS action fields natively, so even if logs were ingested, you would be dependent on the upstream forwarder's format and completeness. For these reasons, while CloudWatch Logs can store and alert on CloudTrail events, it is not the service that captures KMS audit events.

Go deeper

Related to this question