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.

• ✗

  Apply an S3 bucket policy to the RDS automated backup bucket

  Why it's wrong here

  Applying an S3 bucket policy to the RDS automated backup bucket will not control KMS key usage. RDS automated backups are stored in S3, but the bucket is managed by AWS and S3 bucket policies only govern access to the bucket and its objects; they have no authority to grant or deny kms:Encrypt or kms:Decrypt on your customer-managed KMS key. To restrict which principals may use the KMS key, you must modify the KMS key policy or the relevant IAM policies.

• ✗

  Enable automatic key rotation

  Why it's wrong here

  Enabling automatic key rotation is an operational security measure, not an authorization control. Rotating a customer-managed KMS key creates new backing key material while keeping the same key ARN, and the key policy and all IAM permissions remain unchanged, so any role that already has kms:Encrypt or kms:Decrypt access retains that access after rotation. Rotation limits the cryptographic impact of a compromised key, but it does nothing to restrict who can call KMS APIs.

• ✓

  Enable AWS CloudTrail to log KMS API calls

  Why this is correct

  Enabling AWS CloudTrail to log KMS API calls provides a detailed audit trail of every kms:Encrypt, kms:Decrypt, GenerateDataKey, and other KMS operation, including the IAM principal, source IP, and request timestamp. This is a detective control that lets security engineers monitor and investigate who is using the key and when, which is the correct approach when the goal is visibility into KMS usage. CloudTrail does not prevent or allow operations, so it complements, rather than replaces, access-control policies.

• ✓

  Modify the key policy to grant kms:Encrypt and kms:Decrypt only to the required IAM roles

  Why this is correct

  Modifying the key policy to grant kms:Encrypt and kms:Decrypt only to the required IAM roles is the direct and least-privileged way to control access to the CMK. A KMS key policy is a resource-based policy that can explicitly name IAM roles as Principals, and KMS requires that a request be allowed by both the key policy and the caller's IAM policy (if the principal is in the same account). This ensures only the designated RDS-related roles can use the key, effectively restricting encryption and decryption operations to the intended workload.

• ✗

  Create a cross-account key policy to allow all IAM roles in the account

  Why it's wrong here

  Creating a cross-account key policy to allow all IAM roles in the account is unnecessary and overly permissive for a single-account scenario. Cross-account key policies are designed for granting access to principals in other AWS accounts, and using one to grant every IAM role in the current account violates least privilege because roles unrelated to RDS would also be allowed to use the key. The correct approach is to name only the specific IAM roles that need to perform kms:Encrypt and kms:Decrypt as principals in the key policy.

Go deeper

Related to this question