Troubleshoot deployment permissions without assigning Owner

You are trying to deploy a Bicep file that creates a role assignment, but the deployment fails with a permissions error. The first thing to check is the scope of the deployment command and the scope of the role assignment resource. Azure RBAC permissions are strictly scoped. If you are deploying to a resource group, you need permissions on that resource group. If you are deploying to a subscription, you need permissions on the subscription. The deployment command determines the context in which Azure validates your permissions.

Match the deployment scope to the permission requirement

When you use the Azure CLI to deploy a Bicep file, the command you choose dictates the required permissions. According to the deployment documentation, you need write access on the resources you are deploying and access to all operations on the Microsoft.Resources/deployments resource type Deploy Bicep files with the Azure CLI.

For a resource group deployment, you use az deployment group create. This requires permissions on the resource group itself. For a subscription deployment, you use az deployment sub create. This requires permissions on the subscription. If you try to deploy a role assignment scoped to a resource group using a subscription-level deployment command, the deployment will fail because you lack the necessary permissions on the Microsoft.Resources/deployments resource at the subscription scope for that specific operation, or the role assignment itself is being evaluated against the wrong scope.

The permissions required to deploy a Bicep file are not the same as the permissions required to manage the resources inside the deployment. For example, to deploy a virtual machine, you need Microsoft.Compute/virtualMachines/write and Microsoft.Resources/deployments/* permissions Deploy Bicep files with the Azure CLI. To deploy a role assignment, you need permissions to create the Microsoft.Authorization/roleAssignments resource at the target scope.

Verify role assignment syntax and scope

A role assignment is an extension resource. It applies to another resource, such as a storage account or a resource group. When you define a role assignment in Bicep, you must explicitly specify the scope if it differs from the file’s targetScope Use Bicep to create Azure role-based access control (Azure RBAC) resources.

param location string = resourceGroup().location
param storageAccountName string = 'stor${uniqueString(resourceGroup().id)}'
param storageSkuName string = 'Standard_LRS'
param roleDefinitionResourceId string
param principalId string

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
   name: storageSkuName
  }
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: storageAccount
  name: guid(storageAccount.id, principalId, roleDefinitionResourceId)
  properties: {
    roleDefinitionId: roleDefinitionResourceId
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

In this example, the role assignment is scoped to the storageAccount resource. The name property uses the guid() function to create a deterministic GUID based on the storage account ID, the principal ID, and the role definition ID. This ensures the role assignment name is unique and repeatable Use Bicep to create Azure role-based access control (Azure RBAC) resources.

If you do not explicitly specify the scope, Bicep uses the file’s targetScope. For example, if targetScope is set to subscription, the role assignment will be scoped to the subscription Use Bicep to create Azure role-based access control (Azure RBAC) resources. This is a critical distinction. A role assignment scoped to a resource group cannot be deployed using a subscription-level deployment command unless the role assignment itself is scoped to the subscription.

Check for existing role assignments

Another common cause of deployment failure is a conflict with an existing role assignment. Role assignment resource names must be unique within the Microsoft Entra tenant, even if the scope is narrower Use Bicep to create Azure role-based access control (Azure RBAC) resources. If you try to reuse a role assignment’s name for another role assignment, the deployment will fail.

When you delete a user, group, service principal, or managed identity from Microsoft Entra ID, any role assignments are not deleted automatically Use Bicep to create Azure role-based access control (Azure RBAC) resources. If you try to reuse a role assignment’s name for another role assignment, the deployment will fail. To work around this behavior, you should either remove the old role assignment before you recreate it, or ensure that you use a unique name when you deploy a new role assignment Use Bicep to create Azure role-based access control (Azure RBAC) resources.

Verify the principal type

The principalType property specifies whether the principal is a user, a group, or a service principal. Managed identities are a form of service principal. It is important to set the principalType property when you create a role assignment in Bicep. Otherwise, you might get intermittent deployment errors, especially when you work with service principals and managed identities Use Bicep to create Azure role-based access control (Azure RBAC) resources.

Use what-if to preview changes

Before deploying your Bicep file, you can preview the changes the Bicep file will make to your environment. Use the what-if operation to verify that the Bicep file makes the changes that you expect. What-if also validates the Bicep file for errors Deploy Bicep files with the Azure CLI. The what-if operation has the same permission requirements as the deployment itself.

To use what-if with a resource group deployment, you use az deployment group what-if. This command validates the Bicep file and checks your permissions without making any changes. This is a useful step to troubleshoot permissions issues before committing to a deployment.

Verify the deployment

Once the deployment succeeds, verify the role assignment exists at the intended scope. Use the az role assignment list command with the scope and principal ID to confirm the assignment was created correctly.

az role assignment list \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group-name> \
  --assignee <principal-id> \
  --output table

This confirms the role assignment is in place and the permissions are applied as expected.