AWS IAM Explained for Beginners: Users, Roles, Policies, and Real Examples

IAM is the AWS topic that beginners avoid until it blocks everything. That is a mistake. IAM is not a side topic. It is the permission system behind almost every useful AWS workflow, and it shows up in both real projects and certification exams constantly.

The good news is that IAM gets simpler once you use the right mental model: who can do what, to which resource, under which conditions. If you can answer those four questions, most IAM problems stop feeling abstract.

The Core IAM Mental Model

If you read policies through that lens, AWS IAM stops looking like random JSON and starts looking like decision logic.

Users, Roles, and Groups

IAM users

Use IAM users sparingly. They represent a person or workload with long-lived credentials. In modern AWS accounts, that is rarely the best default.

IAM roles

Roles are usually the right answer. A role has no long-term password or access keys. Instead, something assumes the role temporarily. That is why roles are the standard for Lambda execution, EC2 instance profiles, cross-account access, and identity federation.

IAM groups

Groups are simply a way to attach the same permissions to multiple users. They are useful, but they matter less in modern AWS environments than roles do.

The Two Policy Types Beginners Must Understand

Identity-based policies

These are attached to a user, group, or role. They describe what that identity can do.

Resource-based policies

These are attached directly to services like S3, Lambda, and KMS. They describe who can access that resource.

When you are stuck, ask whether the permission belongs on the identity or the resource. That one question resolves a surprising number of AWS exam scenarios.

The Practical Rules

Rule 1: Explicit deny wins

If any applicable policy says Deny, the request is denied.

Rule 2: No allow means deny

AWS does not assume access should exist. If there is no matching allow, the answer is no.

Rule 3: Roles beat hardcoded credentials

If a question offers a choice between storing access keys in code and using a role, choose the role.

Rule 4: Least privilege is not optional

Start with the narrowest permissions that let the job work. Expand only when you have evidence.

Common Real-World Patterns

Lambda execution role

Your function needs permission to write logs and call other services. That permission belongs on the Lambda execution role, not on a human user.

EC2 instance profile

If an EC2 instance needs S3 or DynamoDB access, attach a role to the instance. Do not put access keys in environment variables.

Cross-account access

One account assumes a role in another account. This is the cleanest way to share access between accounts while keeping permission boundaries explicit.

What IAM Means for Certification Study

IAM matters because it is tested everywhere. If you are working toward AWS certifications, especially associate-level exams, this guide should sit alongside the 2026 certification roadmap, the Solutions Architect Associate study guide, and the Developer Associate guide.

Here is the quick mapping:

• Cloud Practitioner: identity basics, shared responsibility, root user safety
• Solutions Architect Associate: IAM plus encryption, cross-account access, least privilege design
• Developer Associate: roles, STS, resource policies, Lambda execution permissions

Beginner Mistakes to Avoid

Using the root user for daily work

Do the account setup, secure it, then stop using it. Create an admin path that does not rely on the root identity.

Making policies too broad

"Action": "*" and "Resource": "*" are convenient, but they create security debt immediately.

Forgetting the trust policy

Many beginners understand permissions but miss the trust relationship on a role. If a principal cannot assume the role, the permission policy never gets a chance to matter.

Guessing instead of reading the error

AWS permission errors are often specific. Read the action, resource, and principal in the error before changing anything.

A Good Learning Sequence

If IAM still feels abstract, use this order:

1. Learn users, groups, and roles.
2. Learn identity-based versus resource-based policies.
3. Learn how Lambda and EC2 consume roles.
4. Practice reading AccessDenied errors.
5. Return to certification scenarios after the mechanics feel normal.

That sequence makes the architecture guides much easier to absorb, especially the SAA guide and the DVA guide.

Recommendation

Treat IAM as a first-week topic, not an advanced topic. If you master the mental model early, the rest of AWS becomes easier to reason about and your exam prep becomes much less fragile.