In AWS IAM, what are users, groups and roles, and why do production AWS accounts prefer roles over IAM users holding long-lived access keys?
answer
- three identity shapes, one is borrowed
- groups hold no credentials at all
- the credential is what expires, or doesn't
- AKIA is permanent, ASIA is a session
- leaked static key works until someone notices
basics
~20 sAWS IAM users are identities with long-lived credentials, groups are policy-carrying containers of users, and roles are identities that anything trusted can take on to get expiring credentials. Roles are preferred because nothing permanent is left lying around to leak.
solid answer
~50 sIAM has three identity shapes. An **IAM user** represents one person or application and owns long-lived credentials — a console password and/or an access key pair that stays valid until someone rotates or deletes it. A **group** is purely an administrative container: you attach policies to it and put users in it, but a group has no credentials and can never itself be a principal in a policy. A **role** is an identity with permissions but no permanent credentials attached; a trusted party takes the role on and receives short-lived credentials that expire on their own. Production accounts prefer roles because the dangerous asset in AWS is a secret that never expires: a leaked access key in a repo, an image or a laptop backup keeps working indefinitely, while role credentials time out. Roles also make access attributable and revocable by changing who may assume them.
go deeper
Be able to name the three identity types and say plainly what each is: a user holds long-lived credentials, a group is a container of users that carries policies, a role is taken on to get credentials that expire.
Explain why a group has no credentials and cannot be a principal, and describe the practical difference between a static access key pair and a session credential that times out on its own.
Show credential hygiene judgment: argue for eliminating long-lived access keys in the estate you operate, and explain how expiring role credentials change the blast radius and the revocation story when a secret leaks.
Own the direction of travel for identity across many accounts — where human access originates, why every static key is a standing liability with an owner and a rotation cost, and what you trade away by insisting on role-based access everywhere.
## What IAM is for AWS IAM (Identity and Access Management) answers two questions on every single API call to AWS: *who is making this call*, and *are they allowed to do it*. This entry is the map of the first half — the identity types you will be asked to name and place. IAM is a **global** service: users, groups and roles are not per-Region resources, and one identity is the same identity whether it calls an endpoint in `eu-central-1` or `us-east-1`. Every caller of the AWS API is a **principal**. A principal proves who it is by presenting credentials, and AWS then consults the policies that apply to it. The identity types below are simply the different shapes a principal can come in. ## The account root user When an AWS account is created it comes with a **root user** — the email address the account was signed up with. The root user is not an IAM user and cannot be constrained by ordinary IAM permissions; it can do everything in the account, including closing it. The standing practice is to secure it with MFA, remove any access keys it has, and then not use it: everyday work is done through IAM identities instead. A handful of tasks genuinely require the root user, which is why it exists at all, not because it is a convenient admin login. ## IAM users An **IAM user** is a named, long-lived identity inside one account. It can hold two kinds of credentials: - a **console password**, for signing in through the browser; - an **access key pair** (an access key ID and a secret access key), for the CLI, SDKs and any programmatic caller. The defining property of both is that they do not expire. An access key created three years ago is still valid today unless a human deactivated or deleted it. That is exactly what makes IAM users the awkward part of IAM: the credential is a static secret that must be distributed, stored, rotated and eventually revoked by someone remembering to do it. Keys leak through committed `.env` files, baked container images, CI logs and old laptops, and a leaked key is indistinguishable from the legitimate user. A user can be given permissions directly, but scaling that means editing dozens of identities whenever a permission changes — which is what groups are for. ## IAM groups A **group** is a container for users and nothing more. You attach policies to the group, add users to it, and every member picks up those permissions. Two properties trip candidates up: - a group has **no credentials of its own** — nothing signs a request "as a group"; - a group **cannot be a principal** in a policy, and groups cannot be nested inside other groups. So a group is an administrative convenience for granting permissions to many humans at once, not a security boundary and not an identity. ## IAM roles A **role** is an identity with permissions but with no password and no permanent access key. Instead, a trusted party *takes on* the role and, in exchange, receives a set of **temporary credentials** — an access key ID, a secret, and a session token — that stop working when the session expires. A role carries two things: what it may do, and who is allowed to take it on. Anything can be on the receiving end: an AWS service running your code, a workload in another account, a workload outside AWS that federates in, or a human who has authenticated somewhere else. This is why roles are the backbone of real AWS estates. The credentials are handed out on demand, rotate themselves, and are useless once expired, so there is no static secret to leak in the first place. Revoking access becomes an edit to who may assume the role rather than a hunt for every copy of a key. One detail worth recognising in logs and support tickets: long-term access key IDs begin with `AKIA`, while the temporary ones a role session hands out begin with `ASIA`. Seeing `AKIA` in an application's configuration is a strong signal that a static credential is in play where a role should be. ## Where each piece of the picture is decided Identity is only half of an authorization decision. The other half is **policies** — the JSON documents that state what is permitted, attached either to an identity or to a resource — and the **evaluation rules** AWS applies when several policies bear on one request. Those, along with the mechanics of taking on a role, how services obtain role credentials, ceilings such as permissions boundaries and organization-level controls, and end-user identity, are each their own subject. What you should carry away from the map itself is: users are permanent credentials, groups are convenience, roles are borrowed and expiring identity — and the direction of travel in every serious AWS account is away from the first and toward the third.
- Are IAM users, groups and roles regional resources — do I need one per Region?No. IAM is a global service: an identity you create is visible and usable across all Regions of the account, and there is no per-Region copy to keep in sync. Its endpoint is global, which is also why IAM changes can take a moment to be visible everywhere. What is per-Region is the resources those identities act on, not the identities themselves.
- Can a human being use a role, or are roles only for AWS services and applications?Humans use them constantly. A person who has authenticated somewhere else — a corporate identity provider, or AWS's own workforce identity service — ends up taking on a role in the target account and working with its temporary credentials. That is the standard way to give engineers access to many accounts without creating an IAM user in each one.
- What is the AWS account root user, and how does it relate to IAM identities?The root user is the identity created with the account — the sign-up email — and it sits outside ordinary IAM permission control, so it can do anything including closing the account. It is not an IAM user. Standard practice is to protect it with MFA, remove any access keys, and use IAM identities for all routine work, reserving root for the few tasks that genuinely require it.
An IAM user is a permanent badge with your name on it that never stops working if you drop it in the street; a role is a visitor pass from the front desk that anyone the desk trusts can pick up and that stops opening doors at the end of the day.
saying these in an interview costs you the question
- Says a group can be granted access as a principal
- Thinks a group has its own credentials or password
- Believes IAM access keys expire automatically after 90 days
- Claims roles are only for AWS services, never for people
- Treats the root user as just the account's admin IAM user
- Says IAM must be configured separately in each Region