SOA-C02 Security and Compliance 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 AWS CloudTrail to log KMS API calls.

  Why this is correct

  AWS CloudTrail is the authoritative audit service for KMS because every KMS API operation—including Encrypt, Decrypt, GenerateDataKey, and CreateKey—is captured as an event containing the principal, source IP, request parameters, and response. These events are delivered to an S3 bucket as JSON files, providing a durable, tamper-evident record that supports compliance and security investigations. Enabling a trail that records management events is sufficient for KMS, as KMS data-plane calls are automatically logged as management events.

• ✗

  Enable Amazon S3 server access logs to track KMS operations.

  Why it's wrong here

  Amazon S3 server access logs capture HTTP requests made to S3 buckets, such as object GETs, PUTs, and bucket-level operations; they do not capture KMS service API calls because KMS operations are executed via the KMS endpoint, not the S3 data plane. While S3 may log an object's SSE-KMS encryption status, those logs only show that encryption occurred, not which AWS principal called KMS with what parameters. Thus S3 logs cannot provide the detailed API-level audit trail required for KMS key usage.

• ✗

  Use IAM Access Analyzer to review KMS key policies.

  Why it's wrong here

  IAM Access Analyzer is a policy-analysis tool that scans resource-based policies to detect resources shared with external principals; it does not record or monitor real-time API activity. When applied to KMS keys, it can reveal whether a key policy permits cross-account access, but it cannot tell you when or how often the key was used, nor by which IAM principal. Therefore it is unsuitable for auditing KMS API calls and cannot replace CloudTrail logs.

• ✓

  Stream CloudTrail logs to Amazon CloudWatch Logs and create metric filters for KMS events.

  Why this is correct

  Streaming CloudTrail events to CloudWatch Logs is a complementary approach: it enables metric filters and alarms on specific KMS events, such as failed Decrypt attempts or calls from unexpected IP ranges. This turns static CloudTrail logs into a proactive monitoring solution, allowing near-real-time alerting and integration with incident-response workflows. It still relies on CloudTrail as the underlying source, but adds the operational value of monitoring on top of the audit trail.

• ✗

  Use AWS Config rules to monitor KMS key usage.

  Why it's wrong here

  AWS Config rules are designed to evaluate resource configurations against compliance policies, such as checking that KMS keys have rotation enabled or that key policies do not grant wildcard actions. They record configuration changes and can trigger remediation, but they do not log or track the actual cryptographic API calls that use the key. Key usage events (Encrypt, Decrypt) are not configuration items, so Config is fundamentally the wrong tool for auditing KMS operations.

Go deeper

Related to this question