🔐 IAM Roles & Policies
Core Concepts
- IAM User - Long-term credentials for a person or application
- IAM Group - Collection of users sharing the same permissions
- IAM Role - Temporary credentials assumed by users, services, or applications
- IAM Policy - JSON document defining allowed/denied actions on resources
Policy Types
| Type | Description |
|---|
| Identity-based | Attached to users, groups, or roles |
| Resource-based | Attached to resources (e.g. S3 bucket policy) |
| Permission boundary | Max permissions an identity can have |
| SCP (Service Control Policy) | Org-level guardrails via AWS Organizations |
| Session policy | Passed when assuming a role |
Policy Structure
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringEquals": { "aws:RequestedRegion": "us-east-1" }
}
}
]
}
IAM Roles — Key Use Cases
- EC2 Instance Role - Grant EC2 access to AWS services without hardcoding credentials
- Cross-Account Role - Allow another AWS account to access your resources
- Service Role - Allow AWS services (Lambda, ECS) to act on your behalf
- Federation - Allow external identity providers (SAML, OIDC) to assume roles
Best Practices
- Apply least privilege — only grant what’s needed
- Use roles over long-term credentials wherever possible
- Enable MFA for privileged users
- Use permission boundaries to delegate safely
- Rotate access keys regularly
- Use AWS Organizations SCPs for account-level guardrails
- Audit with IAM Access Analyzer and CloudTrail
Evaluation Logic
- Explicit Deny → always wins
- Explicit Allow → permitted
- Implicit Deny → default if no allow matches
Common Exam Scenarios
- EC2 needs S3 access → attach an instance role, not access keys
- Lambda needs DynamoDB access → attach an execution role
- Cross-account access → role assumption with trust policy
- Restrict what a developer can do → permission boundary
- Org-wide restriction → SCP