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 ReadOnlyAccess…

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
  10% (3)
• B
  3% (1)
• C
  83% (24)
• D
  3% (1)

Explanation

Option C is correct because the S3 bucket is KMS-encrypted, and reading encrypted objects requires both S3 read permissions and kms:Decrypt on the KMS key - the existing ReadOnlyAccess policy covers S3 reads but not KMS decryption. Attaching an inline policy with kms:Decrypt to the EC2 IAM role grants exactly the missing permission without over-provisioning.

Why the others are wrong:

• A - AWS managed policies are read-only; you cannot edit them directly. You must extend permissions via separate attached policies.
• B - The bucket policy already allows all account principals, so adding the role as an explicit principal changes nothing; the real gap is the missing KMS permission.
• D - S3:* is unnecessary over-provisioning since ReadOnlyAccess already includes S3 read rights, and it still doesn't solve the KMS decryption problem.

Memory tip: Whenever you see "encrypted S3" + AccessDenied, immediately think KMS. The formula is: S3 read + kms:Decrypt = access to encrypted objects. If one half is missing, access is denied - and you fix it by adding a new policy, never by editing an AWS managed one.

No community discussion yet for this question.