A data engineer is reviewing an IAM policy that controls access to an S3 bucket. The policy is attached to a user group. The policy includes a condition that explicitly requires server-side encryption with SSE-S3 for all GetObject requests. The engineer notices that users are unable to download objects from the bucket. What is the likely cause?
The condition requires SSE-S3 (AES256), so SSE-KMS objects are denied.
Why this answer
The IAM policy includes a condition that allows downloads only if the object is encrypted with SSE-S3. However, the objects in the bucket are encrypted using SSE-KMS, which does not satisfy the condition. As a result, the s3:GetObject request is denied.
This is a common scenario where a specific encryption condition in the policy blocks access when the actual encryption method differs. The other options are less likely: attaching the policy to a user group is valid and does not cause download issues; an incorrect bucket ARN would affect all operations, not just downloads; and missing s3:GetObject would be a straightforward policy error that would be easily identified.
Exam trap
The trap here is that candidates often focus only on S3 actions (like `s3:GetObject`) and overlook the required KMS permissions when SSE-KMS is involved, assuming SSE-S3 or no encryption is the default.
How to eliminate wrong answers
Option A is wrong because attaching a policy to a user group is a valid and common practice for granting permissions to multiple users; the issue is not about the attachment target but the permissions themselves. Option B is wrong because an incorrect bucket ARN would typically cause all actions to fail, not just downloads, and the question implies other operations might work. Option C is wrong because if the policy did not allow `s3:GetObject`, users would likely receive an Access Denied error for any read operation, but the question specifically mentions download failures, which can occur even with `s3:GetObject` allowed if KMS decrypt is missing.