AWS Lab · Interactiveplay · 5–10 min

IAM Policy Evaluation Simulator

The #1 IAM interview question, 'how does AWS decide?', made tangible. Compose the policies, fire a request, and watch the exact gate that allows or denies it.

From your mentor

IAM feels like dark magic until you see the decision pipeline run. Set an Allow, then watch an SCP or a boundary quietly cap it, and watch an explicit Deny crush everything. Once you can predict the verdict, you understand IAM.

Will this request be allowed?

One request, five policy types. Flip each stance and watch the verdict, and the deciding gate, update live. Try the scenario presets to see the classic traps.

The policies in play

Identity-based policy

attached to the role, grants

Resource-based policy

on the bucket, grants (+ cross-account)

Organizations SCP

account guardrail, caps only

Permissions boundary

max for the role, caps only

Session policy

this assumed session, caps only

Try a scenario

Request AppRole → s3:GetObject on arn:aws:s3:::reports/*

No explicit Deny anywhere

Granted by identity ∪ resource

Allowed by Organizations SCP

Within the permissions boundary

Allowed by the session policy

ALLOWED

Granted by an Allow, no explicit Deny, and permitted by every guardrail (SCP, boundary, session). Access granted.

Worth pondering

Two truths do most of the work here. First, an explicit Deny always wins, no Allow, anywhere, can survive it. Second, SCPs, boundaries, and session policies only take away, they’re ceilings, so an Allow under them can be capped but never the reverse. Hit “SCP caps it” and watch a perfectly good Allow get denied anyway.

The rules it enforces (straight from AWS)

The simulator runs the same order AWS does, top to bottom, the first failing gate decides:

The evaluation chain

1. Any explicit Deny → denied, immediately. 2. Must be granted by the identity policy or the resource policy (union). 3–5.Must then be permitted by the SCP, the permissions boundary, and any session policy, each an intersection (a ceiling). Pass all five → ALLOWED; otherwise the first failure’s reason is your answer.

Use it to answer the interview question

When asked “a role has an Allow for s3:* but still gets AccessDenied, why?”, this is the mental model: look for an explicit Deny, then an SCP, then a boundary. The simulator lets you reproduce that exact scenario and name the culprit.

Next up

Go deeper → IAM, in Depth

The full lesson behind this simulator: principals, the policy types, roles & AssumeRole, and least privilege in practice.