AWS IAM Explained: Users, Groups, Roles, Policies & Root User Best Practices

AWS Identity and Access Management (IAM) is the service that controls who can access your AWS account and what they are allowed to do once inside. Every request to AWS — a console click, a CLI command, an API call from an application — passes through IAM, which answers two separate questions. Authentication asks "who are you?" and is proved with credentials: a password, an access key pair, or temporary credentials from an assumed role. Authorization asks "are you allowed to do this?" and is answered by evaluating policies. The exam expects you to keep these two ideas distinct: MFA strengthens authentication; policies define authorization.

Two facts about IAM itself appear regularly as answer options. First, IAM is a global service — an IAM user or role exists once per account and works in every AWS Region; you do not create a separate user per Region. Second, IAM is free. There is no charge for creating users, groups, roles, or policies; you pay only for what those identities actually use.

By default, IAM follows an implicit-deny model: a brand-new IAM user can authenticate but can do nothing until a policy explicitly allows an action. An explicit deny in any applicable policy always overrides any allow. You will not be asked to evaluate complex policy documents at the Cloud Practitioner level, but you should recognize this deny-by-default posture because it is the mechanism that makes least privilege — covered below — achievable in the first place.

IAM manages access within your account. How responsibility for security divides between you and AWS is the shared responsibility model, a separate task statement; here it is enough to know that configuring IAM correctly is always the customer's job.

Nearly every Task 2.3 question reduces to picking the right identity type. Learn these four definitions cold.

An IAM user is an identity with long-term credentials — a console password and/or access keys — representing one person or one application. A group is a collection of users; you attach policies to the group and every member inherits them. Groups cannot be nested and cannot themselves sign in — they exist purely to manage permissions at scale. A role is an identity that is assumed temporarily. It has permissions policies but no long-term credentials: whoever assumes it receives short-lived, automatically rotated credentials. A policy is not an identity at all — it is a JSON document that defines permissions, attached to users, groups, or roles (identity-based) or, for some services, directly to a resource such as an S3 bucket (resource-based). Recognizing that policies attach to resources as well as identities is as deep as the exam goes on that distinction.

The classic trap: a question describes people who need the same permissions (answer: group) versus a workload or temporary need (answer: role). A group organizes humans; a role is assumed by whoever — or whatever — needs it, for as long as needed.

Policies come in flavors, and CLF-C02 expects you to define "custom policies and managed policies in compliance with the principle of least privilege" — the exam guide's own wording. A managed policy is a standalone policy object that can be attached to multiple identities. AWS provides AWS managed policies — prebuilt, maintained by AWS, covering common job functions (for example, a read-only-access policy or a policy granting full access to one service). You cannot edit them, but AWS keeps them current as services evolve. A customer managed policy is one you write yourself: reusable like an AWS managed policy, but scoped exactly to your needs. Finally, an inline policy is embedded directly in a single user, group, or role and cannot be reused — appropriate only when a permission must be strictly bound to one identity.

The least-privilege connection is the point the exam actually tests. AWS managed policies are convenient starting points, but they are intentionally broad — a job-function policy grants everything someone in that role might need. When a question emphasizes granting only the specific permissions required, the better answer is a customer managed (custom) policy tailored to those exact actions and resources. Broad AWS managed policy for speed and low maintenance; narrow custom policy for precision and least privilege.

At the recognition level, also remember: identity-based policies say what an identity can do anywhere; resource-based policies sit on a resource and say who can act on it. You will identify these concepts, not author them, on this exam.

Every AWS account begins with one root user — the identity created with the email address used to open the account. The root user has complete, unrestricted access to everything in the account, and its permissions cannot be limited by IAM policies. That makes it the single most dangerous credential you hold: anyone who compromises it owns the account. AWS best practice, and the exam's default correct answer, is to use the root user only for the handful of tasks that require it, and to do all daily work — including administration — with IAM identities instead.

Protect the root user with this checklist. Each line is an exam-tested "method to achieve root user protection":

• Enable MFA on the root user immediately — the single most frequently tested control.
• Set a long, strong, unique password and store it securely.
• Do not create root access keys; if any exist, delete them. Root should never be used programmatically.
• Never use root for everyday tasks — create an IAM administrator identity for routine administration.
• Keep the root email account and phone number secure and current, since they drive account recovery.
• Monitor for root usage, and treat any unexpected root sign-in as an incident.

Then memorize the short list of root-only tasks — questions ask you to identify them directly: changing the account name, root email address, or root password; closing the AWS account; changing or canceling the AWS Support plan; certain tax and billing settings (such as tax invoice details); restoring permissions if an administrator accidentally locks everyone out (for example, editing a misconfigured S3 bucket policy that denies all access); and registering as a seller in the Reserved Instance Marketplace. If a task is on this list, root is required; for everything else, root is the wrong answer.

The principle of least privilege says every identity — human or application — should have exactly the permissions required to do its job, and nothing more. It is the most-cited security principle on CLF-C02, and it appears both as a definition question and as the hidden logic behind scenario questions: whenever two answers would both technically work, the one granting fewer, narrower permissions is correct.

Least privilege shapes concrete decisions you have already seen in this lesson. Start users with no permissions and add only what they need, rather than granting broad access and trimming later. Prefer a custom policy scoped to specific actions and resources over a broad AWS managed policy when precision matters. Grant permissions to groups by job function instead of hand-assigning generous one-off permissions per person. Prefer roles with temporary credentials over long-term access keys, because a credential that expires in hours is inherently less privileged in time than one that lives for months. And review permissions periodically, removing access people no longer use — permissions tend to accumulate, and least privilege is a practice, not a one-time setup.

A useful exam heuristic: least privilege limits the blast radius. If a developer's credentials leak, an attacker gets only what that developer could do. If a full-administrator credential leaks, the attacker gets everything. Questions that mention "minimize impact of compromised credentials", "grant only required permissions", or "follow security best practices for permissions" are all pointing at least privilege.

Multi-factor authentication (MFA) adds a second proof of identity beyond the password: something you have in addition to something you know. AWS supports several MFA types, and the exam expects recognition, not configuration detail: virtual authenticator apps on a phone that generate one-time codes, security keys and hardware devices (including FIDO passkeys and hardware TOTP tokens). Enable MFA on the root user first, then on IAM users — especially any with elevated privileges. When a question asks how to add a layer of sign-in protection, MFA is the answer.

Access keys are the long-term programmatic credentials of an IAM user: an access key ID plus a secret access key, used by the CLI, SDKs, and direct API calls — never for console sign-in. Because they do not expire on their own, they carry standing risk, and best practices follow: rotate them regularly, never embed them in application code or commit them to source control, and delete keys that are unused. Better still, avoid them where possible — an application running on AWS should use a role, as the next section explains.

An account-level password policy lets you enforce rules for IAM user console passwords: minimum length, required character types (uppercase, lowercase, numbers, symbols), password expiration and rotation requirements, and preventing password reuse. When a question asks how to "require all IAM users to use strong passwords" or "enforce password rotation", the answer is configuring the IAM account password policy — not MFA, and not an external tool.

Keep the pairing straight: passwords (plus optional MFA) authenticate console access; access keys authenticate programmatic access; roles replace both with temporary credentials.

Roles are where Task 2.3 questions get scenario-shaped, and one scenario dominates: an application on an EC2 instance (or a Lambda function) needs to access another AWS service, such as reading from S3 or writing to DynamoDB. The correct answer is always to attach an IAM role to the compute resource. The application then receives temporary credentials automatically — no keys stored on the instance, nothing to rotate, nothing to leak from code or configuration files. The distractor is always "create an IAM user and store its access keys on the instance"; that answer is wrong every time it appears, because embedded long-term keys violate least privilege and credential-hygiene best practices.

Cross-account IAM roles extend the same idea across account boundaries. When users or workloads in account A need access to resources in account B, you do not duplicate IAM users in account B. Instead, account B creates a role that trusts account A; identities in account A assume that role and receive temporary credentials scoped to the role's policies. One set of identities, temporary access, full auditability — this is the exam's expected answer for any "access resources in another AWS account" scenario, and it is listed by name in the exam guide as an authentication method.

Federated identity means users authenticate with an external identity provider — a corporate directory, SAML or OIDC provider, or a social/web identity — and exchange that proof for temporary AWS credentials via a role, without ever becoming IAM users. Federation is the answer when a question says "employees should sign in with their existing corporate credentials" or "avoid creating separate AWS credentials for each employee". Notice the common thread: users, keys, and passwords are long-term; roles and federation are temporary — and on this exam, temporary is almost always the best practice.

AWS IAM Identity Center — the successor to AWS Single Sign-On, and still labeled "AWS Single Sign-On" in the exam guide — solves a problem IAM alone handles poorly: workforce access across many AWS accounts and business applications. IAM identities live inside a single account; a company with ten accounts would otherwise manage ten separate sets of users. Identity Center provides one place to create or connect workforce identities and assign them access to multiple AWS accounts and cloud applications, all reached through one user portal with a single sign-on. Users sign in once and see tiles for every account and application they are permitted to use, receiving temporary role-based credentials behind the scenes. It can hold identities in its own built-in directory or federate with an external identity provider such as a corporate directory — federation and single sign-on working together.

Consider a realistic scenario the exam likes: a company hires 50 engineers and runs three AWS accounts — development, staging, and production. The anti-pattern is creating 150 IAM users (50 per account), each with a password and possibly access keys: three credentials per person, no central offboarding, and enormous key sprawl. With IAM Identity Center, the company defines each engineer once (or connects its existing corporate directory), creates permission sets such as "developer" and "read-only", and assigns groups of engineers to the appropriate accounts. Each engineer signs in once — with MFA — and assumes temporary credentials in whichever account they open. When someone leaves, disabling one identity revokes everything.

The exam discrimination to memorize: IAM manages identities and fine-grained permissions within one account (and is always what evaluates permissions underneath); IAM Identity Center centrally manages human workforce sign-on across multiple accounts and applications. "Multiple accounts", "single sign-on", "one portal", or "existing corporate identity provider" in the question all point to Identity Center.

Applications need secrets too — database passwords, API keys, connection strings — and hard-coding them in application code or configuration files is the anti-pattern every related exam question punishes. AWS provides two services to store such values centrally, encrypted, and retrievable at runtime by an application using its IAM role. You need recognition-level knowledge of both.

AWS Secrets Manager is purpose-built for secrets. It stores credentials encrypted, controls retrieval through IAM permissions, and — its defining feature — supports automatic rotation, replacing secrets like database passwords on a schedule without application downtime or code changes. When a question mentions "automatically rotate database credentials" or "manage the lifecycle of secrets", Secrets Manager is the answer.

AWS Systems Manager Parameter Store is a capability of AWS Systems Manager for storing configuration data and secrets as hierarchical parameters — plaintext values for ordinary settings, or encrypted secure string parameters for sensitive ones. It is a simpler, general-purpose store: excellent for configuration values and basic secret storage, but without Secrets Manager's built-in automatic rotation. The exam guide names "AWS Systems Manager" as a credential-storage example, so recognize Parameter Store as the relevant capability.

The one-line discrimination: Secrets Manager = secrets with managed automatic rotation; Parameter Store = simple storage for configuration data and secrets. Both beat any answer that stores credentials in code, in an S3 object, or on an instance's disk. And in every case, the application should reach the stored secret through an IAM role — tying credential storage back to the temporary-credentials theme that runs through this entire task.