DEA-C01 Data Security and Governance Practice Question

A data engineer needs to share a dataset stored in an Amazon S3 bucket with another AWS account. The dataset must remain encrypted at rest using AWS KMS. The data engineer creates a bucket policy that grants the other account access to the bucket. However, the other account reports that objects appear encrypted and they cannot decrypt them. What is the most likely cause?

⚠ Common exam trap

DEA-C01 often tests the misconception that S3 bucket policies alone are sufficient for cross-account access to KMS-encrypted objects, ignoring the need for KMS key policy permissions.

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 KMS key policy does not grant the other account the kms:Decrypt permission

For cross-account access to KMS-encrypted S3 objects, both the S3 bucket policy and the KMS key policy must grant the necessary permissions. The bucket policy grants s3:GetObject, but decryption requires kms:Decrypt on the KMS key. If the key policy does not allow the other account, the objects cannot be decrypted, even with S3 access.

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 KMS key policy does not grant the other account the kms:Decrypt permission
Why this is correct
Cross-account access requires permissions on both the S3 bucket policy and the KMS key policy. The bucket policy alone grants object access, but decryption fails because the KMS key policy does not authorise the other account's principals to call kms:Decrypt on that customer-managed key.
✗
The bucket policy does not grant the s3:GetObject permission
Why it's wrong here
The stem states the bucket policy already grants the other account access, and objects appearing encrypted rather than access-denied points to the KMS key policy, not s3:GetObject. It is tempting because missing s3:GetObject is the common cause of cross-account S3 access failures generally.
✗
The other account must use the same KMS key to upload objects
Why it's wrong here
Decryption of existing objects depends on the key policy allowing the other account's principals to use the KMS key, not on which key they upload with. It is tempting because key selection matters for writing new objects, but the reported symptom is reading existing encrypted data.
✗
The objects are encrypted with SSE-S3, which is not supported for cross-account access
Why it's wrong here
SSE-S3 is fully supported for cross-account access; the other account simply needs s3:GetObject, since no KMS key policy governs it. It is tempting because SSE-S3 lacks the granular key-policy controls that SSE-KMS requires, but that absence is not a cross-account limitation.

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