DeployIfNotExists permissions, how to avoid remediation failures

DINE stands for DeployIfNotExists. The effect ensures missing resources are automatically deployed when needed. When remediation fails the cause is usually missing permissions for the identity assigned to the policy. The assignment’s Managed Identity (MI) needs the right Role Based Access Control (RBAC) role at the correct scope to deploy the template. Without those rights the remediation job will produce errors and no changes will occur.

Why DINE fails, the real reason is usually missing permissions

When a policy with a DeployIfNotExists effect evaluates compliance, it checks whether the resource exists and whether it matches the required configuration. If the check fails, the remediation task runs an Azure Resource Manager (ARM) template to deploy or configure the missing element. For security reasons the template does not run with your own permissions, it runs under the identity attached to the policy assignment. If that identity lacks the required actions at the target scope, the deployment fails. The most common error messages, such as “AuthorizationFailed” or “LinkedAuthorizationFailed”, often point to missing role assignments rather than faulty templates. Microsoft’s documentation notes that DINE assignments must include an identity because the deployment needs permission to create or configure resources【129551314255150†screenshot】.

The moving parts: assignment identity, remediation task, roleDefinitionIds

A DeployIfNotExists policy involves a few moving parts. Firstly the caller, a human or a pipeline, creates the resources and assigns the policy. The policy assignment includes a Managed Identity, either system assigned or user assigned, which will be used for any remediation. When the policy evaluates, the engine uses the caller’s permissions to read the state but uses the assignment’s identity to deploy any remedial template. Separating the identities means you must grant the assignment identity the specific actions required by the template. The policy definition’s roleDefinitionIds property lists the built‑in or custom roles needed, but these entries are only hints; you still have to assign those roles at the correct scope.

Think of the process as a relay. The caller reads the resource, the policy decides the resource is missing or misconfigured, and then hands the baton to the assignment identity to run the template. If the identity cannot create the resource in the specified resource

group or subscription, the race stops.

Scope it right: where to assign roles for cross‑resource deployments

You need to assign roles at the scope where the remediation writes. Many policies deploy into the same scope that they evaluate, but you can override this behaviour with existanceScope, deploymentScope and resourceGroupName fields. For example, if you deploy diagnostic settings to storage accounts and send the logs to a central Log Analytics workspace, your template writes into both the storage account and the workspace. The assignment identity must have Microsoft.Insights/diagnosticSettings/* actions on each storage account and the workspace. Granting rights at subscription or resource group level simplifies management but increases blast radius. Granting rights at the exact resource scope minimises risk but means you must manage many assignments.

Least privilege examples: storage diagnostics vs private endpoint

Consider a policy that deploys diagnostic settings to all storage accounts. The built in Monitoring Contributor role includes the ability to write diagnostic settings but not to manage the storage data plane. Assign the Monitoring Contributor role to the policy’s identity at the resource group containing the storage accounts. If the template also creates a data collection rule or sends logs to a workspace, grant the minimal roles on those resources too. A broad Contributor role is unnecessary and increases risk.

Another example is deploying a Private Endpoint. This operation spans two resources: the virtual network or subnet and the target resource. The identity must have the Network Contributor role on the virtual network to create the endpoint and must have permissions to approve the private endpoint connection on the target resource. You can achieve this with a custom role granting only privateEndpointConnections/write on the target resource and Microsoft.Network/privateEndpoints/write on the network. Alternatively you can assign Contributor on both resources, but that violates least privilege.

How to test DINE permissions before production

Testing is vital. You can set enforcementMode of the policy assignment to DoNotEnforce to run the policy in audit and deploy mode without blocking resource creation. Then trigger an on demand scan using az policy state trigger-scan at the scope of the assignment. Monitor the remediation jobs and check the results via the Azure portal or by running az policy state summarize. To check role assignments, run az role assignment list --assignee <principalId> --all --include-inherited to see what the identity can do. If the identity is missing required roles, add them before enforcing the policy.

Troubleshooting: LinkedAuthorizationFailed and other common errors

If a remediation fails with AuthorizationFailed, the identity is missing permissions at the scope where the template writes. Add the required built in or custom role. LinkedAuthorizationFailed means the template is creating or modifying a linked resource, such as deploying into a different resource group, and the identity lacks permission on that linked scope. Ensure the identity has rights on both the evaluated resource and the target resource group or subscription. Another common issue is MissingSubscriptionRegistration which occurs when the subscription has not registered the provider required by the template. Register the provider using the portal or az provider register.

Example: wiring a user assigned identity for a policy assignment

Here is a minimal example of a policy definition that deploys diagnostic settings and lists the roles required:

json

{

'properties': {

'displayName': 'Deploy diagnostic settings to Storage',

'policyRule': {

'if': {

'field': 'type',

'equals': 'Microsoft.Storage/storageAccounts'

},

'then': {

'effect': 'deployIfNotExists',

'details': {

'type': 'Microsoft.Insights/diagnosticSettings',

'roleDefinitionIds': [

'/providers/Microsoft.Authorization/roleDefinitions/<MonitoringContributorRoleId>'

],

'deploymentScope': 'ResourceGroup',

'deployment': {

'properties': {

'mode': 'incremental',

'template': {

'$schema': 'http://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#',

'contentVersion': '1.0.0.0',

'resources': [

// template body

]

}

}

}

}

}

}

}

}

To assign the policy, create or select a user assigned identity, attach it to the policy assignment with az policy assignment identity assign, and then assign the Monitoring Contributor role at the resource group containing the storage accounts using az role assignment create --assignee <principalId> --role 'Monitoring Contributor' --scope <resourceGroupScope>. This provides only the necessary rights.

Operational tips for large estates and Lighthouse scenarios

In large organisations with many subscriptions, you need consistency. Decide whether to grant remediation roles at subscription level or resource group level and apply that rule consistently. Tools such as Enterprise Policy as Code can derive the required roles from the roleDefinitionIds entries and generate infrastructure as code for the assignments. For cross tenant scenarios via Azure Lighthouse, you must create the managed identity in the customer’s tenant and grant the managing tenant a User Access Administrator role at the scope required to assign the remediation roles. Then assign the minimal roles in the customer tenant so that the remediation can run but nothing more.

Next steps and a hardening checklist

DeployIfNotExists is powerful but demands careful configuration. Start by reading our Azure Policy basics and testing guide. Then follow our hardening checklist:

1. Define roleDefinitionIds in every DeployIfNotExists or Modify policy to document the required permissions.

2. Use a user assigned Managed Identity for critical policies so that you can rotate it independently and audit its assignments.

3. Assign only the minimal built in or custom roles required by the template at the narrowest scope possible.

4. Test assignments in non enforcing mode and trigger scans before enforcing them in production.

5. If your policy deploys resources across scopes, mirror those scopes in your role assignments.

6. For Lighthouse scenarios, grant User Access Administrator only on the specific scopes needed to assign roles, and remove it afterwards.

7. Keep a runbook of common remediation errors and fixes.

Following these steps reduces the risk of remediation failures, tightens security, and improves platform reliability.

Glossary

- ARM, Azure Resource Manager; the control plane for Azure resources.

- DINE, DeployIfNotExists effect in Azure Policy.

- MI, Managed Identity, a service principal created and managed by Azure.

- RBAC, Role Based Access Control, the authorisation system used by Azure.

- UAI, User Assigned Identity, a Managed Identity created as a separate resource.