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-KMS with a customer-managed key that has automatic key rotation enabled.

  Why this is correct

  SSE-KMS with a customer-managed AWS KMS key that has automatic rotation enabled satisfies the requirement because S3 Glacier applies server-side encryption using KMS, and KMS automatically rotates the underlying key material on an annual basis without any manual action. The CMK remains the same logical key, so object references and permissions are unchanged while the encryption material is refreshed, meeting compliance policies that demand automatic key rotation. This is the most flexible option when you need separate permissions and audit trails.

• ✗

  Use AWS CloudHSM to generate a key and encrypt data before uploading to Glacier.

  Why it's wrong here

  AWS CloudHSM provides hardware-based cryptographic key generation and client-side encryption before upload to Glacier, but it does not offer automatic key rotation. Your application must orchestrate creating new keys, re-encrypting existing objects, and deleting old keys, which is manual and error-prone. Moreover, Glacier itself cannot use CloudHSM keys for server-side encryption; you are responsible for the entire key lifecycle, so this approach fails the automatic rotation requirement.

• ✗

  Use client-side encryption with the Amazon S3 encryption client.

  Why it's wrong here

  The Amazon S3 encryption client performs client-side encryption, meaning data is encrypted before it ever reaches S3 Glacier, but the master key you use must be managed and rotated manually by your application. Even if you source the key from KMS, the client derives and caches data keys, and the server-side infrastructure of Glacier does not manage rotation on your behalf. This offloads encryption but does not deliver the required automatic key rotation, making it an incomplete solution.

• ✗

  Use SSE-C with keys stored in AWS Secrets Manager and rotate keys annually.

  Why it's wrong here

  SSE-C lets you provide your own encryption keys for S3 Glacier, and S3 uses those keys to encrypt the object, but S3 neither stores nor rotates them. Storing keys in AWS Secrets Manager helps with secret management, but rotating annually via Secrets Manager is not automatic; you must build automation to call the rotation API and, critically, you must retain or re-encrypt data with old keys to maintain decryption. Because the requirement specifies automatic key rotation, SSE-C cannot meet it without significant custom work.

• ✓

  Use the default encryption provided by S3 Glacier (SSE-S3).

  Why this is correct

  S3 Glacier’s default server-side encryption, SSE-S3, uses Amazon-managed AES-256 keys that AWS rotates automatically on a regular basis, typically about once a year. No customer effort is required to enable or manage this rotation, and it provides strong encryption of all objects at rest. This is the simplest solution that satisfies the automatic key rotation requirement, though it lacks the audit and permission flexibility of KMS customer-managed keys.

Go deeper

Related to this question