BeginnerIn-depth4 min readUpdated 2 Oct 2026

What is the difference between IAM users, groups, roles and policies in AWS?

SHORT ANSWER

A user is an identity for one person or app with long-term credentials. A group is a set of users that share permissions. A role is an identity that anyone or anything trusted can assume to get temporary credentials. A policy is the JSON document that says what is allowed or denied. Grant only the permissions needed, which is least privilege.

Explain it simply

Think of a company office.

A user is an employee with their own ID card. The card works until it is taken away.
A group is a department, like "Developers". Give the department access to the lab, and everyone in it gets in.
A role is a visitor badge kept at reception. The badge has fixed access. Whoever is allowed to pick it up, a contractor or a delivery robot, wears it for a few hours and returns it.
A policy is the written rulebook pinned to the card or badge: "can enter floor 3, cannot enter the server room".

IAM (Identity and Access Management) is how AWS answers two questions on every request: who are you, and are you allowed to do this?

Example

A small team building a placement app:

text

Group "developers"   -> policy: read/write the app's S3 bucket, view logs
  users: asha, rahul

Role "app-server-role" -> policy: read one S3 bucket, read one secret
  trusted by: EC2 (attached to the app servers)

Role "ci-deploy-role"  -> policy: deploy to one Lambda function
  trusted by: the CI pipeline

A minimal policy that follows least privilege:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::placement-app-resumes/*"
    }
  ]
}

It allows reading objects from one bucket, and nothing else.

How it works

Users have long-term credentials: a console password and/or access keys. Each person should have their own.
Groups only hold users and attached policies. A group cannot contain another group, and you cannot log in as a group.
Roles have no password or permanent keys. A trust policy says who may assume the role. When assumed, AWS STS hands out temporary credentials that expire. EC2 instances, Lambda functions, other AWS accounts and users signed in through a company login all use roles.
Policies are JSON with Effect (Allow or Deny), Action, Resource and optional Condition. They attach to users, groups or roles (identity-based) or to resources like S3 buckets (resource-based).
Evaluation: everything is denied by default. An explicit Allow grants access, and an explicit Deny anywhere always wins over any Allow.
The root user owns the account and can do anything. Lock it with MFA and do not use it for daily work.

Real-world use

An EC2 server or Lambda function reads from S3 using a role, so no access keys sit in the code or on the server.
Interns are added to a "read-only" group and removed when they leave.
A GitHub Actions pipeline assumes a deploy role through OIDC instead of storing long-lived keys as secrets.

Common mistakes

Pasting access keys into code and pushing them to a public GitHub repo. Bots find them within minutes.
Giving everyone AdministratorAccess "to save time".
Using "Action": "*" and "Resource": "*" in policies.
Using the root user for daily tasks or leaving it without MFA.
Creating a user for an application running on AWS instead of giving it a role.

What to say in the interview

"A user is a long-term identity for a person or app. A group lets me attach policies to many users at once. A role is assumed by trusted entities like EC2, Lambda or another account, and gives temporary credentials, so it's the right choice for applications. Policies are JSON documents of allowed or denied actions on resources. Everything is denied by default, and an explicit deny beats any allow. I follow least privilege: start with only the actions and resources a job needs, use roles instead of access keys, and keep the root user locked with MFA."

Follow-up questions

Why is a role safer than access keys for an EC2 instance?
What happens if one policy allows an action and another denies it?
What is the difference between an identity-based and a resource-based policy?
How would you give another AWS account access to your S3 bucket?

Go deeper

Read these once the basics above feel easy.

Use AWS-managed policies to start, then replace them with customer-managed policies scoped to exact resources. IAM Access Analyzer can suggest tighter policies from actual usage. Conditions such as aws:SourceIp or requiring MFA add extra checks. For people, prefer IAM Identity Center with a company login over individual IAM users.

#aws #iam #security #least-privilege