A developer operations team uses AWS Identity and Access Management (IAM) to manage user permissions The team created an Amazon EC2 instance profile role that uses an AWS managed Readonly Access…

Question

Options

• AEdit the ReadOnlyAccess policy to add kms:Decrypt actions.
• BAdd the EC2 IAM role as the authorized Principal to the S3 bucket policy.
• CAttach an inline policy with kms Decrypt permissions to the IAM role
• DAttach an inline policy with S3: * permissions to the IAM role.

• A
  4% (2)
• B
  2% (1)
• C
  83% (39)
• D
  11% (5)

Explanation

Attaching an inline policy with kms:Decrypt to the IAM role is correct because the AccessDenied error is not an S3 permissions problem - it's a KMS permissions problem. When S3 objects are encrypted with a KMS key, reading them requires both S3 read permissions (already granted via ReadOnlyAccess) and kms:Decrypt permission, which ReadOnlyAccess does not include. An inline policy scoped to the specific role follows least-privilege best practice without affecting other identities.

• A is wrong because AWS managed policies cannot be edited by customers - they are owned and controlled by AWS.
• B is wrong because the S3 bucket policy already grants account-wide access; the bottleneck is KMS, not S3.
• D is wrong because the role already has S3 read access via ReadOnlyAccess, and adding S3:* does nothing to address the KMS decryption requirement - plus it's overly permissive.

Memory tip: Whenever you see "encrypted S3" + "AccessDenied" despite valid S3 permissions, think "two locks, one key isn't enough" - S3 read and KMS decrypt are separate permission gates that must both be open.

No community discussion yet for this question.