Fixing Permission Denied Errors in Azure

Recognising the error

Azure permission errors typically appear as one of these messages:

The client '<identity>' with object id '<id>' does not have authorization
to perform action 'Microsoft.Storage/storageAccounts/write' over scope
'/subscriptions/<sub_id>/resourceGroups/myRG' or the scope is invalid.
If access was recently granted, please refresh your credentials.
(Code: AuthorizationFailed)

Resource 'myStorage' was disallowed by policy. Policy identifiers:
'[{"policyAssignment":{"name":"Deny-Public-Storage","id":"/subscriptions/..."},
"policyDefinition":{"name":"deny-public-blob-access"}}]'
(Code: RequestDisallowedByPolicy)

Caller is not authorized to access resource '/subscriptions/.../vaults/myVault/secrets/mySecret'.
(Code: Forbidden)

Each error code leads to a different diagnostic path. AuthorizationFailed means an RBAC role is missing. RequestDisallowedByPolicy means an Azure Policy is blocking the action. Forbidden on a Key Vault means either the RBAC data plane role or the Key Vault Access Policy is missing.

Step 1: Check the current RBAC assignments

Start by listing every role assignment for the identity that is receiving the error. This shows what roles are currently assigned and at what scope.

# List all role assignments for a user (by UPN)
az role assignment list \
  --assignee user@company.com \
  --all \
  --query "[].{Role:roleDefinitionName, Scope:scope}" \
  --output table

# List all role assignments for a service principal (by client ID)
az role assignment list \
  --assignee 00000000-0000-0000-0000-000000000001 \
  --all \
  --query "[].{Role:roleDefinitionName, Scope:scope}" \
  --output table

# Check if a specific role is assigned at the required scope
az role assignment list \
  --assignee user@company.com \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG \
  --query "[].roleDefinitionName" \
  --output table

Common findings at this step: the role is assigned at the wrong scope (e.g., assigned on resource group A but the resource is in resource group B), or the role exists but was deleted and re-created under a different object ID.

Step 2: Grant the missing RBAC role

Identify the specific action that was denied from the error message. Look up which built-in role includes that action using the Azure RBAC documentation or the CLI.

# Find which built-in roles contain a specific action
az role definition list \
  --query "[?contains(permissions[0].actions, 'Microsoft.Storage/storageAccounts/write')].{Name:roleName}" \
  --output table

# Assign the Storage Account Contributor role to a user on a specific resource group
az role assignment create \
  --assignee user@company.com \
  --role "Storage Account Contributor" \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG

# Assign a role to a managed identity (useful for fixing service-to-service errors)
az role assignment create \
  --assignee-object-id $(az webapp identity show --name myWebApp --resource-group myRG --query principalId -o tsv) \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/myStorage

Step 3: Check for Azure Policy denials

If the error code is RequestDisallowedByPolicy, the operation is allowed by RBAC but blocked by a policy assignment. The error message includes the policy assignment name and ID.

# List all policy assignments at the current scope
az policy assignment list \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG \
  --query "[].{Name:displayName, Effect:parameters.effect.value}" \
  --output table

# Get details of a specific policy assignment
az policy assignment show \
  --name Deny-Public-Storage \
  --scope /subscriptions/SUB_ID

# Check the policy definition to understand what is being denied
az policy definition show \
  --name deny-public-blob-access \
  --query "{DisplayName:displayName, Description:description, Rule:policyRule}"

Once you understand what the policy is blocking, you have two options: modify your operation to comply with the policy (the preferred approach — the policy exists for a reason), or request an exemption through your organisation’s Azure governance process. Never delete a policy assignment to work around it without going through the correct approval process.

Step 4: Key Vault specific permission issues

Key Vault permission errors are a frequent source of confusion because Key Vault has two distinct authorization models and many teams mix them up.

# Check which authorization model the Key Vault uses
az keyvault show \
  --name myKeyVault \
  --resource-group myRG \
  --query "properties.enableRbacAuthorization"
# Returns: true = RBAC model, false = Access Policy model

# If RBAC model: assign the appropriate data plane role
az role assignment create \
  --assignee user@company.com \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.KeyVault/vaults/myKeyVault

# If Access Policy model: add the identity to the access policy
az keyvault set-policy \
  --name myKeyVault \
  --resource-group myRG \
  --upn user@company.com \
  --secret-permissions get list \
  --key-permissions get list \
  --certificate-permissions get list

Step 5: Resource provider registration

A specific category of permission-like error occurs when attempting to create a resource whose resource provider is not registered in the subscription:

The subscription is not registered to use namespace 'Microsoft.ContainerService'.
(Code: MissingSubscriptionRegistration)

This is not a permission error but appears similar in the CLI output. Fix it by registering the provider:

# Register a resource provider
az provider register --namespace Microsoft.ContainerService --wait

# Verify registration status
az provider show --namespace Microsoft.ContainerService --query registrationState

Using the Activity Log for diagnosis

The Azure Activity Log records every management plane operation, including failed authorization attempts, with the full identity of the caller and the exact action that was attempted. This is invaluable for diagnosing intermittent permission errors or errors in automated pipelines where the error message may not be fully visible.

# View recent failed authorization events in a resource group
az monitor activity-log list \
  --resource-group myRG \
  --status Failed \
  --offset 1h \
  --query "[?authorization.action != null].{Time:eventTimestamp, Caller:caller, Action:authorization.action, Status:status.value}" \
  --output table