9. Glossary and Cheatsheet
The ten-second lookup.
Glossary
ABAC condition — an expression attached to a role assignment, evaluated per request against attributes of the resource or request (blob index tags, path prefixes). Narrows a grant without a new role definition. Coverage is per-service ⚠️ verify current coverage against current Azure docs.
Access policy (Key Vault) — the legacy, pre-RBAC authorisation model for a vault: a per-vault list
of principals and permitted operations. Retired for a vault by setting
enableRbacAuthorization = true.
actions — the array of control-plane operation strings a role definition permits. Evaluated by ARM.
Activity log — the subscription-level record of control-plane operations, including every role assignment write. Retained briefly by default; route it to a Log Analytics workspace to be useful.
App registration — the global definition of an application in Entra ID. Distinct from the service principal, which is its instance in a tenant. Permissions granted on the wrong one is the classic "I granted it but it doesn't work".
ARM (Azure Resource Manager) — the single control plane at management.azure.com. It evaluates
actions/notActions on every request. See Azure Resource Manager.
assignableScopes — on a role definition, the list of management groups or subscriptions in which
the role may be used. Cannot include root / for a custom role.
AuthorizationFailed — the HTTP 403 error code for an RBAC denial. Names the principal, the action,
and the scope evaluated. Read all three before doing anything else.
Azure Policy — a separate system deciding whether a request shape is permissible, regardless of
who's asking. Denies with RequestDisallowedByPolicy. No role will fix a policy denial.
Azure RBAC — the authorisation system built into ARM. Evaluates role assignments (principal + role definition + scope) on every request. Free, always on, not deployed.
Break-glass account — a cloud-only emergency account with standing root-scope Owner, excluded from lockout policies, alerting on sign-in, credentials split across people. Necessary because PIM activation can itself be the thing that's broken.
Built-in role — a Microsoft-authored, tenant-wide role definition. Several hundred exist ⚠️ verify current count.
Conditional Access — an Entra P1 feature evaluated before authorisation, at token issuance: require MFA, a compliant device, or a trusted network. Applies to the Azure management plane like any other application.
Contributor — the broad built-in role granting every control-plane action except writing role assignments. Can delete every resource in scope, and grants no data access. The workhorse and the trap.
Control plane — managing the resource itself, via ARM. Governed by actions.
Custom role — a role definition you author. Tenant-level object with a per-tenant cap ⚠️ verify. A maintenance commitment, not a config change.
Data plane — the contents of a resource, via the service's own endpoint
(*.blob.core.windows.net, *.vault.azure.net). Governed by dataActions. Owner does not cover it.
dataActions — the array of data-plane operation strings a role definition permits. Evaluated by the
service, not ARM. The word Data in a built-in role name is the tell that it has some.
DefaultAzureCredential — the Azure SDK credential chain: environment variables, managed identity,
az login, and others. Can succeed locally with your permissions and fail in Azure with the identity's.
Deny assignment — a platform-created block on specific actions for specific principals, which outranks role assignments. Created by Azure managed applications (and formerly Blueprints). You can read them; you cannot author one.
Directory role — an Entra role governing the tenant (Global Administrator, User Administrator). Disjoint from Azure roles. Assigned through Entra ID, not ARM.
Elevate access — the one bridge between the two systems: a Global Administrator granting themselves
User Access Administrator at root scope /. Break-glass, logged, should page someone.
Entra ID (Microsoft Entra ID) — the identity provider that answers who are you and issues the token RBAC then authorises. Formerly Azure Active Directory (Azure AD). See Microsoft Entra ID.
Group overage claim — what Entra emits instead of a group list when a principal is in too many groups. Azure's evaluators handle it; application code reading groups from the token concludes the user is in none ⚠️ verify current threshold.
guid() — the Bicep function used to derive a deterministic role-assignment name from
scope + principal + role, making the deployment idempotent. A random GUID would create duplicates.
IMDS (Instance Metadata Service) — the link-local endpoint inside a VM or app from which a managed identity fetches tokens. Not routable from outside the host.
Managed identity — a service principal Azure creates for a resource and whose credentials Azure rotates. System-assigned shares the resource's lifecycle (and gets a new object ID on replacement); user-assigned is its own ARM resource with a stable object ID.
Management group — a scope above subscriptions, nestable, used for organisation-wide assignments and policy. An assignment here reaches every subscription beneath it.
notActions / notDataActions — subtractions within a single role definition, evaluated before
the union. Not denials. Another assignment granting the same action wins. The most misunderstood field
in Azure RBAC.
Object ID (oid) — the Entra GUID identifying a principal. What a role assignment points at, and
what appears in the token's oid claim.
Orphaned assignment — a role assignment whose principal no longer resolves, typically from a deleted service principal or a replaced system-assigned identity. Shows as "Identity not found", counts against the assignment ceiling, and makes audits unreadable.
Owner — the built-in role granting every control-plane action including writing role assignments.
Carries no dataActions. Should be PIM-eligible rather than assigned.
PIM (Privileged Identity Management) — Entra P2 / Governance feature making an assignment eligible rather than held: activation requires justification, optionally approval, and expires. Narrows the time axis. Manageable through ARM, so it can be IaC.
Principal type — User, Group, ServicePrincipal. Setting it on an assignment skips a Graph
lookup that races just-created identities.
RBAC Administrator (Role Based Access Control Administrator) — a narrower alternative to User Access Administrator, constrained in which roles it may assign ⚠️ verify current constraints. The right role for a deployment pipeline.
Reader — read every control-plane property in scope. No writes, no data.
Resource Graph — the estate-wide query engine (authorizationresources table) for questions like
"what assignments exist anywhere". Doesn't consume the ARM throttling budget that looping
az role assignment list does.
Resource lock — CanNotDelete or ReadOnly, applied to a scope and blocking operations for
everyone including Owner. Fails with ScopeLocked, which reads like a permissions error and isn't.
Role assignment — the grant. Microsoft.Authorization/roleAssignments, named with a GUID, binding
one principal to one role definition at one scope.
Role definition — the named set of permissions: four operation arrays plus assignableScopes.
Root scope (/) — the scope above every management group. Requires elevate access to see. Should
never appear in a pipeline.
ScopeLocked — the error code for a resource-lock refusal. Not RBAC.
Scope — where a grant applies: management group, subscription, resource group, resource, or sub-resource. Inherits downward, cannot be subtracted from below.
Security principal — anything assignable: user, group, service principal, or managed identity.
Service principal — the identity of an application in a tenant; the object that actually holds role assignments and gets tokens.
Shared key / SAS — service-native credentials that bypass RBAC entirely. Disable them
(allowSharedKeyAccess = false) or your role design is documentation.
Sub-resource scope — a scope below the resource: a single blob container, queue, or secret. Underused, and dramatically narrower than the parent.
User Access Administrator — may write role assignments and nothing else. Owner's dangerous half, isolated. Anyone holding it can grant themselves anything.
Workload identity federation — trusting an external OIDC provider (GitHub, Azure DevOps, GitLab, Kubernetes) for a specific subject, so a pipeline gets Azure tokens with no secret. The correct answer for anything outside Azure.
Resource ID shapes
Every error message, role assignment scope, and policy assignment is written against one of these.
# A role assignment (name is a GUID)
/subscriptions/{sub}/providers/Microsoft.Authorization/roleAssignments/{guid}
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Authorization/roleAssignments/{guid}
# A role definition (built-in role GUIDs are identical in every tenant)
/subscriptions/{sub}/providers/Microsoft.Authorization/roleDefinitions/{roleGuid}
# The four standard scopes, narrowest last
/providers/Microsoft.Management/managementGroups/{mgName}
/subscriptions/{sub}
/subscriptions/{sub}/resourceGroups/{rg}
/subscriptions/{sub}/resourceGroups/{rg}/providers/{provider}/{type}/{name}
# Sub-resource scopes — the underused narrow option
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{acct}/blobServices/default/containers/{container}
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault}/secrets/{secret}
# Root scope — requires elevate access
/An operation string, for reference:
{Provider}/{resourceType}/{operation} Microsoft.Compute/virtualMachines/restart/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/readCheatsheet
# ── WHO CAN DO WHAT ──────────────────────────────────────────────────────────
# Why does anyone have access here? --include-inherited is the flag that matters
az role assignment list -g rg-app --include-inherited -o table
# What does this principal hold, anywhere?
az role assignment list --assignee <object-id> --all -o table
# Everything privileged in the subscription
az role assignment list --all \
--query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].{role:roleDefinitionName, principal:principalName, scope:scope}" -o table
# ── GRANTING ─────────────────────────────────────────────────────────────────
# Always pass --assignee-object-id and --assignee-principal-type: skips the
# Graph lookup that races a just-created identity
az role assignment create \
--assignee-object-id "$OID" --assignee-principal-type ServicePrincipal \
--role "Storage Blob Data Reader" \
--scope "$(az storage account show -g rg-app -n stapp --query id -o tsv)/blobServices/default/containers/uploads" \
--description "payments API reads uploads"
az role assignment delete --assignee-object-id "$OID" --role "Storage Blob Data Reader" --scope "$SCOPE"
# ── FINDING THINGS ───────────────────────────────────────────────────────────
az role definition list --name "Storage Blob Data Reader" --query "[].id" -o tsv
az role definition list --custom-role-only true -o table
az provider operation show -n Microsoft.Storage # every action string available
# ── PRINCIPALS ───────────────────────────────────────────────────────────────
az ad signed-in-user show --query id -o tsv
az ad group show --group sg-payments-engineers --query id -o tsv
az webapp identity show -g rg-app -n app-payments --query principalId -o tsv
az identity show -g rg-app -n id-payments --query principalId -o tsv
# ── CLOSE THE PARALLEL DOORS (the highest-value free hardening) ──────────────
az storage account update -g rg -n stapp --allow-shared-key-access false
az keyvault update -g rg -n kv-app --enable-rbac-authorization true
az aks update -g rg -n aks-app --disable-local-accounts
az sql server ad-only-auth enable -g rg -n sql-app
# ── THE THINGS THAT LOOK LIKE RBAC AND AREN'T ────────────────────────────────
az lock list -g rg-app -o table # ScopeLocked
az policy state list --filter "complianceState eq 'NonCompliant'" -o table
# ── HYGIENE ──────────────────────────────────────────────────────────────────
# Orphaned assignments: principal no longer resolves
az role assignment list --all --query "[?principalName==null].{role:roleDefinitionName, oid:principalId, scope:scope}" -o table
# Direct-to-user assignments, which should be rare
az role assignment list --all --query "[?principalType=='User'].{principal:principalName, role:roleDefinitionName, scope:scope}" -o table
# Break-glass. Should page someone.
az rest --method post \
--url "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"The KQL query worth keeping
AzureActivity
| where OperationNameValue in~ (
"MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE",
"MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/DELETE",
"MICROSOFT.AUTHORIZATION/ROLEDEFINITIONS/WRITE",
"MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION")
| where ActivityStatusValue == "Success"
| extend props = parse_json(Properties)
| project TimeGenerated, OperationNameValue, Caller, CallerIpAddress,
scope = tostring(props.entity)
| order by TimeGenerated descTerraform, minimum viable
resource "azurerm_role_assignment" "example" {
scope = azurerm_storage_container.uploads.resource_manager_id # not .id
role_definition_name = "Storage Blob Data Reader"
principal_id = azurerm_user_assigned_identity.app.principal_id
principal_type = "ServicePrincipal" # skips the Graph lookup
description = "Managed by terraform"
}Roles worth knowing by name
| Role | Plane | Grants | Does not grant |
|---|---|---|---|
| Owner | Control | Everything, incl. role assignments | Any data access |
| Contributor | Control | Everything except role assignments | Role assignments; any data |
| Reader | Control | Read all control-plane properties | Any write; any data |
| User Access Administrator | Control | Role assignments only | Everything else |
| RBAC Administrator | Control | Role assignments, constrained | Everything else |
Storage Account Contributor |
Control | Manage the account and read its keys | Blob data directly (but keys are a back door) |
Storage Blob Data Reader / Contributor |
Data | Read / read-write blobs | Managing the account |
Key Vault Contributor |
Control | Manage the vault resource | Reading a secret |
Key Vault Secrets User |
Data | Read secret values | Managing the vault |
Azure Service Bus Data Sender |
Data | Send messages | Managing the namespace |
AcrPull |
Data | Pull images | Pushing; managing the registry |
Virtual Machine Contributor |
Control | Manage VMs | The VNet; the subscription |
Monitoring Reader |
Control | Read metrics, logs, alerts | Any write |
The rule: if you need to touch contents, look for Data in the role name.
Limits worth memorising — with the scope each is counted at
A number without a scope is useless in Azure.
| Limit | Counted at | Note |
|---|---|---|
| Role assignments | Per subscription | The one estates actually hit; groups are a 10–50× reduction ⚠️ verify current limit |
| Role assignments | Per management group | Separate, smaller ceiling ⚠️ verify |
| Custom role definitions | Per tenant | Shared across the whole estate ⚠️ verify |
| Groups in a token before overage | Per token | Beyond it, no group list in the token ⚠️ verify threshold |
| ABAC conditions | Per assignment | One condition, with a length cap ⚠️ verify |
| Management group nesting depth | Per tenant hierarchy | ⚠️ verify |
Almost all Azure quotas vary by region and subscription type. Verify before designing against a number.
The six things to remember
- A grant is principal + role + scope. Nothing else.
- Owner does not let you read a blob. Look for Data in the role name.
- There is no deny.
notActionssubtracts within one role; breadth is permanent until removed at its source. - Assign to groups, at the narrowest scope that works.
- Propagation is eventually consistent, in both directions. A fast retest proves nothing; a revocation isn't instant either.
- Close the parallel doors — shared keys, access policies, local accounts, SQL logins — or the whole model is documentation.
You've finished this topic. Next up in the article: pick another from the contents, or revisit Identity and RBAC in foundations now that the detail is in place.
← Back to the Azure RBAC overview · ← Previous: Interview Questions