Users, Groups & Policies

In one line

An IAM user is an identity, a group is a way to attach the same permissions to many users at once, and a policy is a JSON document that says exactly which actions are allowed or denied on which resources.

0/4 · 0%

Think of it like this

An office building. Each employee gets a badge (an IAM USER). Badges are grouped by department (IAM GROUPS — 'Engineering', 'Finance'). Each department has a written rulebook of which doors that badge opens (a POLICY). You don't program every badge individually — you put a person in a department and the department's rules apply.

Key ideas

01
An IAM USER is a long-lived identity for a person (or, historically, an application) — it can have a console password, access keys for the CLI/SDK, or both. A brand-new user has ZERO permissions: IAM is deny-by-default.
02
A POLICY is a JSON document made of STATEMENTS, each with Effect (Allow or Deny), Action (e.g. s3:GetObject), Resource (an ARN — Topic 0.4 — like arn:aws:s3:::my-bucket/*), and an optional Condition (e.g. only from a specific IP, only with MFA present).
03
Policy EVALUATION follows three rules, in this order: (1) an explicit Deny anywhere always wins; (2) otherwise, an explicit Allow grants access; (3) otherwise, the default is an implicit deny. This is why you can safely grant broad access via one policy and carve out a hard exception with a Deny in another.
04
AWS MANAGED policies (like ReadOnlyAccess, AmazonS3FullAccess) are pre-written and maintained by AWS — convenient for getting started but usually far broader than you need. CUSTOMER MANAGED policies are ones you write and version yourself — what production accounts should mostly use. INLINE policies are embedded directly in one user/group/role and can't be reused; use them sparingly.
05
Attach policies to GROUPS, not individual users. When someone changes teams you move them between groups instead of hunting down a dozen individually-attached policies — the same reason you'd never hand-edit badge permissions per employee.

Code & diagrams

read-only-one-bucket.jsonjson

A customer-managed policy scoped to exactly one bucket. Note ListBucket targets the bucket ARN, GetObject targets the objects inside it — a very common mistake is using the wrong one.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-reports"
    },
    {
      "Sid": "ReadObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::acme-reports/*"
    }
  ]
}

groups.shbash

# Create a group, attach the policy to the GROUP, then add users to it
aws iam create-group --group-name report-readers

aws iam create-policy \
  --policy-name ReadAcmeReports \
  --policy-document file://read-only-one-bucket.json

aws iam attach-group-policy \
  --group-name report-readers \
  --policy-arn arn:aws:iam::123456789012:policy/ReadAcmeReports

aws iam add-user-to-group --group-name report-readers --user-name priya

# What does priya actually have? (groups + directly attached)
aws iam list-groups-for-user --user-name priya
aws iam list-attached-user-policies --user-name priya

PolicyEvaluationdiagram

The order every request is checked in. Explicit Deny short-circuits everything.

Rendering diagram…

Explain it without notes

A user is in two groups. Group A's policy allows s3:* on all buckets. Group B's policy denies s3:DeleteObject on arn:aws:s3:::prod-backups/*. Can the user delete an object in prod-backups? Why?

Why is attaching policies to groups rather than directly to users the recommended practice?

Practice

Write a policy statement that allows s3:PutObject into arn:aws:s3:::uploads/* but ONLY when the request comes over HTTPS.

A colleague's policy grants s3:GetObject on arn:aws:s3:::acme-reports (no /*), and they get AccessDenied reading a file. What's wrong?

Trade-offs

↔
AWS managed policies are fast to adopt and kept up to date by AWS as new actions appear, but they're written for the general case and almost always grant more than you need; customer managed policies cost you maintenance effort but let you grant exactly what a team actually uses.

Done when you can

I can read a policy document and identify Effect, Action, Resource, and Condition.
I can state the three-step evaluation order and why explicit Deny always wins.
I know the difference between AWS managed, customer managed, and inline policies.
I attach permissions to groups, not individual users.