☁️
AWS Solutions Architect Associate SAA-C03 Study Notes/
🔶
AWS Identity and Access Management (IAM)/
🔷
IAM Policy Evaluation Logic
🔷

IAM Policy Evaluation Logic

Core Principles

  1. Implicit Deny by Default
      2. All actions start denied unless an explicit allow is found.
  1. Explicit Allow
      2. If a policy explicitly allows an action and no other policy denies it, the action is permitted.
  1. Explicit Deny Takes Precedence
      2. An explicit deny in any applicable policy overrides any allows.
  1. Multiple Policy Types in Play
      2. Effective permissions are the result of evaluating together:
      • Identity-based policies (user, group, or role)
      • Resource-based policies (e.g., S3 bucket policy)
      • Permission boundaries (limits on the max permissions for a user/role)
      • Session policies (applied to temporary credentials)
      • Service Control Policies (SCPs in AWS Organizations)

Evaluation Flow

  • Start: Request is implicitly denied.
  • Check for Allows: Identity-based or resource-based policies must explicitly allow the action.
  • Apply Boundaries: Permission boundaries and SCPs must also allow it.
  • Look for Denies: If any applicable policy has an explicit deny that matches, the request is denied.
  • Conditions: Even with an allow, all conditions (region restrictions, MFA requirements, tags) must be satisfied.

Example – How to Evaluate a Request

To determine if a user can run an action (e.g., sqs:CreateQueue):
  1. Look in the identity-based policies for an allow.
  1. Check if a permission boundary limits it.
  1. Verify there’s no explicit deny from SCPs or resource policies.
  1. Confirm that conditions are met (e.g., correct region or MFA enabled).
You apply the same process for actions like sqs:DeleteQueue or ec2:DescribeInstances — the final answer depends on the intersection of all policies and the absence of explicit denies.