AWS IAM Explained: Users, Groups, Roles, and Policies

AWS Identity and Access Management (IAM) controls who can do what in an AWS account. It has four building blocks: users are long-term identities for a person or application, groups are collections of users that share permissions, roles are identities that are assumed temporarily instead of owned, and policies are the JSON documents that actually grant or deny permissions. Nothing in IAM has any permissions until a policy says so, because AWS denies everything by default.

What IAM is, and what it costs

IAM is a global service. Users, groups, roles, and policies are not tied to a Region; an IAM user created once exists across every AWS Region in the account. IAM itself is free. You pay for what identities do (the EC2 instances they launch, the S3 storage they consume), never for the identities themselves.

Every request to AWS, whether from the Management Console, the Command Line Interface (CLI), or an SDK, is evaluated against IAM. The evaluation logic matters for the exam: by default everything is implicitly denied, an Allow statement in an applicable policy grants access, and an explicit Deny anywhere overrides every Allow. Deny always wins.

Users: long-term identities for people and applications

An IAM user represents one person or one application that needs long-term credentials. A user can have a password for console sign-in, and up to two access keys (an access key ID plus secret access key pair) for programmatic access through the CLI or an API. Best practice is one user per human, never shared credentials, with multi-factor authentication (MFA) enabled on top of the password.

The IAM user is a different animal from the account root user, which is the identity created when the AWS account itself was opened. The root user has unrestricted power and should be locked away, not used day to day; the details live in the root user best-practices article. Everyday work belongs to IAM identities with scoped permissions.

Worth knowing at the awareness level: AWS now steers organizations toward AWS IAM Identity Center for human sign-in, which provides single sign-on and temporary credentials across multiple accounts. IAM users remain the CLF-C02 foundation, but “centralized workforce access across many accounts” points to IAM Identity Center.

Groups: permission bundles for users

An IAM group is a collection of IAM users. Attach a policy to the group and every member inherits those permissions. This is how you manage permissions at scale: build a Developers group, an Admins group, a Billing group, and move users between them as jobs change, instead of editing permissions user by user.

Three group facts the exam checks: a user can belong to multiple groups, groups cannot be nested inside other groups, and a group is not an identity you can sign in as or reference as a principal. Groups exist purely to attach policies to many users at once.

Roles: temporary, assumable identities

An IAM role is an identity with permissions but no long-term credentials. Nobody “owns” a role; trusted entities assume it and receive temporary security credentials that expire automatically. This is the mechanism behind almost every “no hardcoded credentials” answer on the exam.

The canonical scenarios:

• An application on EC2 needs to reach S3. Attach a role to the instance. The application picks up temporary credentials automatically. Storing access keys on the instance is always the wrong answer.
• An AWS service needs to act on your behalf. Lambda functions, ECS tasks, and CloudFormation stacks all execute with roles.
• Cross-account access. A user in account A assumes a role in account B rather than being given a second set of credentials.
• Federation. Users from an external identity provider assume roles instead of becoming IAM users.

Each role has two policy attachments: a trust policy defining who may assume it, and permissions policies defining what the assumer can do.

Policies: where permissions actually live

A policy is a JSON document made of statements, each with an Effect (Allow or Deny), an Action (the API operations, like s3:GetObject), and a Resource (what it applies to, usually by Amazon Resource Name). Identity-based policies attach to users, groups, and roles. Resource-based policies attach to the resource itself; an S3 bucket policy is the everyday example.

Policies come in three management flavors: AWS managed policies (prebuilt and maintained by AWS, such as AdministratorAccess), customer managed policies (you write and reuse them), and inline policies (embedded in a single identity, deleted with it).

The principle that governs all of it is least privilege: grant only the permissions a task requires, and nothing more. When an exam answer choice grants broad access “for convenience,” it is bait.

	User	Group	Role
Represents	One person or application	A set of users	A temporary, assumable identity
Credentials	Long-term (password, access keys)	None	Temporary, issued at assumption
Can sign in	Yes	No	No (assumed, not signed into)
Policies attach	Yes	Yes	Yes (plus a trust policy)
Typical use	Individual long-term access	Permission management at scale	EC2 apps, AWS services, cross-account, federation

How the CLF-C02 exam tests this

• An application on an EC2 instance must access another AWS service “securely” or “without storing credentials.” The answer is an IAM role attached to the instance, never access keys in a file or in code.
• A company wants to grant the same permissions to a set of employees efficiently, or new hires must receive standard permissions automatically. The answer is IAM groups with attached policies.
• A question asks which security practice to apply when granting permissions. The answer invokes least privilege: the narrowest policy that still allows the task.
• A stem asks what kind of service IAM is, or whether identities must be recreated per Region. IAM is global, and it is free.
• A scenario mixes root user tasks with everyday administration. Daily work goes to IAM identities; the root user is reserved for the handful of tasks only it can perform.

Quick reference

• IAM is global and free; you pay for resource usage, not identities.
• Everything is denied by default; explicit Deny overrides any Allow.
• Users hold long-term credentials; enable MFA and never share them.
• Groups bundle users for policy attachment; no nesting, no signing in as a group.
• Roles provide temporary credentials; the answer for EC2 apps, AWS services, cross-account access, and federation.
• Policies are JSON (Effect, Action, Resource); AWS managed, customer managed, or inline.
• Least privilege is the standing rule for every grant.
• IAM Identity Center is the modern path for centralized human sign-on across accounts.