Users, Groups, Roles, and Policies
Learn the IAM building blocks and the permission evaluation rules that explain most AccessDenied errors.
All services used in this lesson are covered by the AWS Free Tier.
AWS Services Used
The IAM mental model
Every AWS API call — from the Console, CLI, or an application — passes through the same evaluation engine. AWS asks five questions in sequence:
- Who is making the request? (the principal)
- What are they trying to do? (the action)
- On which resource? (e.g. a specific S3 bucket or EC2 instance)
- Under what conditions? (MFA required, IP range, resource tags, time of day)
- Is it explicitly allowed, explicitly denied, or neither?
Authentication vs Authorization
These two concepts are the foundation of IAM:
| Authentication | Authorization | |
|---|---|---|
| Question answered | Who are you? | What can you do? |
| Mechanism | Credentials (password, MFA, key) | Attached policies |
| Order | Happens first | Happens second |
IAM handles both in sequence: it verifies your identity, then evaluates your permissions.
The IAM building blocks
IAM user — A named identity for a specific person or application, used for direct sign-in or programmatic access.
IAM group — A collection of IAM users. Attach one policy to the group instead of to each user individually. Groups do not have credentials of their own.
IAM role — An identity designed to be assumed rather than signed into. Provides temporary, auto-expiring credentials for humans, applications, or AWS services.
Policy — A JSON document defining allowed and denied actions. Can be attached to an identity (user, group, role) or directly to a resource.
How policies work
A policy is a JSON document that tells AWS what is allowed and what is denied. A single policy contains one or more statements. Each statement has four parts:
| Part | Required? | What it controls |
|---|---|---|
| Effect | Yes | Allow or Deny — the decision |
| Action | Yes | Which API calls are covered (e.g. s3:GetObject) |
| Resource | Yes | Which specific resources it applies to |
| Condition | No | Extra constraints (e.g. require MFA, specific IP range) |
The 3 rules that explain most "AccessDenied" errors
Policy evaluation is deep, but you can go very far with these rules:
- Default deny: If nothing allows it, it is denied
- Explicit allow overrides default deny: An Allow can grant permission
- Explicit deny always wins: If any applicable policy says Deny, the request is denied even if another policy allows it
Note
That is why you often see AccessDenied errors: the system is secure by default. If you get this error, check what policies are attached and whether the action is explicitly allowed.
Best practices
AWS recommends using IAM roles and temporary credentials for human users and workloads when possible, instead of long-term access keys.
Tip
For teams, schools, or multi-account setups: AWS recommends IAM Identity Center as the approach for workforce access management across accounts. For a single learning account, you can learn IAM concepts directly, but keep "roles and temporary credentials" as the direction you are heading.
Micro-activity 1: Identify the principal
Micro-activity 2: Read a real policy
This is a real IAM policy statement. Read it carefully, then answer the questions below.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::example-bucket/public/*"]
}
]
}Summary
- IAM is how AWS decides who can do what
- Policies are JSON permission documents attached to identities or resources
- Default deny is the starting point, and explicit deny overrides allow
- Prefer roles and temporary credentials over long-term access keys when possible