Azure Infrastructure as Code (IaC) deployments consistently demand clarity—knowing exactly what changes are about to be applied before you press "go" is essential. Yet, when using traditional Azure Resource Manager (ARM) What-If previews, many practitioners are plagued with noise—a flood of irrelevant changes that make it difficult to distinguish meaningful modifications from provider quirks or state inconsistencies.

This noise comes primarily from the sprawling ecosystem of Azure Resource Providers (RPs), each implemented by independent teams and often lacking complete alignment on how to minimize spurious changes in their What-If outputs. The result? Confusing deployment previews that deter confident infrastructure management—unless you have deep domain expertise to separate noise from signal.

Enter Deployment Stacks, with a brand-new What-If engine designed specifically to solve this problem. Deployment Stacks fundamentally transform the What-If experience by drastically reducing noise in change detection, retaining What-If results as tangible Azure resources for easy post-deployment review, and improving detection of subtle changes like encryption key rotations or resource deletions.

In this post, we’ll explore how Deployment Stacks refine the What-If process, demonstrate their capabilities using a real Bicep example, and share practical insights on leveraging this new tooling to streamline your Azure deployments.

Architecture Overview

┌────────────────────────────────────────────┐
│Architecture                                │
├────────────────────────────────────────────┤
│• Enterprise data sources                   │
│• Foundry platform                          │
│• AI applications                           │
└────────────────────────────────────────────┘

Key Technical Observations

• New Dedicated What-If Engine for Deployment Stacks
  Unlike the legacy What-If experience tied to regular deployments, Deployment Stacks use a completely new engine optimized for noise reduction and resource-based result retention.

• What-If Results Persisted as Azure Resources
  Deployment stack previews generate resources in Azure that hold the What-If results with a configurable retention interval (defaulting typically to 3 hours). This persistent snapshot enables post-deployment auditing and easier historical review.

• Significant Noise Suppression Across Providers
  With Deployment Stacks, noise—which previously stemmed from inconsistent Resource Provider implementations—is reduced by approximately 99%, shifting noisy edge cases into scenarios solvable by template adjustments.

• Improved Detection of Encryption Changes and Resource Deletions
  The new engine effectively identifies changes such as switching Key Vault encryption keys and flagged resource deletions, which were often obscured or noisy in classic What-If outputs.

• New PowerShell Cmdlets Prefixed with New-Az
  Retrieving and managing What-If results resources is streamlined using the new New-Az... cmdlets, promoting integration into deployment automation and audit workflows.

• Flexible Stack Resource ID Requirement
  What-If commands now require a Stack resource ID, but users can reference a non-existent stack ID to preview potential changes without creating the stack upfront, enhancing developer flexibility.

How It Works: Deployment Stacks What-If in Action

Creating and Using Deployment Stacks

First, you create a deployment stack scoped to a resource group:

Creating a deployment stack resource in Azure

This stack acts as the anchor point for subsequent What-If operations and persists What-If preview results as Azure resources scoped to it.

Writing the Bicep Template and Parameters

The example uses a concise Bicep template option2.bicep from the author's public library, focused on Azure resource encryption scenarios. The parameters file looks like this:

using 'option2.bicep'

param entraUserDisplayName = 'Stanislav Zhelyazkov'
param entraUserPrincipalId = '{redacted}'
param keyVaultSubscriptionId = '{redacted}'
param keyVaultKeyName = 'key0033'
param keyVaultName = '{redacted}'
param keyVaultResourceGroup = '{redacted}s'
param sqlServerName = 'sql000233aass'
param userAssignedIdentityName = '{redacted}'
param userAssignedIdentityResourceGroup = '{redacted}'
param userAssignedIdentitySubscriptionId = '{redacted}'

This structured parameterization is essential for reproducible and clear deployments.

Comparing Regular vs Deployment Stacks What-If Results

Running a classic What-If against this template produces a noisy output, cluttered by spurious changes from resource provider quirks:

Noisy regular What-If output with encryption changes masked by noise

Switching to Deployment Stacks What-If, the output cleans up dramatically, showing no changes since the deployment state matches the template:

Clean What-If results with no noise for unchanged deployment stack

Detecting Encryption Key Changes

Changing the Key Vault key name triggers the engine to explicitly detect this subtle encryption change:

What-If accurately reporting encryption key rotation as a precise resource change

Detecting Resource Deletions

Deleting a resource from the Bicep template also surfaces correctly in the What-If results, including removal indication:

Clear detection of resource deletions in deployment stack What-If preview

Using What-If Without an Existing Stack

You can also preview changes without creating a stack by simply specifying a non-existent Stack resource ID. The system still produces valid What-If results scoped to that ID:

Running What-If by referencing a stack resource ID for a non-existent stack

Quick Tips & Tricks

1. Transition from Classic to Deployment Stacks What-If
   Make Deployment Stacks your default method for Azure deployments to harness noise reduction and improved change clarity.

2. Set Appropriate Retention Intervals
   Use the PT3H (3 hours) or shorter retention interval for What-If result resources to benefit from automatic cleanup and avoid manual deletions.

3. Leverage Persistent What-If Result Resources
   Use the persisted What-If resources for auditing deployment drift or for post-deployment impact analysis within the retention window.

4. Detect Changes Via Automated Pipelines
   Integrate the new New-Az... cmdlets into CI/CD pipelines to automate noise-free preview gating before production deployments.

5. Adjust Bicep Code to Address Remaining Edge Noise
   Although rare, tweak Bicep templates in edge cases flagged by the new engine to further improve preview accuracy.

6. Experiment with Stack Resource ID Parameters
   Try running What-If commands referencing non-existent stacks to preview deployment impacts without resource creation.

Conclusion

Azure Deployment Stacks revolutionize the deployment What-If experience by dramatically reducing noise, preserving What-If results as Azure resources, and enhancing change detection—especially for complex scenarios like encryption updates and deletions. This clarity empowers DevOps teams to act with confidence, reduces deployment surprises, and streamlines auditing.

The new dedicated What-If engine unlocks a higher fidelity preview experience previously impossible at scale due to discrepancies across hundreds of Resource Providers. Coupled with new PowerShell tooling and flexible stack ID usage, deployment stacks offer a compelling path forward for modern Azure IaC practices.

As Azure evolves, expect deployment stacks and their What-If capabilities to become the new standard, making deployment previews more reliable and actionable for practitioners of all skill levels.

References

1. Noise Reduction with What-If Results for Deployment Stacks | Cloud Administrator in Azure World — Original article detailing deployment stacks improvements
2. What-If for Deployment Stacks | Microsoft Learn — Official Microsoft documentation for the feature
3. Azure Resource Providers and Types | Microsoft Learn — Understanding resource providers involved in What-If noise
4. azure-resource-encryption-examples - option2.bicep | GitHub — Source example template leveraged in the article
5. Deployment Stacks repo at GitHub — Report issues or contribute ideas around this evolving capability

---