AWS Access Management Capabilities (IAM)
Identify AWS access management capabilities
What you will learn
- Distinguish an IAM user, an IAM group, and an IAM role by purpose.
- Explain what an IAM policy is and how it attaches to an identity.
- State the permission evaluation rule: an explicit deny beats any allow.
- Pick the right tool (user, group, or role) for a given scenario.
Every request in AWS — uploading a file, launching an instance, deleting a database — passes through an IAM check first: who are you, and do you have permission for exactly this action on exactly this resource? The answer comes from a combination of four elements: users, groups, roles, and policies.
The four elements
| IAM User | A permanent identity representing a specific person or application, with fixed credentials. |
|---|---|
| IAM Group | A collection of users to which policies are attached in bulk — not something assumed as an identity itself. |
| IAM Role | An identity with temporary permissions assumed without permanent credentials — for applications or temporary cross-account access. |
| IAM Policy | A JSON document explicitly stating which actions are allowed or denied on which resources — attached to a user, group, or role. |
How a request's permission is evaluated
Default deny
Everything is denied by default unless explicitly allowed.
Check every attached policy
Directly on the identity, via a group, or through an assumed role.
An explicit deny always wins
If an explicit "Deny" exists in any policy, no other "Allow" can override it.
Groups vs. roles
| IAM Group | IAM Role | |
|---|---|---|
| Assumed as an identity? | No — just a way to organize policies for real users | Yes — an actual identity issued temporary credentials when assumed |
| Typical use | Grouping users with the same job (e.g., a developer team) | Giving an application running on EC2 access to S3 without permanent keys |
What matters on the exam
- An explicit deny always wins over any allow — this point is tested directly and frequently.
- A group is never assumed as an identity — an application cannot "assume a group," but it can assume a role.
Users are not exclusively for humans
It's common to believe "users are for humans, roles are for applications" is a strict rule — in reality, an IAM user can also be created for an application, but best practice recommends roles for applications to avoid storing permanent keys in code.
Quick check
Answer in your head first, then reveal.
What wins if an "allow" and an "explicit deny" conflict across two different policies?Reveal the answer
The explicit deny always wins.
Can an IAM group be assumed as an identity directly?Reveal the answer
No — a group is only a policy grouping; roles are what get assumed.
What format is an IAM policy written in?Reveal the answer
JSON.
Sign in to track your progress on this topic.
Your next step
Read the lesson, then mark it complete
Sources
Used to verify the facts. The writing is original to Passuit.