Identity and Access Management

One password, the whole account

Say a company gives every new developer the AWS account's root user password so nobody has to wait on IT to grant access. It is fast, and for months nothing goes wrong. Then a laptop with that password saved in a browser is stolen from a coffee shop. Whoever has it can now launch instances, read every stored file, delete every backup, and change billing details, because the root user has no limits at all.

Identity and access management exists to make that scenario much smaller. Instead of one shared, all-powerful credential, IAM lets a team hand each person and each application its own identity, scoped to exactly what that identity needs to do. A stolen laptop then exposes one narrow slice of the account, not the whole thing.

Root user, IAM users, and roles

Every AWS account starts with a single root user, created automatically, with unrestricted access to everything. AWS's own guidance is blunt about it: don't use the root user for everyday tasks, lock its credentials away, and set up other identities for actual work.

Two of those other identities matter most. An IAM user is a persistent identity, typically for a specific person or an application that needs standing access, with credentials that last until someone rotates or revokes them. A role is different: it's an identity with no credentials of its own, assumed temporarily by a user, an application, or an AWS service, which receives short-lived, auto-expiring credentials for the duration of that session. Modern practice leans hard toward roles precisely because there is nothing long-lived to leak.

Two separate checks: authentication, then authorization

Picture a developer signing in with a password and an MFA code, then requesting to launch a new virtual machine. AWS runs two distinct checks, in order, not one combined check.

First, authentication: does this password and MFA code match a real identity trusted by this account? If yes, the identity is confirmed. Second, and separately, authorization: does the confirmed identity's attached policy actually permit launching an instance? A user can pass authentication perfectly, with a correct password and a valid MFA code, and still be denied at authorization if their policy doesn't grant that action. The two checks protect against different failures: a stolen password defeats authentication, while a policy that grants too much defeats authorization even when authentication is working exactly as intended.

Least privilege: start narrow, not broad

Say a developer's role needs to read files from one reporting bucket and nothing else. A least-privilege policy grants exactly that: the s3:GetObject action, scoped to that one bucket, no more. Compare that to a broad policy granting full S3 access "to be safe": if that role's credentials are ever misused, the narrow policy limits the damage to one bucket's read access, while the broad one hands over every bucket in the account.

Least privilege is a direction to move in, not a one-time setting. AWS's own guidance recommends starting with a broader managed policy while a team explores what a new workload actually needs, then narrowing it down as usage patterns become clear, using tools that analyze real access activity to generate a tighter policy automatically. Teams that never revisit that first broad policy are the ones an audit flags.

The boundary: groups versus roles

These two get confused because both let more than one entity share a set of permissions, but they solve different problems. A group is a collection of IAM users, useful for granting the same policies to, say, everyone on a data team, without attaching that policy to each user individually. A role is not a collection of anything; it's a single identity that different principals can temporarily assume, one at a time, receiving credentials that expire. Ask which question the scenario poses: "grant the same standing permissions to several people" points to a group; "let this application or this person temporarily act as a specific identity" points to a role.

Misconception: a strong password is enough

It's tempting to think a long, unique password is sufficient protection for an account. It is not: passwords get phished, reused across breached sites, or captured by malware regardless of how strong they are. MFA closes that gap by requiring a second factor, something the account holder has or generates, that a stolen password alone cannot satisfy. AWS specifically recommends phishing-resistant MFA, like security keys or passkeys, over one-time codes sent by text, since even the code itself can sometimes be intercepted or the workflow tricked.

Exam cues: matching the scenario to the tool

Where this leaves you

Identity is the row on the shared-responsibility table that never moves to the provider, and IAM is the toolset that lets you actually own it: confirm who's asking with authentication, decide what they can do with authorization, and keep both narrow with least privilege and roles instead of standing, all-powerful credentials. Knowing who's allowed to touch your data solves half the problem. The next lesson covers what protects that data even if someone gets past every one of these checks: encryption.