Q: What is the difference between AWS IAM Roles vs IAM Policies?
Master AWS iam roles vs iam policies: key architectural differences, identity vs resource policies, trust policies, STS AssumeRole, and IRSA in Kubernetes.
Want to master this scenario in a live sandbox? Stephane Maarek's AWS Certified DevOps Engineer Professional Masterclass on Udemy covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
Direct Answer: In AWS cloud security interviews, understanding the exact distinction of iam roles vs iam policies is foundational. When asked this question, I explain the fundamental relationship: IAM Policies define WHAT permissions are allowed or denied, while IAM Roles define an IDENTITY that can be assumed temporarily by trusted entities.
The Core Conceptual Distinction: IAM Roles vs IAM Policies
An IAM Policy is a passive JSON document that outlines explicit permissions (Allow/Deny actions on AWS resources). An IAM Role is an active AWS identity that has no permanent credentials and must be assumed by a trusted principal (EC2, Lambda, GitHub Actions, or Kubernetes pods).
- IAM Policy: WHAT can be done (e.g.
s3:GetObjecton bucketfinance-data). - IAM Role: WHO is doing it (an assumed identity receiving temporary STS credentials).
Deep Dive into IAM Policies: Types & Evaluation Logic
IAM Policies specify Effect (Allow/Deny), Action, Resource, and Condition. They are categorized into Identity-Based Policies, Resource-Based Policies, and Guardrails.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3Read",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::my-company-reports",
"arn:aws:s3:::my-company-reports/*"
],
"Condition": {
"Bool": {"aws:SecureTransport": "true"}
}
}
]
}- Identity-Based Policies: Attached to IAM Users, Groups, or Roles.
- Resource-Based Policies: Attached directly to AWS resources (S3 bucket policies, KMS key policies).
- Evaluation Logic: Default Deny -> Any explicit Deny wins -> Explicit Allow required -> Final decision.
Anatomy of an IAM Role: Trust Policy vs Permissions Policy
Every IAM Role requires TWO distinct policies to function: a Trust Policy (AssumeRolePolicyDocument) and one or more Permissions Policies.
# Trust Policy (Who can assume this role?)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}- Trust Policy: Defines WHICH principal (AWS Service, IAM User, external OIDC provider) is allowed to call
sts:AssumeRole. - Permissions Policy: Defines WHAT AWS actions the assumed role can perform once assumed.
Temporary Credentials via AWS STS (Security Token Service)
Unlike IAM Users which rely on dangerous, static access keys (AKIA...), IAM Roles never have permanent passwords or access keys. They generate short-lived, auto-expiring credentials via AWS STS.
# Calling STS AssumeRole via AWS CLI
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/DeployerRole \
--role-session-name cicd-deploy
# Returns: AccessKeyId (ASIA...), SecretAccessKey, and SessionToken (expires in 1h)- Credential Prefix: Permanent keys start with
AKIA; temporary STS keys start withASIA. - Zero Key Rotation: Credentials expire automatically (15 minutes to 12 hours), eliminating the risk of leaked permanent keys.
Comprehensive Decision Matrix: IAM Roles vs IAM Policies
Architectural comparison contrasting IAM Roles vs IAM Policies across critical security parameters:
- Policy is a Document: An IAM Policy is a JSON document declaring explicit Allow or Deny actions on specific AWS resources.
- Role is an Identity: An IAM Role is an AWS identity with no permanent credentials, assumed by trusted principals (EC2, Lambda, EKS pods).
- Two Policies in Every Role: A Role requires a Trust Policy (who can assume it via sts:AssumeRole) and a Permissions Policy (what it can do).
- Temporary STS Credentials: Roles issue auto-expiring temporary tokens (ASIA...) via AWS STS, eliminating static key leakage.
- Production Patterns: Used everywhere in production: EC2 Instance Profiles, GitHub Actions OIDC pipelines, and EKS IAM Roles for Service Accounts (IRSA).
Senior hiring managers and bar raisers evaluate how you prioritize during outages. Avoid these common anti-patterns:
- Creating IAM Users with static access keys for EC2 applications Static keys embedded in config files leak into git or logs; always attach an IAM Role via an EC2 Instance Profile instead.
- Forgetting the Trust Policy when creating an IAM Role Without an explicit Trust Policy granting sts:AssumeRole to the principal, the role cannot be assumed by any service or user.
- Using wildcard '*' for Actions and Resources in production policies Granting Action: '*' and Resource: '*' grants full administrator rights, violating least privilege and failing security audits.
- Confusing Resource-Based Policies with IAM Roles An S3 bucket policy is an IAM policy attached to a bucket; it is not an identity that can be assumed by applications.