← Back to Labs L2 Intermediate

AWS · Identity · IAM Policy Evaluation

AWS IAM Policy Evaluation

Intermediate LAB for understanding how AWS evaluates effective permissions across identity policies, resource policies, permission boundaries, session policies, SCPs, and explicit deny.

Status Intermediate
Cloud AWS
Domain Identity
Track L2

Overview

This lab teaches how AWS IAM produces a final authorization decision when multiple policy layers apply.

L2 Intermediate Identity-first Policy reasoning No live mutation

Concept Deep Dives

Expand each concept when you need a deeper explanation during study, mentoring, or executive walkthroughs.

What is Zero Trust?

Zero Trust means every request must be evaluated based on identity, policy, resource, and context. Trust is not granted simply because the requester is inside a network or already authenticated.

In this lab, Zero Trust shows up as policy evaluation: who is asking, what action is requested, what resource is targeted, and what context affects the final decision.

What is effective permission?

Effective permission is the final permission outcome after all applicable controls are evaluated. It is not enough to find one allow. The allow must survive explicit deny, permission boundaries, session policies, and organization guardrails.

What is explicit deny?

Explicit deny is a hard stop. If an applicable policy denies an action, the request is denied even when another policy allows it.

This is why the first learning rule is: check for deny before proving allow.

What is a permission boundary?

A permission boundary limits the maximum authority a principal can have. It does not grant access by itself. It constrains what identity policies can successfully allow.

What is an SCP?

A Service Control Policy is an AWS Organizations guardrail. It defines the maximum available permissions for accounts or organizational units. Like a boundary, it does not grant access by itself.

Why does this matter for Principal LABs?

Cross-account trust, iam:PassRole, and role chaining all depend on effective authority. This L2 lab teaches the decision logic required before analyzing those advanced paths.

Evaluation Model

Principal
  +
Action
  +
Resource
  +
Context
  =
Authorization Decision
Request received
    ↓
Check explicit deny
    ↓
Evaluate identity policies
    ↓
Evaluate resource policies
    ↓
Apply permission boundaries
    ↓
Apply session policies
    ↓
Apply service control policies
    ↓
Final decision

Visual Evaluation Model

IAM authorization is easier to learn when the request is treated as a decision path. The final result is not based on one policy alone; it is produced by the interaction of identity, policy layers, resource, and request context.

Principal User, role, service, or federated identity
→
Action Requested API operation such as s3:GetObject
→
Resource Target ARN, bucket, role, key, or service object
→
Context Region, source IP, MFA, tags, time, or session attributes
Identity Policy What the principal may request
Resource Policy What the resource permits
Boundary Maximum allowed authority
SCP Organization-level guardrail
Explicit Deny? If yes, final decision is DENY
→
Effective Permission Combine applicable policy layers
→
Allow / Deny Final authorization result
Learning rule: IAM evaluation is not “find an allow.” It is “check for deny, then prove an allow survives every boundary.”

Explicit Deny

The central IAM rule is simple but critical: 

Explicit deny overrides allow.

A request can have an allow in one policy and still be denied if another applicable policy explicitly denies it.

Bridge to Principal LABs

This L2 lab prepares learners for the AWS Principal Identity Track by teaching the policy evaluation logic behind deterministic identity paths.

Cross-Account Role Escalation Requires trust policy and AssumeRole reasoning. iam:PassRole Privilege Escalation Requires effective permission and service role reasoning. Role Chaining Escalation Requires transitive role trust and effective authority reasoning.

Governance Boundary

This lab is read-only and deterministic. 

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not exploit AWS
  • Does not mutate infrastructure
  • Does not deploy live resources
  • Does not issue runtime tokens
  • Does not override OPA

Source Artifacts

  • metadata.json
  • architecture.md