Azure Built-in Roles
Every Azure RBAC built-in role with its category, role definition ID, assignable scopes and the description Microsoft gives each individual action, from the official built-in roles reference.
| Role ▲ | Category ▲ | Actions ▲ | NotActions ▲ | DataActions ▲ | NotDataActions ▲ | Role definition ID ▲ |
|---|
About Azure built-in roles
Azure role-based access control grants permissions through role definitions. A role definition is a list of allowed control-plane operations (Actions), operations carved back out of them (NotActions), and the equivalent pair for operations on the data inside a resource (DataActions and NotDataActions). Built-in roles are the ones Microsoft ships and maintains; their definition IDs are the same GUID in every tenant, which is why they can be referenced safely from templates and pipelines.
Reading a role definition
Actionsare management operations - creating, reading, updating or deleting the resource itself.DataActionsreach the data a resource holds: the blobs in a storage account, the secrets in a key vault, the messages in a queue. A role with noDataActionscannot read your data, however broad its management rights look.NotActionsis a subtraction, not a deny. It removes an operation from this role only; another assignment can still grant it.- A wildcard such as
Microsoft.Compute/*covers every current and future operation in that namespace, so the effective reach of a role grows as Azure does.
Choosing the right role
Start from the narrowest role whose actions cover the task, and assign it at the narrowest scope that works - a resource before a resource group, a resource group before a subscription. Owner, Contributor and User Access Administrator are flagged as privileged here because they can grant access to others or bypass the guardrails placed on a scope, so they deserve a Privileged Identity Management workflow rather than a standing assignment.
Where this data comes from
The dataset is rebuilt several times a day from Microsoft's generated Azure RBAC reference, so a role added or reworded upstream shows up here without anyone editing this page. The per-action descriptions come from the same source, which is why they read the way they do in the portal.