Cloud / Azure Role Based Access Control (RBAC) Interview questions

Azure role-based access control (Azure RBAC) is the authorization system built on Azure Resource Manager that decides who can do what, and on which resources. You grant access by assigning a role to a security principal at a particular scope.

Instead of giving someone blanket admin rights, you pick a role such as Reader, Contributor, or a narrower job-function role, and attach it to a user, group, service principal, or managed identity at a management group, subscription, resource group, or single resource.

Azure RBAC is additive and inherited: permissions from all your assignments are combined, and an assignment at a parent scope flows down to every child. It is enabled by default on every Azure subscription and has no extra cost.

An Azure RBAC grant always answers three questions: who gets access, what they can do, and where. Those map to four building blocks.

Deleting the assignment removes the access but leaves the role definition and principal untouched. The same role definition can be reused in thousands of assignments.

A security principal is the identity that receives a role assignment. Azure identifies it by its Microsoft Entra object ID, not by its display name or email.

Azure RBAC supports four kinds:

• User - a person with a Microsoft Entra account (including invited guests).
• Group - a Microsoft Entra security group; every member inherits the assignment.
• Service principal - the identity of an application or automation tool.
• Managed identity - an automatically managed service principal for an Azure resource, either system-assigned or user-assigned.

Because assignments point at object IDs, deleting and recreating a user with the same name does not bring the old access back.

A role definition is a named collection of permissions. It lists which operations a holder can perform and the scopes where the role may be assigned. Azure ships with more than 400 built-in definitions, and you can add your own.

The key properties are Actions, NotActions, DataActions, NotDataActions, and AssignableScopes. This is how the built-in Reader role is shaped:

{
  "roleName": "Reader",
  "description": "View all resources, but does not allow you to make any changes.",
  "type": "BuiltInRole",
  "permissions": [
    {
      "actions": [ "*/read" ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "assignableScopes": [ "/" ]
}

A definition grants nothing by itself. It only takes effect once a role assignment links it to a principal and a scope.

A role assignment is the object that actually grants access. It attaches one role definition to one security principal at one scope. Optionally it carries a description and a condition (ABAC) that narrows when the role applies.

Each assignment is stored as a resource of type Microsoft.Authorization/roleAssignments, and its name is a GUID. You need the Microsoft.Authorization/roleAssignments/write permission at that scope to create one, which Owner, User Access Administrator, and Role Based Access Control Administrator have.

Assignments are additive. If a user has Reader on a subscription and Contributor on one resource group, they are effectively a Contributor inside that group and a Reader everywhere else in the subscription.

Azure RBAC has four scope levels, arranged in a hierarchy. You can assign a role at any of them:

flowchart TD
  A["Tenant Root Management Group"] --> B["Management group"]
  B --> C[Subscription]
  C --> D["Resource group"]
  D --> E[Resource]

• Management group - groups subscriptions so one assignment covers many of them.
• Subscription - a billing and isolation boundary.
• Resource group - a lifecycle container for related resources.
• Resource - a single VM, storage account, key vault, and so on.

A scope is written as an ID path, for example /subscriptions/<id>/resourceGroups/rg-app. The narrower the scope, the smaller the blast radius.

Role assignments are inherited downward. A role assigned at a parent scope applies automatically to every child scope below it. Contributor on a subscription means Contributor on every resource group and resource inside that subscription, including ones created later.

Inheritance only flows down. A role on a single resource never leaks up to its resource group.

You cannot remove an inherited assignment at the child level, and there is no way to carve out an exception from a parent assignment. If a team should only reach some resource groups, assign the role on those groups instead of at the subscription.

In the portal, the Role assignments tab shows an inherited entry with a Scope column pointing at the parent, so you can tell where it came from.

Almost every Azure role traces back to four fundamentals. Three are general-purpose and one is about access management.

Beyond these, Azure offers many job-function roles (for example Virtual Machine Contributor or Storage Blob Data Reader) that grant access to one service only. Prefer those over the fundamentals whenever one fits.

Both can create, update, and delete any resource. The difference is access management: Owner can grant and remove access, Contributor cannot.

Contributor has Actions: *, but its NotActions remove Microsoft.Authorization/*/Write, Microsoft.Authorization/*/Delete, and the elevate-access action. That blocks role assignments, role definition changes, and locks.

Giving app teams Contributor on their own resource group is the usual pattern. Reserve Owner for a very small number of people, ideally through just-in-time activation.

User Access Administrator lets a principal manage access to Azure resources, and nothing else. It grants Microsoft.Authorization/* so the holder can create and delete role assignments at the scope, but it does not allow creating or changing resources like VMs or databases.

It is useful for access-governance teams or delegated onboarding processes that must grant access without touching workloads.

The role is powerful despite its narrow purpose. A holder can assign themselves Owner, so treat it like Owner and keep it time-bound with Privileged Identity Management. When you only need to delegate specific role assignments, the Role Based Access Control Administrator role with conditions is a safer choice.

Azure RBAC governs Azure resources. Microsoft Entra roles govern the directory itself: users, groups, applications, and tenant settings. The two systems are separate, and a role in one does not give access in the other.

The one bridge is elevate access: a Global Administrator can temporarily grant themselves User Access Administrator over all Azure subscriptions in the tenant.

Actions lists the management operations a role allows, written as {Provider}/{resourceType}/{action}, with wildcards permitted. NotActions removes specific operations from that allowed set.

For example, Microsoft.Compute/virtualMachines/* allows every VM operation, while Microsoft.Compute/virtualMachines/delete in NotActions carves out deletion.

NotActions is not a deny. It only subtracts from the same role's list. If the user holds another role, at this scope or inherited, that allows the operation, they can still perform it. For a true block, you need a deny assignment.

"actions": [ "Microsoft.Compute/virtualMachines/*" ],
"notActions": [ "Microsoft.Compute/virtualMachines/delete" ]

DataActions list operations on the data inside a resource, such as reading a blob, getting a secret, or sending a Service Bus message. NotDataActions subtract from that list the same way NotActions does for management operations.

A data action looks like Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. This is what separates Storage Blob Data Reader from the plain Reader role, which cannot read blob contents.

Wildcards in Actions do not include data actions. Owner has Actions: *, yet that does not by itself grant blob or secret access over Microsoft Entra authentication. Data permissions must be granted explicitly through a role carrying DataActions.

AssignableScopes defines where a role can be assigned. A role can only be used at the scopes listed there, or below them.

Built-in roles are assignable at root (/), so they work everywhere. For custom roles, you list management groups, subscriptions, or resource groups, for example /subscriptions/<id>. Listing several subscriptions shares one custom role across them, as long as they trust the same Microsoft Entra tenant.

Two practical rules: you need Microsoft.Authorization/roleDefinitions/write on every assignable scope to create the role, and a custom role that contains DataActions cannot be assignable at management group scope.

Least privilege means giving a principal only the access needed for the task, at the narrowest scope, for the shortest time. In Azure RBAC that comes down to three choices: the role, the scope, and the duration.

1. Role - choose a job-function role (Virtual Machine Contributor) over a fundamental one (Contributor), and Contributor over Owner.
2. Scope - assign on the resource group or resource that the work touches, not on the subscription.
3. Duration - use Privileged Identity Management so elevated roles are eligible and expire after hours, not permanent.

A quick test: if a person with Contributor at subscription level only ever manages one app, you can move the assignment to that app's resource group with no loss of function and much less exposure.

You need a role with Microsoft.Authorization/roleAssignments/write at the target scope, such as Owner or User Access Administrator. Then:

1. Open the resource, resource group, subscription, or management group and select Access control (IAM).
2. Choose Add and then Add role assignment.
3. On the Role tab, pick a job-function role or a privileged administrator role.
4. On the Members tab, select the user, group, service principal, or managed identity.
5. Optionally add a condition if the role supports it.
6. Select Review + assign to save.

The Check access tab on the same blade lets you confirm afterwards what a specific principal can do at that scope.

Use az role assignment create with the principal, the role name or ID, and the scope.

az role assignment create \
  --assignee-object-id <object-id> \
  --assignee-principal-type Group \
  --role "Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-app

Passing --assignee-object-id together with --assignee-principal-type (User, Group, or ServicePrincipal) skips a Microsoft Graph lookup. That makes scripts faster and avoids PrincipalNotFound errors right after a new identity is created.

If you omit --scope, the CLI uses the current subscription. Check with az account show before running it so you do not assign at the wrong level.

Both tools can filter by principal, scope, or role. The CLI command is az role assignment list; PowerShell uses Get-AzRoleAssignment.

# Azure CLI
az role assignment list --assignee user@contoso.com --all --output table
az role assignment list --resource-group rg-app --include-inherited -o table
az role assignment list --scope /subscriptions/<sub-id> --role Owner -o table

# Azure PowerShell
Get-AzRoleAssignment -SignInName user@contoso.com
Get-AzRoleAssignment -ResourceGroupName rg-app

By default the CLI only shows assignments at the current scope. Add --all to include the whole subscription, --include-inherited to see assignments from parent scopes, and --include-groups to also show roles the user receives through group membership.

Delete the assignment at the same scope where it was created. You need Microsoft.Authorization/roleAssignments/delete there, which Owner and User Access Administrator have.

az role assignment delete \
  --assignee <object-id-or-upn> \
  --role "Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-app

# PowerShell
Remove-AzRoleAssignment -ObjectId <object-id> -RoleDefinitionName "Reader" -Scope "/subscriptions/<sub-id>/resourceGroups/rg-app"

Two things to remember. Removing an assignment at a parent scope removes the inherited access from every child, and removing at a child scope will not touch an assignment inherited from above. The change can also take several minutes to be effective everywhere.

A custom role is a role definition you write yourself when no built-in role matches the permissions you need. It has the same structure as a built-in one: Actions, NotActions, DataActions, NotDataActions, and AssignableScopes.

Typical reasons are least privilege (a role that can start and stop VMs but not delete them) or a job function Microsoft does not ship. Each tenant can hold up to 5,000 custom roles, and a custom role can be shared across subscriptions in the same tenant.

You can create one in the Azure portal, Azure CLI, PowerShell, or the REST API. Creating it needs Microsoft.Authorization/roleDefinitions/write on every assignable scope, which Owner and User Access Administrator have.

Write the role as JSON, then pass it to az role definition create. This example lets operators start, restart, and deallocate VMs, but not delete them.

{
  "Name": "VM Operator",
  "IsCustom": true,
  "Description": "Start, restart and deallocate VMs. Read-only otherwise.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "AssignableScopes": [ "/subscriptions/00000000-0000-0000-0000-000000000000" ]
}

az role definition create --role-definition ./vm-operator.json
az role definition update --role-definition ./vm-operator.json

Find the exact action strings with az provider operation show --namespace Microsoft.Compute. To delete a custom role, first remove all of its role assignments.

Managing a VM and signing in to it are separate permissions, so Azure offers distinct roles.

The two login roles only work when the VM has the Microsoft Entra login extension enabled. A common pairing is Virtual Machine Contributor for the platform team and Virtual Machine User Login for developers.

Storage Blob Data Contributor is a built-in role that grants read, write, and delete access to blob containers and blobs through Microsoft Entra authentication. It is a data-plane role, so it uses DataActions rather than Actions.

It does not let the holder manage the storage account itself. Changing replication or firewall settings needs a management role such as Storage Account Contributor. The matching read-only role is Storage Blob Data Reader.

Being Owner of a subscription does not give blob access over Entra ID. The data role must be assigned, ideally on the specific storage account or container. With the CLI, add --auth-mode login so the command uses your Entra identity.

az storage blob list --account-name stappdata --container-name logs --auth-mode login

Locks and RBAC are independent controls, and a lock wins. A CanNotDelete lock blocks deletion and a ReadOnly lock blocks modification, even for an Owner.

A user needs a role with Microsoft.Authorization/locks/* to create or remove a lock. Only Owner and User Access Administrator include it. Contributor does not, so a Contributor cannot remove a lock placed by someone else.

Locks apply to management operations only. A ReadOnly lock on a storage account does not stop data reads, but it does block listKeys because that is a POST action, which can surprise teams.

When a deployment fails with ScopeLocked, the roles are fine. Check for a lock at the resource, its resource group, or the subscription.

The control plane manages the resource itself, through Azure Resource Manager. The data plane works with what the resource holds, through the service's own endpoint. Azure RBAC secures both, but with different permission fields.

Owner and Contributor have full control-plane rights but no data-plane rights on services that support Entra data roles. Many incidents come from forgetting one side: the pipeline can create the storage account yet fails to upload to it.

Azure RBAC is additive. For each request it gathers every role assignment that applies to the caller at the target scope and above, merges their allowed operations, and checks whether the requested operation is in the result. If it is, access is granted. If not, it is denied by default.

flowchart TD
  A["Request arrives"] --> B{Deny assignment matches?}
  B -- Yes --> X["Access denied"]
  B -- No --> C["Collect role assignments at scope and parents"]
  C --> D{Any role allows the action?}
  D -- No --> X
  D -- Yes --> E{Assignment condition true?}
  E -- No --> X
  E -- Yes --> F["Access allowed"]

There is no priority between roles, so a more restrictive role cannot cancel a broader one. The only explicit blocker is a deny assignment, which is checked first. Locks and Azure Policy are evaluated separately from RBAC.

A deny assignment blocks specific actions for specific principals at a scope, even if a role assignment would allow them. It is the only real deny mechanism in Azure RBAC, and it is evaluated before role assignments.

Users cannot create deny assignments directly. Azure creates them on your behalf for features such as managed applications and deployment stacks (deny settings), to protect managed resources from accidental edits.

A deny assignment has Actions, NotActions, DataActions, NotDataActions, a list of Principals, ExcludePrincipals, and a DoNotApplyToChildScopes flag. You can see them on the IAM blade under the Deny assignments tab, or with Get-AzDenyAssignment in PowerShell.

If a request is rejected even though the role looks correct, check whether a deny assignment from a managed application is in the way.

Azure RBAC controls who can act. Azure Policy controls what resources are allowed to look like, no matter who acts. They complement each other.

An error tells you which one stopped the request: AuthorizationFailed points to RBAC, while RequestDisallowedByPolicy points to Azure Policy.

Assigning to a Microsoft Entra security group makes access follow membership, not individual assignments. That brings several concrete benefits:

• Fewer assignments. One group assignment replaces dozens of user ones, which matters because a subscription is capped at 4,000 role assignments.
• Simple joiners and leavers. Adding or removing a member changes access without touching Azure RBAC at all.
• Easier reviews. Microsoft Entra access reviews can recertify group membership on a schedule.
• Dynamic access. Dynamic groups can add members automatically based on attributes such as department.
• Cleaner audit. You read a handful of group assignments instead of hundreds of user ones.

A readable naming convention such as az-rbac-<scope>-<role> keeps it obvious what each group does.

A managed identity is a service principal that Azure creates and rotates credentials for. It has no access by default. You grant it access exactly like a user, with a role assignment, and the app then requests tokens without storing any secret.

There are two types. System-assigned identities live and die with one resource. User-assigned identities are standalone and can be attached to many resources.

az vm identity assign -g rg-app -n vm1
PID=$(az vm show -g rg-app -n vm1 --query identity.principalId -o tsv)
SA=$(az storage account show -g rg-app -n stappdata --query id -o tsv)

az role assignment create \
  --assignee-object-id $PID \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope $SA

Always set the principal type when scripting. A freshly created identity may not have replicated yet, and without it the call can fail with PrincipalNotFound.

Give the pipeline its own service principal and assign it a narrow role at the narrowest scope it deploys to. Never reuse a human account.

The preferred authentication method is workload identity federation (OIDC), which lets GitHub Actions or Azure Pipelines exchange a short-lived token for Azure access, so no client secret is stored.

# app registration + service principal
az ad sp create-for-rbac --name sp-deploy-app \
  --role Contributor \
  --scopes /subscriptions/<sub-id>/resourceGroups/rg-app

After creating the principal, add a federated credential to the app registration for your repository or pipeline. If the pipeline also assigns roles inside its templates, it needs more than Contributor, for example Role Based Access Control Administrator limited by conditions.

Scope it to the resource group the pipeline deploys to, not the subscription.

Assign the Key Vault Secrets User role to the app's identity on the vault, or on one individual secret. It allows reading secret values and nothing else.

This works only when the vault uses the Azure RBAC permission model. A vault still on access policies ignores role assignments for data access.

az keyvault update --name kv-app --enable-rbac-authorization true

az role assignment create \
  --assignee-object-id <managed-identity-principal-id> \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.KeyVault/vaults/kv-app

Related roles: Key Vault Secrets Officer can manage secrets, Key Vault Reader sees only metadata, and Key Vault Administrator has full data access. For one secret, extend the scope with /secrets/<name>.

Access policies are the older model: permissions are stored inside each vault, one policy per principal, applying to every secret, key, and certificate in it. Azure RBAC uses the same role system as the rest of Azure.

The last row is the security problem. Contributor includes Microsoft.KeyVault/vaults/write, so a Contributor can add an access policy for themselves and read every secret. With RBAC, Contributor cannot grant itself data access.

Azure supports up to 4,000 role assignments per subscription. The count includes assignments at the subscription, resource group, and resource scopes, but not those at management group scope. This limit is fixed and cannot be raised through support.

Management groups have their own cap of 500 role assignments each.

When you reach the limit, new assignments fail with RoleAssignmentLimitExceeded. This often hits subscriptions where people grant access to individual users or on many single resources. Orphaned assignments from deleted users still count, so cleaning them is the first quick win.

To count your usage, query role assignments with Azure Resource Graph or list them with az role assignment list --all and see how many rows come back.

Most changes take effect within a few minutes. Microsoft documents up to 10 minutes for a new or removed assignment to propagate fully, because Azure Resource Manager caches authorization data.

Some situations take longer:

• Cached tokens. A token already issued keeps working with the old permissions until it is refreshed. Signing out and in, or running az login again, forces a new one.
• Managed identities. Their tokens are cached by the Azure back end, and changes can take hours, in some cases up to 24, to show up.
• Group membership. Adding a user to a group is an Entra change, so the user may need a new token before the group's roles apply.

If a pipeline runs immediately after granting access, add a retry with a short delay instead of assuming the role is live.

The role assignments are not removed. Because they reference the object ID, they stay behind as orphans, shown as Identity not found or Unknown in the portal.

The deleted user loses access immediately, but the orphans cause two problems: they still count toward the 4,000 assignment limit, and they clutter audits. If the user is restored from Entra's soft-delete period with the same object ID, the assignments come back to life.

Recreating a user with the same name gets a new object ID and none of the old access. Find orphans in PowerShell and delete them:

Get-AzRoleAssignment |
  Where-Object { $_.ObjectType -eq "Unknown" } |
  Remove-AzRoleAssignment

Azure allows only one assignment per unique combination of principal, role definition, and scope. If that exact trio already exists, a second create call is rejected with RoleAssignmentExists.

Common causes:

• A script or pipeline re-runs and creates the same assignment again.
• Someone granted the same access manually earlier.
• An infrastructure template uses a random name for the assignment on each run, so Azure sees duplicates instead of an update.

A related error is RoleAssignmentUpdateNotPermitted. It appears when a template reuses an existing assignment name but with a different principal, role, or scope, since those properties cannot be edited.

The fix for templates is a deterministic name, such as guid(scope.id, principalId, roleDefinitionId). For scripts, check with az role assignment list first, or treat the error as success.

AuthorizationFailed means Azure RBAC found no role granting the action. The error message already tells you the caller's object ID, the action, and the scope. Work through it in order:

1. Read the message. Note the exact action (for example Microsoft.Compute/virtualMachines/write) and the scope.
2. Confirm the identity and subscription. Run az account show to rule out the wrong tenant or subscription.
3. List the caller's assignments at that scope including inherited ones.
4. Check the role covers the action. Inspect its permissions for the action string.
5. Look for blockers. Deny assignments, resource locks, and ABAC conditions can also stop it.
6. Rule out delay. Wait up to 10 minutes and refresh the token.

az role assignment list --assignee <object-id> --scope <scope> --include-inherited --all -o table
az role definition list --name "Virtual Machine Contributor" --query "[].permissions[].actions"

Remember that a data-plane operation needs a DataActions role, so Contributor will not fix a failing blob read.

Prefer built-in roles by default. Microsoft maintains them, so when a service adds new operations the role is updated for you. Choose a custom role only when no built-in role fits without granting too much.

Good reasons for a custom role:

• The closest built-in role is too broad, for example Contributor when someone only needs to restart VMs.
• You need to combine permissions from several services into one job function.
• You want to exclude a dangerous operation by adding it to NotActions.

The costs are real. You maintain the JSON yourself, new provider actions are not added automatically, wildcards may silently grant new rights, and the tenant cap is 5,000 custom roles. Keep a small, well-named catalog, store the definitions in source control, and review them regularly.

Assign a role at a management group and every subscription underneath inherits it. This is how you give a platform or security team consistent access across dozens of subscriptions with one assignment.

az role assignment create \
  --assignee-object-id <group-object-id> \
  --assignee-principal-type Group \
  --role "Reader" \
  --scope /providers/Microsoft.Management/managementGroups/mg-platform

Points to watch:

• Role assignments at management group scope do not count toward a subscription's 4,000 limit, but each group has its own cap of 500.
• A custom role can list a management group in AssignableScopes, but only if it contains no DataActions.
• You need permissions on the management group itself to read or write assignments there. Subscription Owner is not enough.
• Changes can take longer to show up than subscription-level ones.

Elevate access lets a Microsoft Entra Global Administrator grant themselves the User Access Administrator role at root scope (/), which covers every subscription and management group in the tenant. It is a break-glass feature for recovering from situations like an owner leaving the company or a subscription nobody can manage.

You turn it on in the Microsoft Entra admin center under Properties by switching Access management for Azure resources to Yes, or with the REST API.

az rest --method post \
  --url "/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"

Use it briefly: assign the needed roles, then remove the root-scope assignment, because it is a very broad permission. The actions are recorded in the directory and Azure logs, so review them.

Role Based Access Control Administrator is a built-in role that can manage access to Azure resources by creating and deleting role assignments. Unlike User Access Administrator, it is designed to be constrained with conditions.

A condition can limit which roles the holder may assign, which principal types they may assign to, or both. For example, a team lead can be allowed to give developers only Reader and Virtual Machine Contributor on their subscription, but never Owner.

This solves the escalation problem of User Access Administrator, where the holder can assign any role, including Owner, to themselves. Delegation becomes safe enough to hand to application teams.

The role cannot manage access through other means, such as Azure Policy, and it does not create custom role definitions.

Attribute-based access control (ABAC) adds an extra check to a role assignment. The role still has to allow the action, and the condition must also evaluate to true, based on attributes of the resource or the request.

The classic example is storage. You can give a user Storage Blob Data Reader on a whole account but limit it to one container:

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
 )
 OR
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals 'project-a'
 )
)

Other attributes include blob index tags and, for role-assignment delegation, the role being assigned. Conditions only work with roles whose actions support them.

They also reduce the number of assignments. One conditional assignment replaces many container-level ones, which helps with the 4,000 limit.

Privileged Identity Management (PIM) makes Azure role assignments just-in-time. Instead of holding Owner all day, a user is eligible and must activate the role when needed. The activation expires automatically, usually after a few hours. PIM needs Microsoft Entra ID P2 or ID Governance licensing.

To use it, you onboard the subscription or management group in PIM, then convert permanent assignments for privileged roles such as Owner, Contributor, and User Access Administrator to eligible.

Benefits: a smaller attack window, a clear activation audit trail, and less standing privilege. Eligible assignments also help with the role assignment limit because they are not counted as active assignments.

Every role assignment and role definition change is recorded in the Azure Activity Log. The key operations are Microsoft.Authorization/roleAssignments/write, .../roleAssignments/delete, and Microsoft.Authorization/roleDefinitions/write.

The Activity Log keeps data for only 90 days, so send it to a Log Analytics workspace through diagnostic settings for long-term queries and alerts.

AzureActivity
| where OperationNameValue in~ (
    "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE",
    "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/DELETE")
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, OperationNameValue, Properties
| order by TimeGenerated desc

To see the current state across subscriptions, query the authorizationresources table in Azure Resource Graph. For ongoing hygiene, add an alert on Owner assignments and schedule Microsoft Entra access reviews.

With a hard cap of 4,000 assignments per subscription, the goal is to replace many narrow assignments with fewer broader ones without increasing real privilege. Start by finding where the assignments come from:

authorizationresources
| where type =~ "microsoft.authorization/roleassignments"
| extend principalId = tostring(properties.principalId),
         principalType = tostring(properties.principalType)
| summarize assignments = count() by principalId, principalType
| order by assignments desc

Then apply these fixes, roughly in order of effort:

1. Delete orphans left behind by deleted identities.
2. Swap users for groups. One group assignment replaces many user assignments.
3. Remove duplicates where a role is already inherited from a higher scope.
4. Combine roles. One custom role can replace several built-in assignments for the same principal.
5. Use conditions so one assignment covers what used to be many resource-level ones.
6. Make privileged roles eligible in PIM.
7. Move to management group scope where it is appropriate, since those are not counted.

Declare each assignment as a Microsoft.Authorization/roleAssignments resource, set its scope, and give it a deterministic name using guid() so re-deployments are idempotent.

param principalId string
param storageName string

resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' existing = {
  name: storageName
}

var blobReaderRoleId = '2a2b9908-6ea1-4ae2-8e65-a410df84e7d1' // Storage Blob Data Reader

resource blobReader 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(storage.id, principalId, blobReaderRoleId)
  scope: storage
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', blobReaderRoleId)
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

Three habits keep this reliable: always set principalType to avoid replication errors with new identities, use role definition GUIDs instead of names, and make sure the deploying identity itself has a role-assignment permission. Terraform does the same with azurerm_role_assignment.

When you call a management API, Azure Resource Manager (ARM) is the front door, and it performs the authorization check before the request reaches the resource provider.

sequenceDiagram
  participant C as Client
  participant E as Microsoft Entra ID
  participant A as Azure Resource Manager
  participant R as Resource Provider
  C->>E: Sign in, request token for management.azure.com
  E-->>C: Access token (object ID, tenant, claims)
  C->>A: API call with bearer token
  A->>A: Validate token
  A->>A: Gather role assignments at scope and parents
  A->>A: Check deny assignments, then role actions and conditions
  alt allowed
    A->>R: Forward request
    R-->>C: Result
  else not allowed
    A-->>C: 403 AuthorizationFailed
  end

1. Token. The caller gets a token for ARM. It carries the object ID and tenant.
2. Validation. ARM checks signature, audience, and expiry.
3. Assignment lookup. ARM finds assignments for the principal and its group memberships at the target scope and every parent scope.
4. Evaluation. Deny assignments are checked first, then whether some role allows the action and any condition is true.
5. Forward or reject. If allowed, the request goes to the resource provider; otherwise it returns 403.

For the data plane, the service itself, such as Storage or Key Vault, validates the token and performs the equivalent check against DataActions. Locks and Azure Policy run as separate checks.

Because Contributor includes Microsoft.Storage/storageAccounts/listKeys/action. Anyone who can list the account keys can authenticate with Shared Key, and that bypasses Azure RBAC data roles entirely. It gives full read, write, and delete over all data in the account.

So a Contributor with no data role can still read every blob. It is a hidden privilege escalation from the control plane to the data plane, and it makes data-plane RBAC meaningless if left open.

How to close the gap:

1. Disable shared key authorization on the account: az storage account update -n stappdata -g rg-app --allow-shared-key-access false.
2. Use Microsoft Entra ID with data roles such as Storage Blob Data Contributor.
3. Avoid giving Contributor on storage accounts to people who should not see data. Use a custom role without listKeys.
4. If keys must exist, rotate them and store them in Key Vault.

The same pattern exists with SAS tokens: anyone who holds the key can mint them.

Design around management groups, Entra groups, and the narrowest useful scope. Roles flow from the top of the hierarchy to workloads, and guardrails come from Azure Policy, not from trusting individuals.

1. Groups only. Every assignment targets a Microsoft Entra group named by scope and role.
2. PIM for privileged roles. Owner and User Access Administrator are eligible and time-bound. Microsoft advises keeping subscription owners to a small number.
3. Delegate safely. App leads get Role Based Access Control Administrator with conditions, not Owner.
4. Custom roles at management group scope, control plane only, kept in source control.
5. Policy guardrails for location, tags, and allowed SKUs, so Contributor is safe to hand out.
6. Break-glass accounts and an elevate-access procedure for emergencies.
7. Audit. Activity Log to Log Analytics plus periodic access reviews.