Every so often someone on the team asks the same question in a slightly different shape: “Why can’t this role read that bucket?” “Will this Lambda be allowed to write to the table?” “We added the bucket policy — why is it still AccessDenied?”

The answer is almost always hiding in the interaction between six things: the IAM identity policy, the permission boundary, the resource-based policy, the SCP, the RCP, and — for encrypted resources — the KMS key policy. Each one can independently sink a request, and a few of them interact in ways that are genuinely counterintuitive.

I’d written all of this up as notes. But a wall of rules is hard to internalise, so I turned it into something you can poke at:

→ Try the evaluator

What it does

You set the scenario with toggles — service, same-account vs cross-account, encryption, and the state of each policy — and the page draws a live diagram of the request. Nested boxes are policy scopes: SCP and RCP wrap the account, the permission boundary and the identity / resource policies wrap the principal and the resource. Press Run request and a dot travels from the role to the resource and stops, pulsing, at the exact gate that decides the outcome. A gate-by-gate table and a one-line “deciding rule” explain why.

It’s deliberately a teaching tool. The fun is in flipping one switch and watching the verdict change.

The corners worth playing with

A few scenarios are worth setting up yourself, because they’re the ones people get wrong:

• Implicit vs. explicit deny in a permission boundary. Same-account, a resource-policy grant overrules an implicit deny in the boundary (the action simply isn’t in its allow set) — but it can never override an explicit Deny. Flip the boundary between “Silent” and “Explicit Deny” and watch the verdict flip with it.
• Cross-account needs both sides. Same-account is generous: an IAM Allow on the role is often enough. Cross-account is not — you need an IAM Allow and a resource-policy grant. The diagram makes this physical: the request has to clear a gate on each side of the account gap.
• aws/s3 can’t go cross-account. The AWS-managed S3 key silently makes cross-account access impossible. Set it up and the evaluator calls it out.
• A CMK is deny-by-default. Same-account buys you nothing with a customer-managed KMS key — the principal has to be enumerated in the key policy. IAM alone never unlocks it.
• SCPs and RCPs can’t be bypassed. A resource-policy grant can paper over an implicit boundary deny, but never an SCP or RCP block.

Why a diagram and not a blog post

I could have published the rules as prose — I nearly did. But authorization is a path: a request either makes it through every gate or it doesn’t, and the interesting part is always which gate stopped it. A diagram that animates that path teaches the mental model in a way a table never quite does. The underlying logic is the same one I packaged as a reusable agent skill; this is just its friendlier, clickable face.

If you find a scenario it gets wrong, I’d love to hear about it.