IAM Role vs IAM User

WHAT THIS TESTS The interviewer wants to confirm you understand the distinction between a persistent identity and an assumable role, and that you default to temporary credentials over long-lived keys.

A GOOD ANSWER COVERS An IAM user is a permanent identity, typically representing a person, that owns long-lived credentials such as a console password or access key pair. Those credentials persist until rotated or revoked, which makes them a liability if leaked. An IAM role is a set of permissions that no single identity owns; instead, trusted principals assume it and receive temporary, automatically expiring credentials issued by the security token service. Roles are the right tool for workloads: an EC2 instance, a Lambda function, or a container assumes a role and gets short-lived credentials with no secrets stored on disk. Roles also enable cross-account access and identity federation, where an external identity provider's users assume a role rather than getting their own user. You choose a user for a human who needs direct, durable sign-in, though even there federation into roles is increasingly preferred. You choose a role whenever a service, instance, or external or cross-account identity needs permissions, because temporary credentials shrink the blast radius of any leak.

COMMON WRONG ANSWERS Saying roles and users are interchangeable. Embedding a user's long-lived access keys in application code or config instead of attaching a role. Believing roles have permanent credentials; they issue temporary ones.

LIKELY FOLLOW-UPS How does an instance profile let EC2 assume a role? What is the trust policy on a role? How does STS issue temporary credentials?

ONE CONCRETE EXAMPLE Instead of baking access keys into an app, you attach a role to the EC2 instance; the app reads auto-rotating temporary credentials from instance metadata, so a compromised host yields only short-lived, narrowly scoped access.