DEA-C01 Data Security and Governance Practice Question

A company wants to enforce that all data in Amazon S3 is encrypted at rest. They want to automatically reject any PUT request that does not include encryption headers. What S3 feature should they use?

⚠ Common exam trap

DEA-C01 often tests whether candidates confuse default encryption (which silently encrypts but does not reject) with a bucket policy condition (which actively denies unencrypted PUTs) — the requirement to reject is the key differentiator.

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

✓

Bucket policy with a condition for encryption headers

An S3 bucket policy with a condition such as s3:x-amz-server-side-encryption or s3:x-amz-server-side-encryption-aws-kms-key-id can explicitly deny any PutObject request that lacks the required encryption headers. This enforces encryption at rest by rejecting unencrypted uploads at the API level, which is exactly the requirement. Default encryption alone does not reject unencrypted PUTs — it only encrypts them automatically.

Answer analysis

Option-by-option breakdown

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

✓
Bucket policy with a condition for encryption headers
Why this is correct
A bucket policy with `s3:PutObject` denied unless `s3:x-amz-server-side-encryption` is present rejects unencrypted PUT requests at the authorisation layer, satisfying the requirement to block uploads lacking encryption headers. This enforces encryption at rest without relying on client compliance or post-upload remediation.
✗
Default encryption
Why it's wrong here
Default encryption applies SSE automatically to objects lacking encryption headers, so it encrypts rather than rejects the PUT request. It is tempting because it achieves encryption at rest, and would be correct if the requirement were simply ensuring all objects are encrypted without refusing non-compliant uploads.
✗
MFA Delete
Why it's wrong here
MFA Delete controls version deletion authorisation, not encryption of uploaded objects, so PUT requests without encryption headers still succeed. It is tempting because it is a bucket-level security control, and would be correct if the requirement were protecting object versions from accidental or malicious deletion.
✗
S3 Block Public Access
Why it's wrong here
Block Public Access governs ACL and policy permissions, not encryption headers, so it cannot reject unencrypted PUT requests. It is tempting because it enforces bucket-wide restrictions automatically, and would be correct if the requirement were preventing public exposure rather than mandating encryption.

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 Security and Governance Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question