CLF-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.

• ✗

  SSE-S3 (Amazon S3-managed keys)

  Why it's wrong here

  SSE-S3 uses Amazon S3-managed encryption keys, where AWS fully owns and operates the key hierarchy that encrypts your objects. While the data is encrypted at rest, you have no control over the key material, its rotation schedule, or who can access it—AWS can decrypt the data on your behalf as part of its service. This option does not satisfy the 'customer controls the encryption keys' requirement because the customer cannot set policies, disable keys, or independently audit usage through CloudTrail. It is fundamentally a turnkey AWS-managed encryption solution, not a customer-controlled one.

• ✗

  SSE-KMS with an AWS managed CMK (aws/s3)

  Why it's wrong here

  SSE-KMS with an AWS managed CMK (aws/s3) still uses AWS Key Management Service, but the CMK is created and managed entirely by AWS. You cannot edit the key policy, cannot manually rotate it, and cannot delete it—AWS controls the key lifecycle and has the authority to use it for decryption. Although some customers think any KMS key gives them control, the 'aws/s3' managed CMK is automatically shared across all AWS services and does not allow customer-defined permissions or audit visibility. This falls short because AWS, not the customer, retains independent control over the encryption key material.

• ✓

  SSE-KMS with a customer-managed CMK

  Why this is correct

  SSE-KMS with a customer-managed CMK is the only option that gives the customer direct ownership and control over the encryption key. You can define the key policy, set rotation frequency, and delete or disable the key as needed; if you delete the CMK, the S3 objects encrypted with it become permanently unreadable, even by AWS. Every call to use the key is also recorded in AWS CloudTrail, providing an independent audit trail that AWS-managed keys cannot offer. This matches the explicit requirement that the customer must control the encryption keys.

• ✗

  S3 Versioning with MFA Delete

  Why it's wrong here

  S3 Versioning with MFA Delete is about protecting object versions, not about encryption keys. Versioning retains copies of objects so you can recover from accidental overwrites or deletions, while MFA Delete adds a second authentication factor to permanently remove versions or turn off versioning. Neither feature encrypts your data nor gives you any control over encryption keys; objects remain stored in their original form—plaintext or whatever encryption you separately configured. Therefore, it fails the requirement because it addresses data durability and deletion protection, not encryption key ownership.

Go deeper

Related to this question