A closer look at noise reduction in Stacks What-If

Following the general availability of what-if for Azure Deployment Stacks, this article deep dives into the co-released feature of "noise reduction", which was a top community feature ask from Deployment Stacks customers. In this article, we will cover what noise reduction solves, how it works, and how to get started with noise reduction. For the full reference, see Noise reduction in deployment stack what-if results on Microsoft Learn.

The problem with Deployments What-if results

What-if for deployments compares a Bicep file or ARM template against the current state of the deployed resources and reports every difference between the two. Historically, a large share of those differences are changes that won't actually happen, and they're considered noise.

Noise is a difference that what-if reports but that deploying the template wouldn't actually change. It shows up when the property values declared in your template differ from the resource as it exists in Azure for reasons that have nothing to do with your edit. A resource provider fills in default values for properties you left out. It also returns read only properties that no template can declare, which surface as false deletions because nothing in your file matches them. Write only properties can add noise too, but only when what-if doesn't know that a property is write only, because the value you deploy is never returned to compare against.

This has been one of the most common pieces of feedback we receive about what-if. Noise makes a result harder to trust, and a result that is not trusted is slower to act on. Review turns into a manual exercise, because someone has to read every line and dismiss the ones that nobody authored. As a stack grows to manage more resources, the problem compounds.

What noise reduction looks like

Here is what a regular deployment what-if response looks like:

In this example, the property values of properties.sqlEndpoint and properties.minimalTlsVersion on the Cosmos DB account, sku.tier and properties.kafkaEnabled on the Event Hubs namespace, and the five properties.siteConfig values on the web app show up as changes but are actually noise (given they were not a part of the original template).

Now, with Deployment Stacks What-if, the response is more accurate and the noise is removed, as shown in the following example.

Where the noise comes from

Noise most commonly comes from default properties for resource types, but it can also come from read only properties, and from write only properties that what-if doesn't recognize as write only. Below are common examples of such noise:

The same pattern holds as the resource types vary. On a separate stack managing 13 resources spanning storage, networking, Event Hubs, Container Registry, App Service, Log Analytics, and Application Insights, what-if for deployments returned 30 property level differences on an unedited template.

Stacks What-if against the same stack returned none.

How Deployment Stacks filter noise

A Deployment Stack keeps a record that a standalone deployment does not. It captures the noise that was already present after the last successful deployment of that stack.

After each successful stack deployment or update, Azure runs what-if and saves the result as a baseline. That baseline captures the differences that come from Azure itself, such as provider defaults, rather than from any later edit you make to the template.

The next time you run Stacks What-if, Azure compares the new result against that baseline. If a property looks the same in both, Azure drops it from the output, because the edit you are previewing is not what introduced that difference.

Noise reduction is enabled in all regions and there is no flag to set. It depends on a baseline, so it applies to stacks that were deployed or updated on or after August 13, 2026. If a stack hasn't been deployed since then, deploy or update it once to record a baseline. The next Stacks What-if run uses that baseline. If a result looks noisier than you expect, check when the stack was last deployed, because a missing baseline is the most common cause.

What noise reduction does not hide

Filtering against a baseline removes differences that were already present when the baseline was recorded, not differences that appear afterwards. In a test stack, an Azure Policy assignment added a myTag tag to every managed resource at deployment time. What-if for deployments reported tags.myTag as a deletion on all four resources, because nothing in the template declared it. Stacks What-if reported those same four resources as NoChange, because the tag was already in the baseline. Adding a different tag directly to one of those resources after the stack had deployed produced the opposite outcome. That tag was not in the baseline, so Stacks What-if reported it. Drift introduced after a deployment still surfaces.

Getting started

The quickest way to evaluate this is against a stack you already have. Run Stacks What-if with the unchanged template and compare the result to what what-if for deployments reports for the same file. Unlike a deployment what-if, a Stacks What-If Result is itself an Azure resource, so the name you give it, noise-check in the examples below, becomes the resource name you use to retrieve that result later:

Azure PowerShell:

New-AzResourceGroupDeploymentStackWhatIfResult `
  -Name "noise-check" `
  -ResourceGroupName "my-rg" `
  -StackResourceId "<stack-resource-id>" `
  -TemplateFile "main.bicep" `
  -ActionOnUnmanage DetachAll `
  -DenySettingsMode None `
  -RetentionInterval "PT3H"

Azure CLI:

az stack-whatif group create \
  --name "noise-check" \
  --resource-group "my-rg" \
  --stack-id "<stack-resource-id>" \
  --template-file "main.bicep" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Keep in mind that --action-on-unmanage and --deny-settings-mode affect the Stacks What-if result, because they change how the stack would manage your resources. The clearest way to see this is to remove a resource from your template and run the same evaluation twice. With detachAll, that resource is reported as v Detach and its management status moves from managed to notManaged, but it stays in Azure. With deleteResources, the same resource is reported as - Delete and is listed again under Resources Marked for Deletion. The template change is identical in both runs, so the difference in the result comes entirely from actionOnUnmanage. Running Stacks What-if does not change any deployed resource. It does create one resource, the Stacks What-If Result itself, which is how the output is stored so you can retrieve it later. Stacks What-if is available at resource group, subscription, and management group scope, in Azure CLI, Azure PowerShell, and the Azure SDKs.

Azure PowerShell takes PascalCase enum values such as DetachAll and None, written without quotes. Azure CLI documents the camelCase spellings detachAll and none. Use the spelling each tool documents, and if a value is not recognized the error lists the allowed values.

The retention interval sets how long Azure keeps the result before cleaning it up. It currently accepts ISO 8601 durations between PT1H and PT3H, so the PT3H used in these examples is the longest window available today. If you intend to hand a result to a reviewer as an approval artifact, plan around that window, because the result is removed once it expires.

The result is printed in up to three sections. Changes to Stack covers the stack resource itself, such as deny settings, and appears when those change or when the stack does not exist yet. Changes to Managed Resources lists every managed resource with its change type and property level detail. Resources Marked for Deletion repeats, as an explicit list with a count, the resources the run predicts will be deleted, which is the section to read first when you are reviewing a risky update.

You need permission to read the deployment stack and the resources it manages, and permission to create the result. The operations involved are Microsoft.Resources/deploymentStacks/read, Microsoft.Resources/deploymentStacksWhatIfResults/write to create a result, Microsoft.Resources/deploymentStacksWhatIfResults/read to retrieve one, and Microsoft.Resources/deploymentStacksWhatIfResults/delete to remove one. Because the evaluation compares your template against live resource state, the identity running it also needs read access to the managed resources themselves.

Tell us what you think

If Stacks What-if reports a property you did not change, open an issue in Azure/deployment-stacks and include the resource type, the full property path as it appears in the output, and the correlation ID. Because the result is a stored resource rather than terminal output, the correlation ID is saved on it and can be read back at any time with az stack-whatif group show --name <result-name> --resource-group <resource-group> --query properties.correlationId, or from the CorrelationId property returned by Get-AzResourceGroupDeploymentStackWhatIfResult.

Resources

• Noise reduction in deployment stack what-if results. The Microsoft Learn article on noise reduction, covering where noise comes from, how the baseline works, and what it doesn't filter.
• Preview deployment stack changes with what-if. Change types, running Stacks What-if at each scope, retrieving and deleting Stacks What-If Resources, and noise reduction.
• Create and deploy Azure deployment stacks in Bicep. The main Deployment Stacks article, including actionOnUnmanage.
• Preview Bicep deployment changes by using what-if. What-if for deployments, included for comparison.
• az stack-whatif command reference. The Azure CLI command group for Stacks What-if at resource group, subscription, and management group scope.
• New-AzResourceGroupDeploymentStackWhatIfResult. The Azure PowerShell cmdlet reference, including the subscription and management group equivalents.
• Deployment stacks what-if results REST API. The Microsoft.Resources/deploymentStacksWhatIfResults reference, which is the contract the SDKs are generated from.