AWS IAM Policy
Simulator

How AWS IAM Policy Evaluation Works — Complete Guide

Understanding how AWS evaluates IAM policies is critical for building secure cloud architectures. This simulator replicates the exact AWS policy evaluation engine — so you can test decisions, debug access issues, and validate security controls before deploying to production.

The Six-Step AWS Policy Evaluation Algorithm

When an IAM principal makes an API request, AWS evaluates all applicable policies in a strict order. The first matching rule wins — and an explicit Deny always wins over everything else.

• Step 1 — Explicit Deny check: AWS scans all applicable policies for any statement with "Effect":"Deny" that matches the action and resource. If found, the request is denied immediately — no further evaluation.
• Step 2 — SCP evaluation: If the account is part of an AWS Organisation, SCPs define the maximum permissions. If no SCP allows the action, it is implicitly denied at this layer.
• Step 3 — Permissions boundary: If a permissions boundary is attached to the IAM entity, the action must also be allowed by the boundary policy. The boundary limits, but does not grant, permissions.
• Step 4 — Resource policy (same account): For resource-based policies (S3, SQS, KMS), an explicit Allow in the resource policy can grant access independent of the identity policy for same-account principals.
• Step 5 — Identity policy Allow: If no Deny and no SCP/boundary block, an explicit Allow in any attached identity policy grants access.
• Step 6 — Implicit Deny: If no Allow statement was found, the request is denied by default. AWS never allows by default — permissions must be explicitly granted.

Explicit Deny vs Implicit Deny — What's the Difference?

An explicit deny occurs when a policy statement has "Effect":"Deny" that matches the request. It is definitive and cannot be overridden by any Allow in any other policy — including admin policies and root permissions (except for root on certain actions). An implicit deny is simply the absence of an Allow — the default state. Any policy could still grant access and override an implicit deny, but nothing can override an explicit deny.

How Conditions Are Evaluated

Conditions use a three-part structure: operator, context key, and value. For a statement to apply, all conditions in the block must be satisfied. Within a single condition, multiple values use OR logic (any must match). The IfExists suffix passes the condition if the context key is absent, making it safe for optional keys. Global condition keys like aws:SourceIp are always available; service-specific keys like s3:prefix are only available for relevant service APIs.

Cross-Account Access Rules

When a principal in Account A accesses a resource in Account B: both the resource policy in Account B must allow the access AND the identity policy in Account A must allow the action. Either policy alone is insufficient. This is why S3 bucket policies with "Principal":"*" still require the caller to have an Allow in their own identity policy.

Common IAM Policy Debugging Patterns

• Access Denied but policy shows Allow: Check for an explicit Deny elsewhere — in a SCP, permission boundary, or another attached policy. Deny always wins.
• Condition not matching: Verify the context key name is correct and the value type matches (Bool vs String). Missing context keys cause conditions to fail silently.
• S3 access denied cross-account: Confirm both the bucket policy grants access to the specific principal AND the caller's identity policy allows the S3 action.
• Role can't do what user can: Check if a permissions boundary is attached to the role limiting its effective permissions below what the identity policy allows.

Frequently Asked Questions