IAM Policy Evaluation Logic | Overview.

IAM Policy Evaluation Logic - Overview.

Scope:

• Intro,
• The core logic & fundamental rules,
• The AWS evaluation order for a single-account request path,
• Core Principle,
• Policy Types,
• Architecture,
• Link to official documentation,
• Evaluation Flow Overview,
• Effective Permission Formula,
• Visual Evaluation Flow Diagram,
• Common Gotchas (things to watch out for),
• Sample of  Identity Policy,
• Key Takeaway.

Intro:

• AWS IAM evaluates a request by combining all applicable policies in a specific sequence to determine a final "Allow" or "Deny" decision. 

The core logic & fundamental rules:

• Default Deny: All requests are denied by default.
• Explicit Deny: If any applicable policy contains a "Deny" statement that matches the request, the final decision is "Deny," overriding any "Allow".
• Explicit Allow: If no explicit "Deny" exists and at least one "Allow" statement matches the request, the final decision is "Allow".
• Implicit Deny: If there is no explicit "Deny" and no explicit "Allow," the request remains "Deny". 

The AWS evaluation order for a single-account request typically follows this path: 

1. Check for explicit denies across all applicable policies.
2. Evaluate Service Control Policies (SCPs) if the account is part of an AWS Organization.
3. Evaluate Resource-based policies (e.g., S3 bucket policies).
4. Check Permissions Boundaries attached to the IAM principal.
5. Evaluate Session policies if using temporary credentials.
6. Evaluate Identity-based policies (inline or managed policies attached to the user/role). 

NB:

• For cross-account access, the request must be explicitly allowed by both the account owning the resource and the account owning the IAM principal.
• 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

NB:

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

Policy Type	Scope	Sample
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”

 Architecture

 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

Link to official documentation

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-basics.html

 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

 # Sample of  Identity Policy

# json

{

  "Effect": "Allow",

  "Action": "s3:*",

  "Resource": "*"

}

# Permission Boundary

{

  "Effect": "Allow",

  "Action": "s3:GetObject",

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

}

# Key Takeaway:

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