IAM Policy Evaluation Logic — the diagram AWS should have made

The most common question I get about AWS IAM isn't "how do I allow this" — it's "why is this denied when I clearly allowed it?" The answer is almost always the evaluation order, and almost nobody has it memorised. So here's the diagram AWS should have shipped.

Practitioner guidance. The authoritative source is the AWS IAM policy evaluation documentation — use this as the working mental model.

The order that actually decides every request

When a principal makes a request, AWS evaluates it through layers — and the order is what trips people up:

   Request
     │
  1. Explicit DENY anywhere?  ──── yes ──►  ❌ DENIED  (full stop, nothing overrides this)
     │ no
  2. Service Control Policy (SCP) allows it?  ── no ──►  ❌ DENIED
     │ yes
  3. Resource-based policy allows it?  ── yes ──►  ✅ ALLOWED  (can stand alone)
     │ no / none
  4. Permission boundary allows it?  ── no ──►  ❌ DENIED  (caps the maximum)
     │ yes
  5. Session policy allows it?  ── no ──►  ❌ DENIED
     │ yes
  6. Identity-based policy allows it?  ── yes ──►  ✅ ALLOWED
     │ no
        ❌ DENIED  (default deny — no explicit allow)

Two rules explain 90% of the surprises:

• An explicit Deny always wins. One Deny statement anywhere — identity policy, SCP, boundary, resource policy — kills the request. You can have a hundred Allows; the single Deny beats them all.
• Default is deny. If nothing explicitly allows the action, it's denied. Access is opt-in.

The four "but I allowed it!" traps

1. An SCP is silently blocking you. SCPs don't grant anything — they set the outer boundary for an entire account/OU. If your org's SCP doesn't allow s3:DeleteBucket, no IAM policy in that account can either. The IAM policy looks correct; the account just isn't allowed to.

2. A permission boundary is capping the role. A boundary defines the maximum a principal can have. If the boundary allows s3:Get* but the identity policy allows s3:*, the effective permission is only s3:Get* — the intersection. The identity policy reads broad, but the boundary quietly clips it.

3. An explicit deny with a condition. A Deny with Condition: { Bool: { aws:MultiFactorAuthPresent: false } } blocks everything when MFA isn't present — even actions you've explicitly allowed. The allow is real; the conditional deny outranks it.

4. Resource-based vs identity-based confusion. For cross-account access you often need both an identity policy (on the caller) and a resource policy (on the target). One alone isn't enough across accounts — within the same account, a resource policy allow can stand on its own.

Why this matters for CPS 234 (and any audit)

"Least privilege" isn't a single policy — it's the net effect of all six layers. When an auditor asks "can this role read customer data?", the honest answer requires evaluating the whole stack, not just the identity policy. That's why the durable controls are:

• SCPs as the non-bypassable floor (e.g. deny disabling CloudTrail, deny public S3) — they hold even if an identity policy drifts.
• Permission boundaries so teams self-serve without exceeding a ceiling.
• IAM Access Analyzer to compute effective access from real activity, instead of reading policies by eye.

The tool that reads this whole picture for you is Cloudsplaining — it surfaces the policies that grant privilege escalation, data exfiltration and resource exposure, which is exactly the access-control evidence CPS 234 paragraph 21 expects. This same evaluation order is why least-privilege for AI agents must be enforced at the IAM layer, not in the prompt.

The one-line version

Deny wins. Boundaries cap. SCPs gate. Default is deny. When a request is denied and you don't know why, walk the six layers from the top — the answer is always one of them.

Building APRA-aligned AWS security tooling in the open — IAM patterns, conformance packs, and compliance scanners — at aiopsone.com.

Primary sources: AWS IAM policy evaluation logic · IAM security best practices