What Is IAM?

Every action taken inside an AWS account — creating a server, reading a file, deleting a database — has to answer two questions before AWS allows it: who is asking, and are they allowed to do this specific thing. IAM is the AWS service responsible for answering both.

Module 1 already introduced one IAM concept in passing — the root user, and the principle of least privilege. This module is where IAM itself becomes the subject, rather than a supporting mention.

These two words get used almost interchangeably in casual conversation, but IAM treats them as genuinely separate steps:

• Authentication answers "who are you?" — proving an identity is who it claims to be. Signing in with a username and password, or a workload presenting valid temporary credentials, are both authentication.
• Authorization answers "what are you allowed to do?" — once AWS knows who you are, it still has to check whether this specific identity is permitted to take this specific action on this specific resource.

Being authenticated doesn't automatically mean being authorized. A signed-in, verified IAM user can still be denied a specific action if nothing grants them permission to take it.

A useful mental model for the rest of this module:

Identity → Policy → Permission → Resource

1. An identity (a user, group, or role — all covered in this module) exists within the account.
2. A policy — a permission document — is attached to that identity.
3. The policy grants (or denies) specific permissions: which actions are allowed.
4. Those permissions apply to specific resources — a particular S3 bucket, not "all of S3" by default.

Every lesson from here builds one link in that chain: identities in the next lesson, then policies and permissions, then the discipline of keeping that chain as narrow as possible.