Edit

Noise reduction in deployment stack what-if results

The what-if operation compares your Bicep file or Azure Resource Manager template (ARM template) against the current state of your resources and reports every difference it finds. Some of those differences aren't changes that deploying your file would actually make. Resource providers add and normalize values after a resource is deployed, so a property can differ from your file even though nothing meaningful changed. These differences are called noise.

Deployment stacks filter noise out of what-if results automatically. This article explains where noise comes from, how the filtering works, what it removes, and what it doesn't remove.

For the commands that run what-if against a stack, see Preview deployment stack changes by using what-if.

Why noise appears

When you deploy a resource, the resource provider might store and return different properties than the ones you supply:

  • It applies defaults for properties you omit. For example, a Cosmos DB account gets a properties.minimalTlsVersion value even when your file doesn't set one.
  • It computes read-only properties. For example, properties.sqlEndpoint on a Cosmos DB account is generated by the service and can't be set in a template.
  • It derives properties from other properties. For example, sku.tier on an Event Hubs namespace is derived from sku.name.
  • It records runtime state. For example, properties.runningStatus on a container app reflects what the app is doing, not how it's configured.
  • It doesn't return write-only properties. It accepts a write-only value, such as a secret, when you deploy, but doesn't return that value when what-if reads the resource. What-if reports the difference as noise only when it doesn't know that the property is write-only.

In each case, the resource as what-if reads it genuinely differs from your file, so the comparison is accurate. The prediction is what's misleading, because applying the file doesn't change those properties.

The following table shows properties that are commonly reported as changed for this reason:

Resource type Property reported as changed Why it appears
Cosmos DB account properties.sqlEndpoint Generated by the service, read-only
Cosmos DB account properties.minimalTlsVersion Provider default applied after deployment
Event Hubs namespace sku.tier Derived from sku.name by the provider
Container app properties.runningStatus Runtime state rather than configuration
Role assignment properties.principalType Resolved by the provider at creation
Stream Analytics job properties.runtimeMode Provider default applied after deployment

Noise makes a result harder to trust. You have to read and dismiss lines you didn't cause before you reach the ones you did, and that work grows as a stack manages more resources.

How deployment stacks filter noise

A deployment stack has information that a standalone deployment doesn't: a record of what its managed resources looked like the last time the stack deployed successfully.

When you create or update a stack, Azure evaluates what-if for that stack at that moment and stores the result as a baseline. Because the evaluation runs immediately after a successful deployment, the differences it captures are ones the deployment didn't intend to make. The baseline is a record of the noise for that specific stack.

When you run what-if against the stack later, Azure compares the new evaluation against the baseline. Any property that's identical in both is removed from the result, because a difference that was already present before you edited your file isn't a difference your edit introduced. What remains is closer to the set of changes your Bicep file or ARM template actually makes.

Noise reduction is enabled in all regions. There's no flag to set and no preview to opt into.

Establish the baseline

Azure records the baseline when you create or update a stack, so noise reduction applies to stacks that you created or updated on or after August 13, 2026. A stack that you haven't deployed or updated since then doesn't have a baseline yet, and its what-if results still include noise.

To establish the baseline, create or update the stack once. Subsequent what-if runs are filtered against it.

Tip

If you're evaluating noise reduction and the results look noisier than you expect, check when the stack was last deployed or updated. A missing baseline is the most common explanation.

What noise reduction doesn't remove

Noise reduction removes differences that were already present in the baseline. It still reports differences that appear after the baseline was recorded. This behavior is intended, because a change made outside your Bicep file or ARM template is a change worth knowing about.

The following differences are reported even though you didn't make them:

  • A resource provider changes a default in a newer API version. A property that matched at baseline time now differs.
  • Something outside your file modifies a managed resource. A new policy assignment, or a manual edit in the Azure portal, changes a managed resource after the baseline was recorded.

Reordering a list of values is also reported. Reordering the security rules in a network security group is reported as no change, but reordering a list of values such as ["80","443","8080"] to ["8080","80","443"] is reported as an addition and a deletion. The baseline doesn't suppress this difference, because the reorder is new relative to the baseline rather than pre-existing.

Note

A what-if run against an unmodified file isn't guaranteed to report no changes. Review the reported changes rather than assuming that every remaining difference is a real change.

Evaluate noise reduction on your own stack

Run what-if against a stack you already have, using a Bicep file or ARM template that you didn't edit, and compare the result to what what-if for deployments reports for the same file.

az stack-whatif group create \
  --name "<what-if-result-name>" \
  --resource-group "<resource-group-name>" \
  --stack-id "<deployment-stack-resource-id>" \
  --template-file "<bicep-file-name>" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

The actionOnUnmanage and deny settings values affect the result, because they change how the stack manages your resources. For example, if you remove a resource from your file and set actionOnUnmanage to delete resources, what-if reports that resource as deleted rather than detached. Running what-if doesn't change any deployed resources. It creates only the what-if result resource that stores the output.

To run what-if against a stack, you need permission to read the stack and the resources it manages, and permission to create the what-if result, which is the Microsoft.Resources/deploymentStacksWhatIfResults/write action. If the what-if request uses deny settings, you also need the Microsoft.Resources/deploymentStacks/manageDenySetting/action action.

Report a property that should be filtered

If what-if reports a property that you didn't change, open an issue in the Azure/deployment-stacks repository. Include the following information:

  • The resource type.
  • The full property path as it appears in the output, such as properties.minimalTlsVersion.
  • The correlation ID, which is stored on the what-if result as properties.correlationId.
  • Whether you recently created or updated the stack, so you can rule out a missing baseline.

Related content

  • Last updated on