IAM Policies & Roles
IAM is the backbone of AWS security. Every action in AWS is an API call that IAM evaluates:
Policy Types (Know All 6)
| Policy Type | Attached To | Use Case | Priority |
|---|---|---|---|
| Identity-Based | Users, Groups, Roles | Grant permissions to principals | Standard |
| Resource-Based | S3 buckets, SQS, KMS keys | Cross-account access without assuming role | Standard |
| Permission Boundary | Users, Roles | Maximum permissions a role CAN have (ceiling) | Restricts other policies |
| SCP (Org-level) | AWS Organization OU/Account | Guardrails across ALL accounts (e.g., deny regions) | Overrides everything |
| Session Policy | STS AssumeRole sessions | Limit permissions for a specific session | Restricts role |
| ACL (Access Control List) | S3, VPC | Legacy cross-account (avoid β use bucket policies) | Legacy |
IAM Policy Evaluation Logic
- Explicit Deny? β DENY (always wins, cannot be overridden)
- SCP allows? β If no, DENY
- Resource-based policy allows? β If yes, ALLOW
- Identity-based policy allows? β If yes, check Permissions Boundary
- Permission Boundary allows? β If yes, ALLOW
- Nothing matches? β DENY (implicit deny)
Roles vs Users β The Rule
Never use long-term credentials (access keys). Use IAM Roles everywhere: EC2 instance profiles, ECS task roles, Lambda execution roles, cross-account roles. Only use IAM users for CLI access by humans, with MFA enforced.
π― Key Takeaway
Interview tip: "I follow least-privilege: start with zero permissions, add only what's needed. I use IAM Roles (not users) for all services, SCPs as guardrails at the org level, and Permission Boundaries to limit what developers can create. Explicit deny always wins in policy evaluation."