DEA-C01 Data Security and Governance Practice Question

A company wants to enforce that all data written to an S3 bucket is encrypted with a customer-managed AWS KMS key. The data engineer has created the KMS key and attached an S3 bucket policy. However, users are still able to upload objects without specifying the KMS key. What is the most likely cause?

⚠ Common exam trap

DEA-C01 often tests the difference between default encryption and policy-enforced encryption. Candidates may think that enabling default encryption is sufficient, but it only applies when no encryption is specified, so users can still upload without the KMS key if they don't specify encryption.

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

✓

The S3 bucket policy does not include a condition that denies s3:PutObject without the correct encryption

The most likely cause is that the S3 bucket policy does not include a condition that denies s3:PutObject requests unless the correct encryption (e.g., aws:kms with the specific key) is specified. Without an explicit deny condition, users can still upload objects using the default encryption or no encryption if their IAM permissions allow it. The bucket policy must enforce the encryption requirement by denying non-compliant uploads.

Answer analysis

Option-by-option breakdown

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

✓
The S3 bucket policy does not include a condition that denies s3:PutObject without the correct encryption
Why this is correct
The bucket policy lacks a Deny statement with the `s3:PutObject` action and a `StringNotEquals` condition on `s3:x-amz-server-side-encryption` (and the KMS key ARN), so uploads without the customer-managed key are never refused. Without an explicit deny, S3 permits unencrypted or default-encrypted writes despite the policy.
✗
The S3 bucket has default encryption enabled with SSE-S3
Why it's wrong here
SSE-S3 default encryption satisfies S3's encryption requirement using AWS-managed keys, so PUTs without a KMS key header are accepted. It is tempting because default encryption sounds protective, but it would be correct only if AWS-managed keys were acceptable rather than a customer-managed KMS key.
✗
The KMS key policy does not grant the users kms:Encrypt permission
Why it's wrong here
KMS key policy governs use of the key, not whether S3 accepts an unencrypted PUT; uploads succeed because the bucket policy lacks a condition rejecting requests without the required encryption headers. It is tempting because KMS permissions are genuinely needed for SSE-KMS, but they fail the upload rather than permit a non-compliant one.
✗
The IAM role for the users does not have s3:PutObject permission
Why it's wrong here
Without s3:PutObject the uploads would be denied outright, yet the scenario states users still upload successfully, so this cannot be the cause. It is tempting because missing PutObject is a common S3 access failure, and would be correct if the symptom were AccessDenied rather than unencrypted objects.

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