Comparing IAM Users and Groups

AWS Identity and Access Management (IAM) is the service that controls who can do what in your account. Two of its most basic building blocks are users and groups. A user is a permanent identity tied to a person or application, while a group is simply a container that bundles users together so they share the same permissions. Understanding the difference is the foundation for everything else on the exam.

An IAM user is a long-term identity with a name unique within your account. It can have two kinds of credentials:

• A console password for signing in through the web.
• Access keys (an access key ID and secret) for programmatic API and CLI calls.

Because these credentials are long-lived, AWS treats them as higher risk. Best practice is to prefer roles and temporary credentials over creating many users with permanent keys.

An IAM group is a collection of users that share permissions through attached policies. Groups make access management scalable: instead of attaching the same policy to ten developers, you attach it once to a "Developers" group and add the users. Key facts the exam expects:

• A group has no credentials and cannot be a principal in a policy.
• A user can belong to multiple groups.
• Groups cannot be nested inside other groups.

When a user makes a request, IAM combines all policies that apply: those attached directly to the user plus those attached to every group the user belongs to. The result is the union of all allowed actions, unless an explicit deny appears anywhere. This means group membership only ever adds permissions, never subtracts them, except through an explicit deny statement.

Managing permissions per user invites configuration drift: over time each user accumulates a slightly different, hard-to-audit set of policies. Groups centralize permissions so a single policy change applies consistently to everyone in a role. For an auditor, listing who belongs to the "Admins" group is far easier than inspecting dozens of individual users one by one.

You can inspect membership from the CLI to audit who holds elevated access. The command below lists every user inside a group, which is a common first step when responding to an over-privileged-access finding.

Do not confuse IAM users with the root user. The root user is the account owner identity created when the account is opened, and it has unrestricted access that cannot be limited by IAM policies. AWS strongly recommends you lock away root credentials, enable multi-factor authentication (MFA) on it, and never use it for daily work. Create individual IAM users (or better, use federation) instead.

Every IAM user should have MFA enabled, which requires a second factor such as a hardware key or authenticator app in addition to the password. You can enforce MFA through policy conditions like aws:MultiFactorAuthPresent. The exam often tests using MFA to protect sensitive operations such as deleting resources or changing security settings.

A common mistake is creating IAM users with static access keys for applications running on EC2 (Elastic Compute Cloud). This embeds long-term secrets that can leak. The secure pattern is an IAM role attached to the instance, which we cover next. For human teams, prefer IAM Identity Center federation over individually managed users.

The IAM credential report is a downloadable CSV listing every user, when their password and access keys were last used, and whether MFA is active. Combined with IAM Access Analyzer and last-accessed data, it helps you find stale users, unused keys, and over-broad groups. Regular review is a core part of least-privilege hygiene the exam rewards.

Use users when you need a distinct, credentialed identity for a person or legacy app. Use groups to assign shared permissions cleanly and avoid per-user drift. In modern designs you minimize standing users entirely, relying on roles for workloads and federation for humans. Users and groups remain essential vocabulary, but they are the starting point, not the destination.

Test your grasp of users versus groups.

You learned that an IAM user is a long-term credentialed identity while an IAM group is a credential-less container that bundles users to share policies. Permissions are the union of user and group policies, groups cannot nest, and the root user should be locked away with MFA. Prefer roles for workloads and federation for humans to avoid long-lived secrets and configuration drift.