AdvikPrep

AWS IAM Policy Evaluation Practice

Work through realistic authorization scenarios and see how explicit denies, organization guardrails, identity and resource policies, permissions boundaries, and session policies affect access decisions.

?

How to Play AWS IAM Policy Evaluation

New to AWS IAM evaluation logic? Click here to learn the rules.

Beginner LevelStep #1

Cross-Account S3 Access with Explicit Deny

A Lambda function attempts to read an S3 object in Account B. An identity policy grants s3:GetObject, but an SCP explicitly denies s3:* for external buckets.

  1. Step 1: Explicit Deny Check
  2. Step 2: Organization SCPs
  3. Step 3: Resource-Based Policies
  4. Step 4: Identity-Based Policies
  5. Step 5: Permissions Boundary
  6. Step 6: Session Policies

Is there an explicit Deny statement in any applicable policy?

How AWS IAM policy evaluation works

AWS evaluates a request using the principal, requested action, resource, and policies that apply to that request. A useful starting point is that an explicitDenyoverrides anAllow. If no applicable policy grants the request, the result is generally an implicit deny. Which policy types participate—and how they combine—depends on the request context; AWS authorization is not one universal linear checklist.

What each policy layer does

Identity-based policies
Attach permissions to users, groups, or roles. They can grant actions, subject to other applicable controls.
Resource-based policies
Attach permissions to resources, such as an S3 bucket. Cross-account access generally requires authorization from both the caller’s account and the resource-owning account.
Service control policies (SCPs)
Set the maximum permissions available to principals in an AWS Organization. SCPs do not grant permissions themselves.
Permissions boundaries
Set the maximum permissions an identity-based policy can grant to a user or role. A boundary does not grant permissions by itself.
Session policies
When supported and supplied for a session, further limit permissions for that session; they do not add permissions beyond those available to the role or user.

Apply the ideas to the practice scenarios

  • Cross-account S3 request: an identity policy allowings3:GetObject does not erase an applicable explicit deny. Check the caller’s permissions, the bucket policy, and any organization guardrails that apply to the accounts.
  • Role with a permissions boundary: an identity policy may allowdynamodb:PutItem, but a boundary that does not include that action limits the role from using it.
  • Assumed-role session: evaluate the role’s available permissions and any session policy supplied when the role was assumed. A session policy can narrow access; it does not independently grant new actions.

Official AWS references