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.

• ✗

  Use SSE-S3 with default encryption.

  Why it's wrong here

  SSE-S3 with default encryption encrypts objects with a single AWS-managed key that Amazon S3 fully controls, so there is no way to split key custodianship between your security team and the service. Because the key is not visible or configurable by you, CloudTrail cannot log key usage events for each GetObject/PutObject call, leaving no audit trail of when your sensitive data was decrypted. Additionally, SSE-S3 offers no support for key rotation scheduling or the ability to deny access by disabling a key, making it unsuitable for compliance-driven migrations of sensitive data.

• ✗

  Use SSE-C and store the keys in AWS Secrets Manager.

  Why it's wrong here

  SSE-C requires you to supply the encryption key in each S3 API request and, although S3 performs the encryption, it does not log which key was used to decrypt an object, so even if the keys are stored in AWS Secrets Manager, you get no key-usage audit trail for S3 accesses. Secrets Manager can manage and rotate the keys, but SSE-C has no built-in integration with CloudTrail to record key identifiers or access patterns, which is typically mandatory for sensitive data audits. Moreover, you must manage key material delivery in every SDK call, and if the secret is rotated, all existing S3 objects encrypted with the old key would need re-encryption, creating serious operational risk.

• ✓

  Use SSE-KMS with a customer-managed key and enable CloudTrail for KMS.

  Why this is correct

  SSE-KMS with a customer-managed key gives you independent control over the CMK, including the ability to set key policies, grant and revoke permissions, and force rotation. With CloudTrail for KMS enabled, every Decrypt, GenerateDataKey, and ReEncrypt request against that key is recorded with the user, role, and principal ARN, directly tying each S3 object access to an auditable event. Customer-managed keys also let you align the key with your own governance model, and because the key is in KMS, you can use key policies to enforce conditions (such as VPC endpoints or MFA) and can respond to a breach by disabling the key to instantly block all future decrypt operations.

• ✗

  Use AWS CloudHSM to generate and store keys, and use Amazon S3 with SSE-KMS.

  Why it's wrong here

  AWS CloudHSM generates and stores keys in hardware, but S3 itself cannot use those keys directly for SSE-KMS, so you would still need to generate a KMS key or import the HSM key into KMS, making CloudHSM an unnecessary intermediate layer. Even if you integrate CloudHSM with KMS via a custom key store, you are still using SSE-KMS under the hood, and the resulting audit trail is fragmented between CloudHSM logs and CloudTrail KMS events rather than being centralized. Furthermore, CloudHSM adds significant operational overhead (managing HSM clusters, backups, and high availability) without improving the S3 encryption workflow, so it is not a simpler or more secure replacement for the native SSE-KMS approach.

Go deeper

Related to this question