sdlc.dev

AWS fundamentals path · Ground rules · Topic 4 of 18

How IAM evaluates a request

Not started

For each request, IAM collects every policy that applies (the principal's identity-based policies, the resource's policy, any SCPs and resource control policies from AWS Organizations, a permissions boundary on the principal, and a session policy if one was passed) and runs the same decision. The request begins **implicitly denied**. Any matching **explicit Deny** ends it. Then each guard-rail policy that applies must allow the action. Finally, an Allow in an identity-based or resource-based policy grants it.

Why it matters: When access is unexpectedly denied, or worse, unexpectedly allowed, the answer is always in the evaluation order. Knowing it turns hours of guessing into a few minutes.

  1. 1Default deny

    A request starts as denied. Only an explicit Allow in an applicable policy can change that.

  2. 2Explicit deny always wins

    A Deny that matches, in any policy type, overrides every Allow. There is no way to allow around it.

  3. 3Guard rails intersect

    SCPs, resource control policies, permissions boundaries and session policies only limit. The action must be allowed by each one that applies.

  4. 4Grants combine

    Within one account, an Allow in either the identity-based policy or the resource-based policy is enough.

1

How it works

The explanation, with examples you can run.

The order, simplified

  1. Is there a matching "Effect": "Deny" in any applicable policy? Then deny. Nothing can override it.
  2. Is the account in an organization with SCPs or resource control policies? The action must be allowed by them; if not, deny.
  3. Does the principal have a permissions boundary, or the session a session policy? The action must be inside it; if not, deny.
  4. Does an identity-based or resource-based policy allow it? Then allow.
  5. Otherwise, deny (the implicit deny from the start).

Guard rails never grant anything; they only cut the maximum. An SCP that allows s3:* does not let anyone use S3 until an identity or resource policy also does. Real IAM has more detail (cross-account requests need an allow on both sides, a few resource policies that name a principal directly behave differently with boundaries, and conditions can make any statement not apply), but this order explains nearly every surprise.

Try it

A toy evaluator for single-account requests with an SCP. Wildcards (*) match any characters, as in IAM. Change the policies and see which step decides.

⌘/Ctrl + Enter
OutputNot run yet

Press Run to see what your code prints, in order.

Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.

Run with Node, it prints:

s3:GetObject reports/2026/q1.csv -> ALLOWs3:DeleteObject reports/2025/q4.csv -> DENY (explicit deny)s3:ListBucket reports/x -> DENY (not allowed by the SCP)s3:GetObject payroll/jan.csv -> DENY (implicit: nothing allowed it)

The third request is the one people trip over: the role's own policy says s3:*, but the organization's SCP never allowed listing.

Debugging a denial

  • The error message often says which policy type denied the request ("with an explicit deny in a service control policy", "because no identity-based policy allows").
  • The IAM policy simulator and aws iam simulate-principal-policy evaluate a request without making it.
  • CloudTrail records the denied call, the principal and the error code.
  • Check the resource side too: bucket policies, KMS key policies and queue policies are frequent sources of explicit denies, and a KMS key policy must allow use of the key even when the bucket allows the read.
2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.A role's policy allows s3:* on a bucket. The account's SCP allows only s3:Get*. Can the role delete objects?
  2. 2.A user's identity policy allows s3:GetObject on a bucket. The bucket policy explicitly denies everyone without a specific tag. The user lacks the tag. Result?
  3. 3.Within the same account, a bucket policy allows a role to read the bucket, and the role's own policies say nothing about S3. Is the read allowed?

0 of 3 right so far. Get all three to finish this topic.

Go deeper