Ravindra BagaleCourses & study guides मराठी Track your progress

What Is an AWS IAM Role and When to Use It

An IAM role is a temporary jacket. A person or a service puts it on, gets short-lived keys, does the job, and takes it off. No permanent access key stuck on a laptop.

What you'll learn in this chapter

  • Role vs user vs group
  • Trust policy vs permissions policy
  • Who uses roles: EC2, Lambda, humans
  • When a role beats an IAM user
  • Cross-account role idea

1. Everyday example first

Why do we need this?

At Infosys Pune, a visitor does not get a permanent office badge. Security gives a time-bound visitor pass for one floor. AWS roles work the same way — temporary permission, not a lifelong key.

The names and floors in this story are made up for learning.

What is it?

An IAM role is an identity that has no long-lived password or access key of its own. Someone (or something) assumes the role and receives temporary credentials from STS.

IdentityLives how long?Typical use
IAM userUntil you delete itNamed human (older style)
GroupUntil you delete itBundle of policies for many users
RoleCredentials expire (minutes–hours)EC2, Lambda, SSO, cross-account

2. Two policies on every role

Why do we need this?

Beginners mix these up in interviews. One answers “who may wear the jacket”. The other answers “what the jacket can do”.

What is it?

  • Trust policy (resource-based on the role): who can call sts:AssumeRole — e.g. EC2, Lambda, another account, SAML/OIDC.
  • Permissions policy (identity): Allow/Deny actions on resources — e.g. s3:GetObject on one bucket.
  • Without trust, nobody can assume. Without permissions, the assumed session can do almost nothing useful.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

That trust snippet says: only the EC2 service may assume this role. Attach a separate permissions policy for S3/DynamoDB/etc.

3. When to use a role

  1. EC2 / ECS / Lambda — never put access keys in code or on disk. Attach a role.
  2. Humans via Identity Center (SSO) — user picks a permission set; AWS issues temporary role credentials.
  3. Cross-account — Account A trusts Account B’s admin (or a role) to assume a role in A.
  4. Break-glass admin — rare high-power role with MFA and logging, not daily AdministratorAccess on a user.

Ravindra Bagale's Tip

Students often create an IAM user with AdministratorAccess and paste keys into .env. Prefer a role (or Identity Center). Keys leak; role sessions expire.

4. Interview angles

Q. User vs role?

User has long-lived creds; role is assumed for temporary creds.

Q. Trust vs permissions?

Trust = who may assume; permissions = what the session can do.

Q. Why roles on EC2?

Instance metadata hands rotating creds; no keys on disk.

Q. Can a role have a password?

No. You assume it; you do not “log in as the role” with a password.

Q. Cross-account role?

Trust policy Principal is another account (or role ARN).

Try at home

  1. Open IAM → Roles and read the trust policy of any lab role you already have.
  2. Next: learn STS AssumeRole and session tokens.

In short

  1. A role is temporary credentials via AssumeRole.
  2. Trust policy ≠ permissions policy.
  3. Prefer roles over long-lived keys for compute.
  4. Identity Center uses roles under the hood for humans.

Practice Tasks

About this scenario

Aurangabad Pharma is a pharmaceuticals business in Chhatrapati Sambhajinagar. Dr. Farhan Shaikh looks after its IT and cloud work. They count money in INR and run their AWS resources in the ap-south-1 Region. In the tasks below you do real jobs for them using what this lesson teaches. All names, account IDs, IP addresses and numbers are made up for practice.

0 / 12

Medium Trust policy for an EC2 role

Why: The trust policy says WHO may take the role.

What to do: Write a trust policy that lets ec2.amazonaws.com assume the role.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Medium Trust policy for a Lambda role

Why: The trust policy says WHO may take the role.

What to do: Write a trust policy that lets lambda.amazonaws.com assume the role.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Medium Attach a policy to a role

Why: The role needs permissions: attach a policy to say what it may do.

What to do: Attach arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess to role abadpharma-ec2-role.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Let a function write logs

Why: Without these actions, Lambda logs never appear in CloudWatch.

What to do: Allow logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents on arn:aws:logs:*:*:* only.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Medium Assume a role

Why: AssumeRole gives you short-lived keys for another role, often in another account.

What to do: Assume role arn:aws:iam::112055250461:role/Auditor with session name farhan-audit.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Trust policy for an ECS task role

Why: The trust policy says WHO may take the role.

What to do: Write a trust policy that lets ecs-tasks.amazonaws.com assume the role.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Hard Let another account assume a role

Why: Cross-account roles are safer than sharing access keys.

What to do: Write a trust policy that lets account 111122223333 assume this role.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Hard Allow PassRole for one role

Why: To launch EC2 with a role, the user needs iam:PassRole on that role.

What to do: Allow iam:PassRole on arn:aws:iam::112055250461:role/abadpharma-ec2-role only.

How:
  1. Start with { "Version": "2012-10-17", "Statement": [ ... ] }.
  2. In each statement write Effect, Action and Resource.
  3. Give only what the task needs (least privilege).
  4. Use double quotes and commas correctly. Click Check answer.

Hard Put the role in the instance profile

Why: The profile is empty until you add the role to it.

What to do: Add role abadpharma-ec2-role to instance profile abadpharma-ec2-profile.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Hard Create an instance profile

Why: EC2 uses a role through an instance profile, a small wrapper around the role.

What to do: Create an instance profile named abadpharma-ec2-profile.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Hard Create a role with a trust policy

Why: A role is an identity that services or people "assume". The trust policy says who may assume it.

What to do: Create a role named abadpharma-ec2-role using the trust policy in trust.json.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Hard Give a running EC2 its role

Why: With the profile attached, apps on the server get temporary keys automatically.

What to do: Associate instance profile abadpharma-ec2-profile with instance i-01a40525502111a2b.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

Revision card: What is an IAM role?. At Infosys Pune a visitor gets a time-bound pass for one floor — not a lifelong office badge. Compute needs the same pattern. An IAM role is an identity with no long-lived password or access key. A caller assumes it and STS returns temporary credentials. Create the role, attach a permissions policy, set a trust policy for who may assume, then let EC2/Lambda/CLI assume it. An EC2 instance profile role lets the instance call S3 with rotating keys from the metadata service — no keys on disk.
Revision card: What is an IAM role? · Download PNG · Open card page
Revision card: Trust vs permissions policy. Mixing “who may wear the jacket” with “what the jacket allows” causes AccessDenied you cannot debug. Trust policy (resource-based on the role) lists who may AssumeRole. Permissions policy lists Actions/Resources the session may call. Edit trust Principal (user/role/service ARN or account). Attach customer-managed permissions separately. Trust Principal = your IAM user; permissions allow s3:GetObject on one lab bucket only.
Revision card: Trust vs permissions policy · Download PNG · Open card page
Revision card: When to use a role. Long-lived access keys on EC2 or in GitHub are how student accounts get hijacked. Prefer roles for EC2, Lambda, cross-account access, and humans via Identity Center. Use IAM users sparingly for break-glass or old tools. Attach an instance profile / execution role / permission set instead of creating an access key. Lambda reads DynamoDB with its execution role; you never paste a secret key into the function code.
Revision card: When to use a role · Download PNG · Open card page
Comparison: IAM role vs IAM user. IAM role: No long-lived password/key; assumed for temporary STS credentials. IAM user: Named identity with password and/or long-lived access keys until deleted.
Comparison: IAM role vs IAM user · Download PNG · Open card page
Interview card: User vs role — what is the difference?. An IAM user is a named long-lived identity (password and/or access keys until you delete them). An IAM role has no long-lived password/key; you assume it for temporary STS credentials. Long-lived keys on disks and in Git history are a common breach path. Roles rotate automatically via STS and shrink blast radius when leaked. EC2 and Lambda use roles (instance profile / execution role). Humans increasingly use Identity Center, which also assumes roles under the hood.
Interview card: User vs role — what is the difference? · Download PNG · Open card page
Interview card: Trust policy vs permissions policy?. Trust policy answers who may call sts:AssumeRole on this role. Permissions policy answers what API actions the resulting session may perform on which resources. A perfect S3 permissions policy still fails if trust Principal does not include the caller. Wrong trust is a top lab AccessDenied cause. Example: trust Principal = arn:aws:iam::111:user/ravi; permissions Resource = arn:aws:s3:::lab-bucket/* with s3:GetObject.
Interview card: Trust policy vs permissions policy? · Download PNG · Open card page

More cards: Ravi Sir's Cards.