Fixing Terraform Permission Errors in Azure

The two permission error messages

During terraform apply, Azure returns HTTP 403 responses that Terraform surfaces as one of two error messages:

Error: creating/updating Resource Group "myapp-rg" (Subscription: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"):
resources.ResourceGroupsClient#CreateOrUpdate: Failure responding to request:
StatusCode=403 -- Original Error: autorest/azure: Service returned an error.
Status=403 Code="AuthorizationFailed"
Message="The client 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with object id
'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not have authorization to perform
action 'Microsoft.Resources/subscriptions/resourcegroups/write' over scope
'/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' or the scope is invalid."

The second variant appears when Azure Policy blocks the action rather than RBAC:

Error: Code="RequestDisallowedByPolicy"
Message="Resource 'myapp' was disallowed by policy. Policy identifiers:
'[{\"policyAssignment\":{\"name\":\"Require tags on resources\",
\"id\":\"/subscriptions/.../policyAssignments/requiretags\"},
\"policyDefinition\":{\"name\":\"Require a tag on resources\"}}]'."

These require different fixes. The AuthorizationFailed error means an RBAC role assignment is missing. The RequestDisallowedByPolicy error means an Azure Policy assignment is blocking the operation — adding RBAC roles will not fix it.

Identify which identity Terraform is using

Before assigning roles, confirm which identity is running Terraform. The error message includes the object ID, but you need to map that to a service principal or managed identity.

Find the service principal by its object ID:

az ad sp show --id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --query "{displayName: displayName, appId: appId, servicePrincipalType: servicePrincipalType}" \
  --output json

If Terraform uses environment variables for authentication, check what is set:

# Typical Terraform environment variables for service principal auth
echo $ARM_CLIENT_ID
echo $ARM_TENANT_ID
echo $ARM_SUBSCRIPTION_ID
# ARM_CLIENT_SECRET should not be echoed but confirm it is set
printenv | grep ARM_

List current role assignments for the service principal:

SP_OBJECT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

az role assignment list \
  --assignee "$SP_OBJECT_ID" \
  --include-inherited \
  --include-groups \
  --output table

The --include-inherited flag shows roles assigned at parent scopes (subscription, management group) that are inherited at the resource group level.

Required roles for common Terraform operations

The minimum role needed depends on what Terraform is creating:

Contributor alone is insufficient when Terraform creates a resource and also assigns a role on it (for example, creating a storage account and granting a managed identity Storage Blob Data Contributor). For that, the service principal needs both Contributor and User Access Administrator.

Assigning the missing role with Azure CLI

Once you know what role is needed, assign it to the service principal:

SP_OBJECT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
SUBSCRIPTION_ID=$(az account show --query id -o tsv)

# Grant Contributor at subscription scope
az role assignment create \
  --assignee "$SP_OBJECT_ID" \
  --role "Contributor" \
  --scope "/subscriptions/$SUBSCRIPTION_ID"

# Grant User Access Administrator at a specific resource group
az role assignment create \
  --assignee "$SP_OBJECT_ID" \
  --role "User Access Administrator" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/myapp-rg"

After assigning the role, wait 2–5 minutes for the assignment to propagate, then retry terraform apply. Role assignment propagation is not immediate — retrying immediately after the assignment will still fail.

To verify the assignment took effect:

az role assignment list \
  --assignee "$SP_OBJECT_ID" \
  --scope "/subscriptions/$SUBSCRIPTION_ID" \
  --include-inherited \
  --output table

Finding which role covers a denied action

The error message includes the exact action that was denied, for example Microsoft.KeyVault/vaults/write. Use that action to find built-in roles that include it:

# Find roles that include a specific action
az role definition list \
  --query "[?contains(permissions[0].actions, 'Microsoft.KeyVault/vaults/write')].{name: roleName}" \
  --output table

For a more precise search, use the --custom-role-only false flag to include all roles:

az role definition list \
  --output json \
  | python3 -c "
import json, sys
roles = json.load(sys.stdin)
action = 'Microsoft.KeyVault/vaults/write'
for r in roles:
  for p in r.get('permissions', []):
    actions = p.get('actions', [])
    if any(action == a or a == '*' or
           (a.endswith('*') and action.startswith(a[:-1]))
           for a in actions):
      print(r['roleName'])
      break
"

For custom Terraform operations that require a very narrow set of permissions, create a custom role rather than assigning broad built-in roles:

# Create a minimal custom role for Terraform
cat > tf-custom-role.json << 'EOF'
{
  "Name": "Terraform Deployer",
  "Description": "Minimum permissions for Terraform deployments in myapp-rg",
  "Actions": [
    "Microsoft.Resources/subscriptions/resourceGroups/*",
    "Microsoft.Compute/virtualMachines/*",
    "Microsoft.Network/*",
    "Microsoft.Storage/storageAccounts/*"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myapp-rg"
  ]
}
EOF

az role definition create --role-definition @tf-custom-role.json

Service principal secret expired

A common Terraform failure that looks like a permission error is actually an authentication failure from an expired service principal secret. The error appears differently:

Error: building AzureRM Client: obtain subscription() from Azure CLI:
Error parsing json result from the Azure CLI: Error waiting for the Azure CLI:
exit status 1: ERROR: AADSTS7000222: The provided client secret keys for app
'xxxxxxxx' are expired.

Check the service principal’s credential expiry:

APP_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

az ad app credential list \
  --id "$APP_ID" \
  --query "[].{hint: hint, endDateTime: endDateTime}" \
  --output table

Rotate the secret:

# Create a new secret (valid for 1 year)
az ad app credential reset \
  --id "$APP_ID" \
  --years 1 \
  --query "{clientId: appId, clientSecret: password}" \
  --output json

Update the ARM_CLIENT_SECRET environment variable or pipeline secret with the new value. The old secret continues working until its expiry date, so creating a new one does not break existing sessions.