What it is
An IAM role is a set of permissions that a service or a person can pick up for a job, then put down. Azure’s twin is a managed identity. Neither is a password you copy into a file.
The server, the function, or the pipeline asks the cloud “may I do this?” The cloud checks the role attached to that workload. When the job stops, the permission stops.
This is the grown-up version of access keys on laptops. Same idea as a visitor badge that expires when the meeting ends, not a master key on a lanyard in the drawer.
Why it matters in the meeting
When Selena says the app “uses a user,” Bart should flinch. Apps are not people. People leave. Apps stay. The leftover key does not.
Roles also make audits possible. You can ask what the billing pipeline is allowed to do. You cannot ask that of a key named `temp` from 2019.
Real world
Most of the ugly GitHub stories start with a long-lived key that should have been a role. EC2 instance profiles, Lambda execution roles, and Azure managed identities exist so the laptop never holds production power.
If a contractor needs access, give a role they assume, with a time limit. If the pipeline needs access, give the pipeline a role. If someone says that is slower, compare it to rotating a leaked key on a Sunday.
A role is permission that shows up for the job and leaves with the job. A key is permission that shows up in a spreadsheet. Prefer the one that does not commute home on the GO train.
What to ask
- Does production compute assume a role or a managed identity, or does it still use a stored key?
- Which people still have standing admin instead of a role they request when they need it?
- If we disabled every access key tomorrow, which workloads would actually break?
- Who owns each role, and when was that list last reviewed?
You just knew a little more Jack than you did five minutes ago.
All concepts