DVA-C02 Security 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-C

  Why it's wrong here

  With SSE-C, you must provide your own encryption keys in every request, and AWS uses them only to encrypt and decrypt the object before discarding them. You are entirely responsible for key storage, rotation, and distribution, and all requests must be made over HTTPS. This does not satisfy a requirement for AWS-managed encryption because the key lifecycle remains in your control.

• ✓

  SSE-KMS

  Why this is correct

  SSE-KMS uses AWS KMS to generate and manage your encryption keys, and the service applies envelope encryption where S3 encrypts objects with a data key that is itself encrypted by a customer master key. It supports automatic key rotation, provides a CloudTrail audit trail of every KMS API call, and lets you attach IAM policies and grants to restrict decryption access. This is the most appropriate option when you need centralised control, audibility, and permission-based access to the encrypted data.

• ✓

  SSE-S3

  Why this is correct

  SSE-S3 uses S3-managed AES-256 encryption keys that AWS rotates automatically on your behalf, with no configuration required. The encryption is fully transparent to the application and there is no way to control or monitor key usage, making it a simple but limited solution. It meets a basic requirement for server-side encryption with AWS-managed keys, but lacks the key-level access control and audit capabilities that SSE-KMS provides.

• ✗

  AWS CloudHSM

  Why it's wrong here

  AWS CloudHSM provides dedicated, customer-controlled hardware security modules in the cloud, meaning you own the HSM and manage the keys and credentials yourself. It is not a server-side encryption mode for S3; rather, you would use it with client-side encryption or as a custom key store for AWS KMS. This option fails the requirement that AWS manage the encryption keys, and it introduces significant operational overhead without giving you the integrated S3 encryption behaviour.

• ✗

  Client-side encryption with AWS KMS

  Why it's wrong here

  With client-side encryption, your application encrypts data locally before transmitting it to S3, so the object is already ciphertext when it reaches AWS. Although AWS KMS can generate or protect the data keys used in this process, the encryption does not occur at rest inside S3 and AWS does not manage the encryption of the object at the storage layer. This is the wrong choice when the requirement specifically asks for server-side encryption where AWS handles encryption of data at rest.