An identity policy on a retail role allows s3:PutObject on a bucket. Puts still fail. The role's permission boundary does not include s3:PutObject, and no service control policy mentions S3. Why is the call denied?
Select an answer to reveal the explanation.
Short Explanation
A permission boundary is a ceiling, not a bonus. The identity policy says the role may put objects, and the ceiling stops short of that action, so the put fails. You raise the ceiling on purpose or you stop expecting the put to work, and encryption does not switch IAM off.
Full Explanation
Effective permissions are the overlap of the identity policy and the permission boundary. An allow in the identity policy cannot exceed the boundary, and this boundary omits s3:PutObject, so the call is denied. The boundary does not grant anything the identity policy lacks; it only limits. Encryption of the bucket changes storage, not whether IAM evaluates the boundary. CloudTrail is not part of authorization, so a missing trail cannot be why the boundary denied the put. Caveat: an explicit deny in either document still wins; here the stem describes a missing allow in the boundary, which is an implicit deny. Operational check: include the boundary in the IAM policy simulator for s3:PutObject as this role and confirm the decision flips only after the boundary allows the action. You can see this in the simulator by selecting the role and including the boundary: the identity allow and the boundary's silence become an implicit deny. Adding s3:PutObject to the boundary, and keeping the identity allow, is what makes the overlap include the action. Do not remove the boundary to make the test pass; it is there to cap the role.