How IAM Decisions Are Evaluated

When a principal makes a request to a cloud resource, the IAM engine runs through an evaluation chain that determines whether the request is allowed or denied. This video walks through that chain step by step — from the initial request through authentication, policy lookup, evaluation logic, and the final allow or deny decision.

Understanding this chain is essential for GRC engineers because every audit finding related to access control traces back to a specific point in this evaluation. When an auditor asks "how do you ensure least privilege?" or "how do you prevent privilege escalation?", the answer lives in how your IAM policies are evaluated.

The IAM evaluation chain

Every IAM decision follows the same fundamental sequence, regardless of cloud provider:

1. Request — A principal (user, role, or service account) makes an API call. The request includes the principal's identity, the action being attempted, and the target resource.

2. Authentication — The IAM engine verifies the principal's identity. Is the access key valid? Is the session token current? Has the OIDC token been signed by a trusted issuer? If authentication fails, the request is rejected immediately with a 401 error. No policy evaluation occurs.

3. Policy lookup — The engine gathers all policies that apply to this request. This includes identity-based policies (attached to the principal), resource-based policies (attached to the target resource), permission boundaries, session policies, SCPs (in AWS), and organization policies (in GCP). The full set of applicable policies forms the evaluation context.

4. Evaluation — The engine evaluates all gathered policies against the specific action and resource in the request. This is where the core logic runs — and where the default deny principle and explicit deny rules apply.

5. Decision — The engine returns Allow or Deny. If allowed, the action proceeds. If denied, the principal receives a 403 error.

Default deny: Everything starts denied

The single most important principle in IAM evaluation is default deny. If no policy explicitly grants permission for a request, the request is denied. You do not need a policy that says "deny ec2:TerminateInstances." The absence of a policy granting that permission is itself a denial.

This is why a newly created IAM user with no attached policies can authenticate (they have valid credentials) but cannot do anything (no policy grants them any permissions). Default deny is the foundation of least privilege — principals start with zero access and must be explicitly granted every permission they need.

Explicit deny always wins

When the evaluation engine encounters a conflict — one policy says Allow and another says Deny for the same action — the explicit deny wins. Always. No exception.

This is what makes SCPs and permission boundaries so powerful as guardrails. An SCP that denies cloudtrail:StopLogging will prevent that action even if the principal has an identity policy granting cloudtrail:*. The explicit deny in the SCP overrides the allow in the identity policy.

The evaluation hierarchy, simplified:

1. Explicit deny in any applicable policy — request is denied. Full stop.
2. Explicit allow in an applicable policy (and no explicit deny) — request is allowed.
3. No explicit allow or deny — request is denied (default deny).

Policies on principals vs. policies on resources

IAM policies can attach to either side of the access equation:

Identity-based policies attach to principals. An AWS IAM policy attached to a user, group, or role. A GCP IAM role binding on a service account. These policies say "this principal can do X on resource Y."

Resource-based policies attach to resources. An S3 bucket policy. A KMS key policy. An SQS queue policy. These policies say "principal X can do Y on this resource." Resource-based policies enable cross-account access — a bucket policy can grant access to a principal in a different AWS account without that principal needing an identity-based policy.

When both types of policies exist, the evaluation engine combines them. In AWS, for same-account access, an allow in either an identity-based policy or a resource-based policy is sufficient (unless an explicit deny exists elsewhere). For cross-account access, both sides must allow the request.