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. Every request is evaluated against all the policies that apply to it, in a fixed order of precedence:

1. Explicit deny — a Deny statement in any applicable policy ends the evaluation. Nothing can override it.
2. Explicit allow — if no deny applies, an Allow statement grants the action.
3. Implicit deny — if nothing allows the action, it is denied.

Example: a user belongs to a group whose policy allows deleting S3 objects, and the user also has a policy that denies s3:DeleteObject. The user cannot delete objects — the explicit deny wins over the group's allow. A user with no policy mentioning S3 at all, requesting a bucket that has no bucket policy, is refused by the implicit deny. You will not author policy documents at the Cloud Practitioner level, but this deny-by-default posture 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 IAM 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 group can contain only IAM users from the same account: an EC2 instance, a Lambda function, a role, or a user from another AWS account can never be added to a group. 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 IAM users; a role is assumed by whoever — or whatever — needs it, for as long as needed. Note that roles have no "members": you don't add people to a role, you allow identities to assume it.

Every role carries two different policies. Its trust policy says who may assume the role (a service such as EC2, another account, or a federated identity provider). Its permissions policy says what the role can do once assumed. A special kind, the service-linked role, is created and managed by an AWS service so that the service can act on your behalf (for example, to manage resources it needs); you don't assign it to people, and it has nothing to do with federated sign-in.

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. Being custom is not what makes it least privilege, though: a customer managed policy that allows s3:* on every bucket is just as broad as a managed full-access policy. Least privilege comes from narrowing both the actions and the resources — for example, allowing only start and stop of EC2 instances that carry a specific team tag, instead of every EC2 action on every instance.

At the recognition level, also tell these policy categories apart — you will identify them, not author them:

Boundaries and SCPs are guardrails: an action must be allowed by an identity or resource policy and fall inside every applicable cap. Only resource-based policies live on the resource itself.

The root user is the identity created with the email address and password used to open an AWS account, and it has complete, unrestricted access to everything in that account. Its permissions cannot be limited by IAM policies — attaching a deny policy to root is not possible, because identity-based policies apply to IAM users, groups, and roles, not to the root user. The root user of a standalone account also cannot be deleted; it is protected and set aside. That makes it the single most dangerous credential you hold: anyone who compromises it owns the account. AWS best practice is to use the root user only for the handful of tasks that require it, and to do all daily work — including administration — with other identities. AWS's current recommendation is an administrative user in IAM Identity Center for daily tasks.

Protect the root user with this checklist. Each line is a method of root user protection:

• Enable MFA on the root user — AWS now enforces MFA for root users and prompts you to register a device.
• 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 — use an administrative identity (AWS recommends one in IAM Identity Center) 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.

Tasks that require root user credentials (per the IAM User Guide) include:

• Changing the root email address, root password, or root access keys of a standalone account.
• Closing a standalone account, and reopening an account you closed, during its post-closure period.
• Restoring IAM user permissions when the only IAM administrator accidentally revokes their own access.
• Activating IAM access to the Billing and Cost Management console, plus a few billing tasks such as viewing certain tax invoices.
• Enabling MFA delete on an S3 bucket.
• Editing or deleting an S3 bucket policy or SQS queue policy that denies all principals — the lock-out that no IAM identity can undo.
• Registering as a seller in the Reserved Instance Marketplace, and signing up for AWS GovCloud (US).

Equally important is what is not on the list. Changing the account name, contact information, alternate contacts, or enabled Regions needs only IAM permissions. Changing or canceling the AWS Support plan also needs only IAM permissions — older study material lists it as root-only, which is no longer true.

AWS Organizations changes the picture for member accounts. Authorized identities in the management account (or a delegated admin account) can close member accounts and update their root email addresses, account names, contacts and enabled Regions centrally. With centralized root access enabled, they can also remove member accounts' root user credentials entirely (new member accounts can be created with none) and perform specific privileged tasks — such as unlocking a deny-all S3 bucket policy or SQS queue policy — without ever signing in as the member's root user. A service control policy, by contrast, restricts what identities in member accounts can do; it does not remove root credentials.

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.

Least privilege is often confused with two neighbouring ideas:

RBAC organizes permissions but does not by itself keep them minimal: a job-function role that grants more than the function needs — say, a read-only application's role that can delete any bucket — still violates 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 three MFA types: passkeys and security keys (FIDO2, phishing-resistant — the type AWS recommends), virtual authenticator apps on a phone that generate one-time codes, and hardware TOTP tokens. AWS no longer supports enabling SMS text-message MFA, so a text-message code is not an option for new MFA devices. 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. Because IAM is global, one access key pair works in every Region. The account password policy does not apply to access keys, and nothing makes them expire automatically — rotation is your job. Better still, avoid them where possible — an application running on AWS should use a role, as the next section explains.

To find keys nobody uses, download the IAM credential report: an account-wide CSV listing every IAM user and the status of their credentials, including when each access key was created, last rotated, and last used. Two look-alikes answer different questions: IAM Access Advisor shows which services one identity last accessed (useful for trimming permissions), and CloudTrail event history shows the last 90 days of API events, not an inventory of keys. If a key is leaked, deactivate or delete it immediately (containment), then replace the long-term key with an IAM role so there is no stored key left to leak (prevention).

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. Know its limits: it applies only to IAM user console passwords — not to the root user's password and not to access keys — and it has no account-lockout setting. When you change the policy, new length and complexity rules apply the next time each user changes their password, while a new expiration period takes effect immediately (users whose passwords are now older than the limit must change them at next sign-in).

Keep the pairing straight: passwords (plus MFA) authenticate console access; access keys are the long-term credential for programmatic access; roles replace both with temporary credentials. Two newer or rarer paths: IAM users can get short-term CLI credentials from their console sign-in with the aws login command, and an IAM user's SSH public key is used only for Git over SSH to AWS CodeCommit — it does not sign AWS API requests.

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 to give the compute resource an IAM role — an instance role (through an instance profile) for EC2, or the function's execution role for Lambda. The application then receives temporary credentials automatically — no keys stored on the instance, nothing to rotate, nothing to leak from code or configuration files. Creating an IAM user and storing its access keys on the instance is the anti-pattern this replaces: those keys are long-term, never expire on their own, can leak from disk, code or images, and must be rotated by hand — so embedding them breaks both least privilege and credential hygiene. Adding the instance to an IAM group is not possible either — groups hold only IAM users. Don't confuse the Lambda execution role with a Lambda function's resource-based policy: the execution role controls what the function can access; the resource-based policy controls who may invoke the function.

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, the role lives in the account that owns the resources (account B), and its trust policy names the account that needs access (account A); identities in account A assume that role and receive temporary credentials scoped to the role's permissions policy. Getting the direction backwards — a role in account A trusting account B — gives B access to A, not the other way round. Two allows are needed: B's role must trust A, and the identities in A must be allowed (by their own identity-based policy) to assume it. The same rule applies when a resource-based policy, such as an S3 bucket policy, grants another account access directly: the bucket policy in the owning account and an identity-based policy in the requester's account must both allow the action. 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". For customers signing in to your own web or mobile app — including with social logins — the service is Amazon Cognito, not IAM Identity Center. 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.

Under the hood, each permission set is provisioned as an IAM role in every account it is assigned to; signing in through the portal assumes that role. Identity Center users are not limited to the console: they can configure an Identity Center profile in the AWS CLI and receive short-term CLI credentials without any long-term access keys.

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 — String and StringList parameters for ordinary settings, or encrypted SecureString parameters (encrypted with an AWS KMS key) 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.

Watch for two name traps. AWS Config records and evaluates the configuration of your AWS resources over time — it does not store application configuration values or secrets. AWS KMS creates and manages encryption keys that Secrets Manager and SecureString parameters use — it encrypts data but does not store your passwords or settings for retrieval.

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.