IAM Policy Evaluation Logic | Deep Dive.

A dive deep into AWS IAM Policy Evaluation Logic,

Intro:
This is one of the most critical concepts for understanding how AWS determines whether a user or role can perform a given action on a given resource.

 Core Principle

• At its core, AWS IAM evaluates every request using all applicable policies, and the default is “DENY”.
  
• A request must explicitly be allowed and not explicitly denied to succeed.

 Policy Types Involved

NB:

When evaluating access, AWS considers multiple types of policies that may apply:

Policy Type	Scope	Example
Identity-based policies	Attached to IAM users, groups, or roles	“Allow s3:GetObject on twtech-s3bucket/*”
Resource-based policies	Attached to resources (like S3 buckets, KMS keys, etc.)	“Allow s3:GetObject to arn:aws:iam::twtechAcctID:user/twtechpat”
Permission boundaries	Optional, limits max permissions an identity policy can grant	“Allow only within arn:aws:s3:::twtechspring-app-*”
Service control policies (SCPs)	Organization-level constraints (via AWS Organizations)	“Deny ec2:* outside region us-east-2”
Session policies	Inline policies applied to a federated or assumed-role session	“Allow temporary access to s3:twtechListesOfBucket”
Access control lists (ACLs)	Legacy, resource-specific (e.g., S3, Lambda)	“Allow twtechAdminUser to read object twtechUserPat”

 

 Evaluation Flow Overview

Let’s break down the IAM decision logic AWS uses for each request.

1. Start with an implicit DENY
• Every request starts as denied.
2. Check for explicit DENY
• If any applicable policy (SCP, identity, resource, etc.) explicitly denies the action → final decision = DENY.
3. Check for explicit ALLOW
• If no explicit deny is found, AWS looks for an explicit allow from:
• Identity-based policy
• Resource-based policy
• Session policy
• If no allow is found → DENY.
4. Validate boundaries (if any)
• If the identity has a permission boundary, the effective permissions = (Identity policy ALLOW) ∩ (Boundary policy ALLOW)
5. Validate SCPs and Organization constraints
• If using AWS Organizations, the SCP acts as an outer filter: (All identity/resource/session permissions) ∩ (SCP ALLOW)
6. Final Decision
• If the resulting combination allows the request → ALLOW
• Otherwise → DENY

 Effective Permission Formula

Therefore:

Effective permissions =
(Identity policy ∩ Permission boundary ∩ SCP) ∪ Resource-based policy ∩ Not explicitly denied

Or conceptually:

DENY > ALLOW

Effective Allow = (ExplicitAllow) - (ExplicitDeny) 

Visual Evaluation Flow Diagram:  Flow-Representation.txt

START → Implicit Deny

   ↓

Is there an Explicit Deny? ──► YES → DENY

   ↓ NO

Is there an Explicit Allow? ──► NO → DENY

   ↓ YES

Is Allow within Permission Boundary? ──► NO → DENY

   ↓ YES

Is Allow within SCP constraints? ──► NO → DENY

   ↓ YES

Is Resource Policy allowing it? ──► NO → DENY

   ↓ YES

FINAL DECISION: ALLOW

Visual Evaluation Flow Diagram:  Flow-Representation.jpg

Source: 

https://www.google.com/search?q=IAM+Policy+Evaluation+Logic&sca_esv

 Common Gotchas (things to watch out for)

Scenario	Result	Why
Permission boundary doesn’t include action	❌ Denied	Boundary limits identity policy
SCP denies even though IAM allows	❌ Denied	SCP overrides account-level permissions
Resource policy allows, identity doesn’t	✅ Allowed	Resource policies can grant access without identity policy (e.g., cross-account)
Implicit deny (no policy)	❌ Denied	Default behavior
Explicit deny anywhere	❌ Denied	Deny always wins

 # Example of  Identity Policy

{

  "Effect": "Allow",

  "Action": "s3:*",

  "Resource": "*"

}

# Permission Boundary

{

  "Effect": "Allow",

  "Action": "s3:GetObject",

  "Resource": "arn:aws:s3:::twechspring-app/*"

}

# Key Take away:

Even though identity policy allows s3:*, the permission boundary limits the effective permissions to only s3:GetObject for twtechspring-app/*.