DEA-C01 Data Store Management Practice Question

A data engineer is designing a data lake on Amazon S3 and needs to ensure that objects are automatically encrypted at rest using server-side encryption with AWS KMS. Which bucket policy statement achieves this?

⚠ Common exam trap

Test-takers frequently confuse the encryption header values (`aws:kms` vs `AES256`) and mistakenly choose an option that enforces SSE-S3 (AES256) instead of SSE-KMS, or they pick a Deny statement that only checks for the presence of the header without validating its specific value.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Deny PutObject requests where the x-amz-server-side-encryption header is not set to aws:kms.

It enforces server-side encryption with AWS KMS (SSE-KMS) by denying any PutObject request that does not include the `x-amz-server-side-encryption` header set to `aws:kms`. This bucket policy ensures that all objects written to the S3 bucket are automatically encrypted at rest using AWS KMS, meeting the requirement for mandatory encryption with a specific key management service.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Deny PutObject requests where the x-amz-server-side-encryption header is not set to aws:kms.
Why this is correct
A bucket policy condition on `s3:PutObject` can require the `x-amz-server-side-encryption` header to equal `aws:kms`, denying any upload that omits SSE-KMS. This enforces encryption at rest with AWS KMS at the API layer, satisfying the stem's automatic SSE-KMS requirement regardless of client defaults.
✗
Deny PutObject requests that do not include the x-amz-server-side-encryption header.
Why it's wrong here
Denying requests without the header blocks unencrypted uploads but accepts any algorithm, including AES256 (SSE-S3), so KMS encryption is not enforced. It is tempting because it appears to mandate encryption, and it would be correct if the requirement were simply that all objects be encrypted at rest by any server-side method.
✗
Deny PutObject requests where the x-amz-server-side-encryption header is not set to AES256.
Why it's wrong here
AES256 denotes SSE-S3, so denying anything else still permits S3-managed keys rather than the required AWS KMS keys; the condition must reference aws:kms and a key ARN. It is tempting because it names a specific algorithm, and it would be correct if SSE-S3 were the mandated encryption method.
✗
Allow PutObject requests only if the x-amz-server-side-encryption header is set to AES256.
Why it's wrong here
AES256 specifies SSE-S3, not SSE-KMS, so the condition permits objects encrypted with S3-managed keys and never enforces a KMS key ID. It is tempting because AES256 is a valid header value, and it would be correct if the requirement were merely encryption at rest with AWS-owned keys.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Store Management Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question