5.1.1. IAM Policies, Roles, and Permission Boundaries

💡 First Principle: IAM authorization is a layered evaluation process. Every API call is evaluated against potentially dozens of policies simultaneously — identity-based policies, resource-based policies, permission boundaries, SCPs, and session policies — and the result of that evaluation determines whether the call is allowed or denied. Understanding the evaluation logic is what makes IAM troubleshooting tractable rather than guesswork.

Policy Types and Their Scope:

Policy Evaluation Logic — The Critical Rules:

Key rules:

1. An explicit Deny anywhere overrides any Allow — no exceptions
2. Without an Allow, the default is Deny (implicit deny)
3. Permission boundaries and SCPs restrict — they don't grant permissions on their own
4. For cross-account access, both the caller's identity-based policy AND the resource-based policy must allow the action

Permission Boundaries: A permission boundary is a managed policy attached to an IAM user or role that sets the maximum permissions that identity can have. Even if you attach an AdministratorAccess policy, if the permission boundary only allows S3 actions, only S3 actions are permitted.

Use case: You want to allow developers to create IAM roles for their Lambda functions, but you don't want those roles to have more permissions than the developers themselves. Attach a permission boundary to every role they create — they can grant permissions up to the boundary, but not beyond.

IAM Roles vs. Users:

| | IAM User | IAM Role | |:|:--------:|:--------:| | Has permanent credentials | ✅ (access key + password) | ❌ (temporary credentials via STS) | | Best for | Human console/CLI access | Services, cross-account access, federation | | Credential rotation | Manual | Automatic (STS rotates) | | Recommended for EC2/Lambda | ❌ Never embed access keys | ✅ Always use instance role |

Least Privilege in Practice: The exam frequently presents scenarios where you need to grant the minimum permissions necessary. Key patterns:

• Use Resource to scope permissions to specific ARNs (not "*")
• Use Condition keys to restrict further (e.g., aws:RequestedRegion, aws:PrincipalTag)
• Prefer managed policies for common use cases; add custom policies for specific needs
• Regularly review unused permissions with IAM Access Advisor

⚠️ Exam Trap: A permission boundary does not grant permissions — it only limits them. If a role has a permission boundary allowing S3 but no identity-based policy, the role cannot access anything. Both the boundary and an identity-based policy must allow the action. This is a common confusion: candidates assume the boundary itself is an allow, but it's only a ceiling.

Reflection Question: A developer's IAM role has AdministratorAccess attached. The role also has a permission boundary that allows only s3:* and dynamodb:*. The developer tries to launch an EC2 instance. Is this allowed? Why or why not?