IAM roles vs users vs policies — how do you apply least privilege in the cloud?

This question separates people who use the cloud from people who secure it. The three concepts are distinct, and conflating them leads directly to over-permissioned environments.

The three building blocks

• User. A long-lived identity, usually for a human, with permanent credentials (password, access keys). Permanent keys are a liability — they leak in repos and CI logs.
• Role. An identity with no permanent credentials. A trusted principal (an EC2 instance, a Lambda, another account, a federated user) assumes the role via STS and receives short-lived, auto-rotating tokens. This is the preferred pattern for workloads and cross-account access because there are no static secrets to steal.
• Policy. The JSON document that actually grants or denies permissions — Effect, Action, Resource, and optional Condition. Policies attach to users, roles, or groups. A role or user with no policy can do nothing.

Applying least privilege

Least privilege means each identity holds only the permissions a specific job requires, and nothing more:

• Prefer roles over users for anything non-human, so there are no static keys.
• Scope actions and resources. Replace s3:* on * with the specific actions on specific ARNs. Add Condition clauses (source IP, MFA, tags) where they fit.
• Watch escalation paths. Permissions like iam:PassRole, iam:CreatePolicyVersion, or attaching admin policies let a low-privilege identity become admin — least privilege must cover IAM actions themselves.
• Review and prune. Use access analyzers and last-used data to remove unused permissions over time.

What interviewers look for

Crisp definitions, a clear bias toward roles and short-lived credentials, and awareness that IAM permissions can themselves be an escalation vector.