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.

• ✓

  Set the default encryption on the bucket to SSE-KMS.

  Why this is correct

  Setting default encryption on the S3 bucket to SSE-KMS is the direct and required control because it instructs S3 to automatically apply KMS-based encryption to every new object written to the bucket, regardless of whether the upload request includes encryption headers. This setting meets the requirement without forcing changes to the application code, and it ensures that any object uploaded without explicit encryption is still encrypted at rest.

• ✗

  Enable MFA Delete on the bucket.

  Why it's wrong here

  Enabling MFA Delete on the bucket is a versioning-related protection that requires a second form of authentication to permanently delete object versions or change the versioning state. It is completely unrelated to data encryption at rest, as encryption protects the confidentiality of object contents while MFA Delete is about preventing accidental or malicious destructions of versions. Therefore, it does nothing to encrypt the data.

• ✗

  Create a bucket policy that denies unencrypted requests.

  Why it's wrong here

  Creating a bucket policy that denies unencrypted requests is an optional enforcement layer that uses aws:SecureTransport or the s3:x-amz-server-side-encryption condition to reject PUTs that do not include encryption headers. It does not by itself encrypt any object; it merely blocks writes that do not carry the required headers, and it can directly conflict with default encryption because S3's own inspection of the request may not see the automatically applied default encryption headers. The default encryption setting already guarantees encryption, so this policy is not required to achieve the stated goal.

• ✓

  Grant the IAM role kms:GenerateDataKey and kms:Decrypt permissions.

  Why this is correct

  Granting the IAM role kms:GenerateDataKey and kms:Decrypt permissions is necessary for any principal that will put or get objects encrypted with SSE-KMS. When S3 encrypts an object it calls GenerateDataKey to obtain a data key, and when reading it calls Decrypt to unwrap that stored data key; without these permissions on the customer-managed KMS key, uploads and downloads will fail with access denied, meaning default encryption alone is insufficient if the executing role is not authorized.

• ✗

  Enable versioning on the bucket.

  Why it's wrong here

  Enabling versioning on the bucket is a feature that preserves multiple variants of an object to guard against overwrites and one-time deletions, which is useful for operational recovery but has no bearing on data encryption. Encryption at rest with SSE-KMS is applied independently to each version, but versioning itself will never encrypt any data nor does it alter how S3 uses a KMS key. Since the requirement is to encrypt the data, turning on versioning is irrelevant to that outcome.