Your team currently gives every engineer an IAM user with long-lived access keys in each of five AWS accounts. What does AWS IAM Identity Center replace that with, and why is it considered safer?
answer
- one identity, many accounts
- the key that never expires
- permission set assigned to a group
- short-lived session from the portal
- disable the person once, everywhere
basics
~20 sIAM Identity Center centralises workforce sign-in: each engineer exists once in one identity source, is assigned permission sets per account, and receives short-lived credentials at login instead of access keys that live on a laptop forever.
solid answer
~50 sAn IAM user belongs to exactly one account, so five accounts means five user objects and five secret access keys that never expire on their own — they end up in dotfiles, CI variables and occasionally in git, and rotation is manual. IAM Identity Center inverts that. It sits on top of AWS Organizations, takes its users and groups from a single identity source (its own directory, Active Directory, or an external IdP over SAML), and you grant access by creating a *permission set* — a policy template — and assigning it to a group in a particular account. Signing in at the access portal, or running `aws sso login`, hands the engineer temporary STS credentials scoped to that account and permission set, valid for the permission set's session duration rather than forever. Disabling the person in the identity source removes access everywhere, and no standing secret exists to leak.
go deeper
Be ready to say plainly that a secret access key does not expire by itself, while a federated sign-in hands you credentials that do. Name the flow: sign in once, pick an account and role, get a temporary session.
Expect to explain the moving parts — one identity source, permission sets as policy templates, and assignments that bind a group to a permission set in an account — and what the CLI does when you run aws sso login.
Show that you know revocation is not instant: a live role session runs to its configured duration after the user is disabled. Talk about capping that duration and keeping an alarmed break-glass path for when the IdP is unavailable.
Own the argument for making the corporate identity provider the single source of truth and for treating group membership, not per-person grants, as the control surface. Be able to justify the migration cost against the standing-secret risk it removes.
## What an IAM user actually is An IAM user is a long-lived identity object that lives inside **one** AWS account. It can carry a console password and up to two access key pairs: an access key ID plus a secret access key. Nothing about that pair expires — it is valid from the moment it is created until a human deletes or deactivates it. Because the user object is account-scoped, an engineer who needs dev, staging, prod, tooling and sandbox either gets five separate users with five separate secrets, or gets one user in a "jump" account and assumes roles outward from there. ## Why the long-lived key is the real problem A secret with no expiry accumulates copies. It lands in `~/.aws/credentials`, in a laptop backup, in a container image, in a colleague's DM, in a CI variable, in a `.env` committed by accident. Every copy is independently sufficient to act as that person. Detection is retrospective — CloudTrail and GuardDuty tell you *afterwards* that a key was used from an unexpected place — and the remedy is manual rotation that, in practice, rarely happens on schedule. Multiply that by the number of accounts and the number of engineers and you get a large, quiet, permanently valid credential surface. ## What IAM Identity Center changes IAM Identity Center (the service formerly called AWS SSO) is the workforce single-sign-on layer for an AWS organization. Three pieces matter: 1. **An identity source.** Exactly one, chosen when you enable the service: the built-in Identity Center directory, AWS Managed Microsoft AD / AD Connector, or an external identity provider connected over SAML 2.0 with SCIM for provisioning. Users and groups live there, not per account. 2. **Permission sets.** A named bundle of policies — AWS managed policies, customer managed policy references, an inline policy, optionally a permissions boundary — plus a session duration. It is a template, not a grant. 3. **Assignments.** The grant itself is the triple *(principal, permission set, account)*, normally with the principal being a **group**. Assigning provisions the permission set into that account as an IAM role that the user is allowed to assume through Identity Center. Signing in to the access portal shows the engineer only the accounts and roles they have been assigned. Choosing one produces a temporary AWS session — an access key ID, a secret, **and a session token** — that expires at the end of the permission set's session duration. The CLI equivalent is `aws sso login` against a profile created by `aws configure sso`. ## What concretely improves - **No standing secret.** The worst case for a stolen credential shrinks from "until someone notices" to "until this session expires". - **One place to remove a person.** Disable them in the identity source and every account assignment stops working, instead of hunting five IAM users in five consoles. - **Access is an assignment, not a copy of the person.** Adding a sixth account is one assignment to an existing group; no new identity, no new secret. - **MFA is enforced once, at sign-in**, by the identity source, rather than being configured per IAM user per account. - **Attribution.** The role session carries the signed-in user's name, so CloudTrail shows *who* did something rather than *which shared key* did it. - **Group-shaped review.** Auditing "who can touch production" becomes reading group membership and assignments, not diffing per-account policies. ## What it does not solve Identity Center is for **humans**. Application workloads still get their permissions from roles attached to the compute (an instance profile, a task role, an execution role), and external CI systems federate in over OIDC; neither should hold an IAM user either, but neither is an Identity Center concern. Revocation is also not instantaneous. Removing a user ends their portal session and stops new credentials being issued, but a role session already handed out remains valid until its own duration elapses — which is the practical argument for keeping permission-set session durations short rather than at the ceiling. Finally, you keep a **break-glass** path: a very small number of tightly controlled credentials that work when the identity provider itself is down, guarded by hardware MFA and alarmed on use. Federation is the default door, not the only one. ## The shape of a good answer Say what the *credential* looks like in each model — permanent secret on a laptop versus expiring session from a sign-in — then say what *administration* looks like: five user objects to create, rotate and delete, versus one identity and a set of assignments. That contrast is the whole question.
- An engineer leaves the company on Friday. Walk me through what happens to their AWS access under each model.With IAM users you must find and delete a user object in every account, and any key already copied elsewhere stays valid until you do. With Identity Center you disable or deprovision them in the identity source: the portal session ends and no new credentials are issued anywhere. Sessions already handed out survive until their duration expires, which is why you keep that duration short.
- Some of our automation also uses IAM user keys. Does Identity Center replace those too?No — it is a workforce SSO service for people. Workloads running on AWS take a role attached to the compute itself, and external CI systems such as GitHub Actions federate in through an IAM OIDC identity provider. The goal is the same, no stored long-lived secret, but the mechanism is different.
- Does adopting Identity Center mean IAM policies stop mattering?Not at all. A permission set is a container for ordinary IAM policies, and the session it produces is evaluated by the same policy engine — identity policy, resource policy, boundaries and organization guardrails all still apply. Identity Center changes who holds the credential and for how long, not how a request is authorised.
saying these in an interview costs you the question
- IAM users are fine as long as keys are rotated quarterly
- Identity Center is just a nicer login page over IAM users
- You still create one IAM user per person per account
- Access keys are safe if the repository is private
- One shared admin account with MFA is equivalent