What is the DeployIfNotExists effect in Azure Policy?

DeployIfNotExists checks whether a related resource exists and, if it does not, deploys one to make the resource compliant. For diagnostics, it checks for a diagnostic setting on the resource and deploys one that sends logs and metrics to a destination if none is present. Because it deploys resources, the policy assignment needs a managed identity with a role that can create the diagnostic setting, and it applies to existing resources through a remediation task.

Why do diagnostic settings need to be enforced with policy?

Diagnostic settings are per-resource and easy to forget. A resource created without one logs nothing, and you usually discover the gap during an incident when the data you need was never collected. Manually configuring diagnostics on every resource does not scale and drifts as new resources appear. A DeployIfNotExists policy guarantees coverage automatically, so logging is a property of the estate rather than a task someone has to remember for each resource.

How do I apply diagnostic policies to existing resources?

DeployIfNotExists only evaluates and deploys on resource creation or update by default, so existing resources become compliant through a remediation task. The remediation task uses the policy assignment's managed identity to deploy the missing diagnostic setting on each existing non-compliant resource. Group the many per-resource-type diagnostic policies into an initiative and remediate the initiative so you do not run dozens of separate remediations.

Field notes · Governance

Enforce diagnostic settings

Guaranteeing diagnostics on every resource with Azure Policy

Q: How do I enforce diagnostic settings on Azure resources?

Use Azure Policy definitions with the DeployIfNotExists effect. For each resource type you care about, there is a built-in 'Deploy diagnostic settings ... to Log Analytics workspace' policy that checks whether the resource has a diagnostic setting and, if not, deploys one that routes its logs and metrics to your workspace. Assign these at a management group or subscription scope and run a remediation task to cover resources that already exist.

By Captain O7 min read

A resource with no diagnostic setting logs nothing — and you find out at the worst possible time, mid-incident, when the data you need was never collected. Policy makes "it was logging" true by default.

New to cloud? CAMPUX is a free, build-first course. Start here →

Guarantee logging by assigning DeployIfNotExists Azure Policies: for each resource type, a built-in "Deploy diagnostic settings to Log Analytics" policy checks whether the resource has a diagnostic setting and, if not, deploys one that routes its logs and metrics to your workspace. DeployIfNotExists needs a managed identity on the assignment, and a remediation task covers resources that already exist. Bundle the per-type policies into an initiative and assign it once. Coverage becomes automatic instead of a checklist item everyone forgets.

Diagnostic settings are per-resource, and per-resource means per-forgettable. Someone spins up a new storage account or key vault, never adds a diagnostic setting, and it silently logs nothing — until an incident, when the one thing you need is the data that was never captured. Manually configuring diagnostics doesn't scale and drifts the moment new resources appear. This is exactly the drift Azure Policy exists to kill.

Why DeployIfNotExists, not Audit or Deny

You could audit resources missing a diagnostic setting, but that just produces a to-do list. You can't deny a resource for lacking one, because the diagnostic setting is a separate child resource created after the parent. The right effect is DeployIfNotExists: it checks for the diagnostic setting and, when it's missing, deploys one for you. It's the effect designed for "make this compliant automatically" rather than "block it" or "flag it."

How the pieces fit

Per-resource-type policies — Azure ships "Deploy diagnostic settings for <resource type> to Log Analytics workspace" built-ins. You typically assign many (storage, Key Vault, network security groups, SQL, and so on).
An initiative — bundle those into one policy set (there are built-in diagnostic initiatives) and assign the initiative instead of dozens of policies.
A managed identity — because DeployIfNotExists deploys resources, the assignment needs a managed identity with a role that can create diagnostic settings (typically Contributor + Log Analytics Contributor at the scope). The portal offers to create and grant it at assignment time.
A target workspace — the Log Analytics workspace the logs route to (usually your central one).

Assign and remediate

Assign the initiative at a management group or subscription, supply the workspace parameter, and let the portal create the managed identity and grant its roles. New resources get a diagnostic setting automatically. For everything that already exists, run a remediation task:

# remediate existing resources for one policy in the initiative
az policy remediation create \
  --name "diag-backfill" \
  --policy-assignment "deploy-diagnostics" \
  --definition-reference-id "<ref-id-from-initiative>"

Mind the identity and the delay

Two things trip people up: the assignment's managed identity must actually have its roles before remediation will work (grant them, or let the portal do it), and policy evaluation isn't instant — a compliance scan can take up to ~30 minutes, so newly created resources won't show a diagnostic setting the same second. This is the same DeployIfNotExists pattern covered in writing a custom policy definition.

The payoff pairs with the read side: once diagnostics are guaranteed everywhere, the sign-in and activity logs you export actually cover the whole estate — no blind spots where a resource quietly wasn't logging.

Logging you have to remember per resource is logging you'll be missing during the incident. Make it a property of the platform.

Questions people also ask

How do I enforce diagnostic settings on Azure resources?

Assign DeployIfNotExists policies — the built-in "Deploy diagnostic settings … to Log Analytics" for each resource type — which deploy a diagnostic setting when one is missing. Assign at a management group or subscription and run a remediation task for existing resources.

What is DeployIfNotExists?

A policy effect that checks for a related resource and deploys one if it's absent — here, a diagnostic setting routing logs and metrics to a destination. Because it deploys, the assignment needs a managed identity, and it applies to existing resources via remediation.

Why enforce diagnostics with policy?

Diagnostic settings are per-resource and easy to forget; a resource without one logs nothing, discovered during an incident. Manual configuration doesn't scale and drifts. DeployIfNotExists guarantees coverage automatically, making logging a property of the estate.

How do I apply it to existing resources?

DeployIfNotExists acts on create/update by default, so existing resources become compliant through a remediation task using the assignment's managed identity. Group per-type diagnostic policies into an initiative and remediate the initiative rather than each policy.