Management and Governance ARM deployments verified field-manual operator-field-manual

What-if operation

A what-if operation is the actual Azure Resource Manager preview call behind a what-if deployment. Think of it as asking Azure, given this template, parameters, and scope, what would you change? The result is a structured set of predicted resource changes. It is more precise than reading a template manually because it uses the deployment engine understanding of conditions, references, dependencies, and current state. Operators use the operation output to decide whether a deployment should continue, be revised, or be escalated for deeper review.

Back to glossary browser Open Microsoft Learn source
Aliases
ARM what-if operation, deployment what-if operation, what-if preview operation
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-29

Microsoft Learn

A what-if operation is the Azure Resource Manager evaluation request that powers deployment previews. It analyzes a template at resource group, subscription, management group, or tenant scope and returns predicted change types and property differences before resources are created, updated, or deleted.

Microsoft Learn: ARM template deployment what-if operation2026-05-29

Technical context

Technically, a what-if operation runs through Microsoft.Resources deployments APIs and CLI commands such as az deployment group what-if, sub what-if, mg what-if, and tenant what-if. It evaluates template expressions, parameters, copy loops, conditional resources, and existing deployed resources at the chosen scope. The response includes resource identifiers, change types, and before-and-after property information where available. It is a control-plane operation, not a data-plane simulation. It requires deployment permissions similar to a real deployment, and providers may still return noise or unknown values for properties resolved only during execution.

Why it matters

The what-if operation matters because its output is the reviewable object, not just the idea of previewing a deployment. A pipeline can parse it, a reviewer can approve it, and an operator can archive it with the release. The operation helps teams distinguish harmless updates from risky changes such as delete, replace, network exposure, SKU shifts, or identity changes. It also exposes the exact deployment scope, which prevents teams from accidentally reviewing a resource-group change while deploying at subscription scope. Used well, it turns infrastructure review into evidence-based decision-making instead of template guesswork for production systems under pressure and audit review.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In az deployment group what-if output, operators see resource IDs, change types, before-and-after properties, and the deployment scope used for the preview review and approval.

Signal 02

In Azure DevOps or GitHub Actions logs, the operation appears as a gate before create commands, often failing when delete or replace changes are detected.

Signal 03

In deployment history discussions, engineers refer to saved what-if artifacts to explain why a template change was approved, rejected, or rerun before execution during release review.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Parse what-if operation output in CI to fail builds that contain delete or replace change types.
  • Compare resource-group and subscription-scope previews when a module changes the deployment boundary.
  • Generate reviewer-friendly JSON evidence for emergency hotfixes before running the actual deployment.
  • Detect unknown or noisy provider properties that need manual review before an automation rule is trusted.
  • Validate that a parameter override changes one intended property rather than a whole resource family.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Aerospace supplier creates a delete-stop gate

An aerospace parts supplier had strict controls around production subscriptions because engineering files and supplier portals shared the sa

Scenario

An aerospace parts supplier had strict controls around production subscriptions because engineering files and supplier portals shared the same landing-zone modules. Manual review missed risky resource deletes twice in one year.

Business/Technical Objectives
  • Stop any unapproved delete or replace change before deployment.
  • Use the same deployment identity for preview and execution.
  • Store machine-readable evidence for export-control audits.
  • Reduce reliance on senior engineers reading every Bicep line.
Solution Using What-if operation

The platform team built a pipeline step around the Azure Resource Manager what-if operation. The step ran az deployment sub what-if with the production parameter file, saved the full JSON output, and parsed change types before any create command was available. Deletes, replaces, public network changes, and Key Vault access changes failed automatically unless a named approver added an exception. The operation used the same service principal as the final deployment so RBAC gaps appeared early. A review dashboard summarized high-risk resource IDs while preserving raw artifacts for audits and incident reconstruction.

Results & Business Impact
  • Two unintended deletes were blocked in the first month after the gate launched.
  • Senior-engineer review time for routine releases dropped from three hours to forty minutes.
  • Audit requests were answered with stored JSON artifacts instead of manually reconstructed notes.
  • Deployment failures from permission drift fell by 31 percent because preview used the final identity.
Key Takeaway for Glossary Readers

The what-if operation becomes a real control when its structured output is parsed, stored, and tied to deployment approval.

Case study 02

Lending platform reviews hotfix scope under pressure

A digital lending platform needed an emergency network-rule hotfix after a partner IP range changed. The release was small, but the subscrip

Scenario

A digital lending platform needed an emergency network-rule hotfix after a partner IP range changed. The release was small, but the subscription also contained production databases and private endpoints.

Business/Technical Objectives
  • Prove the hotfix changed only the intended firewall rules.
  • Avoid opening public access while restoring partner traffic.
  • Give incident leadership readable evidence within the response bridge.
  • Deploy quickly without bypassing normal infrastructure controls.
Solution Using What-if operation

The on-call engineer ran a what-if operation at resource group scope using Azure CLI and the exact hotfix parameter file. The output was saved as JSON and summarized into three reviewed changes: one firewall rule update, one tag update, and no deletes. A custom script highlighted publicNetworkAccess, privateEndpointConnections, and roleAssignments fields because those had caused previous incidents. When the first preview showed an unexpected network rule on a staging database, the team found that a shared variable file was still referenced. After correcting it, the operation output matched the incident objective and the deployment proceeded.

Results & Business Impact
  • Partner loan submissions recovered twenty-eight minutes after the corrected preview was approved.
  • No production database exposure settings changed during the emergency release.
  • The bridge avoided a full change-board delay because operation output showed a narrow blast radius.
  • The stale variable file was removed from four pipeline templates the same day.
Key Takeaway for Glossary Readers

During incidents, a what-if operation can keep speed and discipline together by proving the proposed fix is narrowly scoped.

Case study 03

Museum archive avoids storage replacement

A museum digitization team managed petabytes of scanned collection images with ARM templates maintained by a small central IT group. A stora

Scenario

A museum digitization team managed petabytes of scanned collection images with ARM templates maintained by a small central IT group. A storage-account naming change looked cosmetic in review.

Business/Technical Objectives
  • Detect replacement behavior before archive storage was touched.
  • Preserve immutable blob policies and private endpoint configuration.
  • Keep curators informed without exposing raw infrastructure complexity.
  • Build confidence in template modernization work.
Solution Using What-if operation

Before deploying the modernization template, IT ran the Azure Resource Manager what-if operation with FullResourcePayloads output. The preview showed a storage account would be deleted and recreated because a generated name changed with a new abbreviation convention. It also showed that diagnostic settings and private endpoint connections would disappear with the replacement. The team stopped the release, kept the existing storage account as an existing resource in Bicep, and moved naming cleanup to new resources only. A simplified summary of the operation output was shared with curators to explain why the release paused.

Results & Business Impact
  • A storage replacement that could have broken archive access for days was prevented.
  • Immutable retention and private endpoint settings remained intact after the corrected deployment.
  • Curator confidence improved because the pause was explained with concrete planned changes.
  • Future naming convention changes added an automatic what-if replacement review.
Key Takeaway for Glossary Readers

The what-if operation is often where a harmless naming cleanup reveals a destructive replacement path.

Why use Azure CLI for this?

I use Azure CLI for the what-if operation because it maps cleanly to the four deployment scopes and produces output that automation can inspect. With ten years of Azure deployment work, I care about exact scope more than a pretty screen. CLI lets me run the same operation against resource group, subscription, management group, or tenant deployments, choose result format, and fail a pipeline when the change set includes unapproved deletes. It is also easy to rerun with a different parameter file during incident recovery. The command history becomes a practical audit trail for the decision to deploy or stop.

CLI use cases

  • Execute a what-if operation at resource group scope for an application module release.
  • Execute a subscription-scope operation before governance or shared networking changes.
  • Save operation output as JSON for automated parsing and approval evidence.
  • Rerun the operation with corrected parameters to prove a risky change disappeared.
  • Use operation output to stop a deployment when delete or replace changes are not approved.

Before you run CLI

  • Confirm tenant, subscription, scope, location, template file, parameter file, and deployment identity.
  • Check that the CLI command uses what-if, not create, before allowing a pipeline gate to run.
  • Understand whether the template includes modules, conditional resources, loops, or complete-mode behavior.
  • Protect output artifacts because they can expose resource names, IDs, topology, and security-sensitive intent.
  • Choose an output format that humans can review while preserving raw JSON for machines.

What output tells you

  • The response lists resource-level changes and shows whether each resource is predicted to change.
  • Change types identify creates, deletes, modifications, unsupported resources, ignored resources, or unchanged resources.
  • Property diffs show values Azure can compare before deployment and where provider values remain unknown.
  • Scope and resource IDs show whether the operation evaluated the intended management boundary.
  • Unexpected noise can indicate provider defaults, drift, computed properties, or a template expression that needs review.

Mapped Azure CLI commands

What-if operation and deployment operation commands

direct
az deployment group what-if --resource-group <resource-group> --template-file main.bicep --parameters @parameters.json --result-format FullResourcePayloads
az deployment groupdiscoverManagement and Governance
read-only Microsoft docs
az deployment sub what-if --location <region> --template-file main.bicep --parameters @parameters.json
az deployment subdiscoverManagement and Governance
read-only Microsoft docs
az deployment mg what-if --management-group-id <management-group-id> --location <region> --template-file main.bicep
az deployment mgdiscoverManagement and Governance
read-only Microsoft docs
az deployment tenant what-if --location <region> --template-file main.bicep
az deployment tenantdiscoverManagement and Governance
read-only Microsoft docs
az deployment operation group list --resource-group <resource-group> --name <deployment-name> --output table
az deployment operation groupdiscoverManagement and Governance
read-only Microsoft docs

Architecture context

Architecturally, the what-if operation is a control-plane decision point in the deployment workflow. It sits after template build and validation, and before create or update execution. In a serious platform pipeline, it should run with the same deployment identity, scope, and parameter files used for the actual release. The output can be inspected by policy-as-code gates, human approvers, or custom scripts that flag deletes and sensitive properties. Because the operation evaluates current Azure state, it also exposes drift that code review alone cannot see. It belongs beside Bicep build, template specs, deployment stacks, and Azure Policy checks for safe releases.

Security

Security impact is indirect but significant because the what-if operation can reveal unsafe infrastructure changes before they are applied. Review output for public IP creation, firewall rule expansion, managed identity replacement, role assignment changes, Key Vault access policy shifts, private endpoint removal, or diagnostic setting deletion. The operation itself should be run by trusted identities because it exposes subscription structure and planned resource IDs. Store outputs in protected pipeline artifacts, not public logs. Permissions should match deployment least privilege, and secret parameters should be passed securely so preview runs do not leak sensitive values or references during regulated release review.

Cost

Cost impact is indirect because the operation is a preview, not a spend calculator. Its value is showing planned resources that could change cost: new gateways, plan upgrades, database SKU changes, extra replicas, diagnostic retention, private endpoints, or deleted reservation-support resources. It can also catch accidental duplication when a name or scope parameter points to the wrong environment. FinOps teams should not rely on what-if alone for forecasts, but it is a strong early warning. Tagging, budgets, pricing calculators, and cost analysis should follow when the operation shows spend-affecting infrastructure changes before spend ownership becomes disputed or finance review closes.

Reliability

Reliability value comes from seeing disruption risk before the deployment engine acts. The operation can show replace or delete behavior, capacity changes, zone-setting differences, route-table modifications, or removal of monitoring resources. Those signals let teams add maintenance windows, backups, slot swaps, or rollback steps before approval. It is not a chaos test and cannot prove that an application will survive the change, so post-deployment validation remains required. Watch for noisy or unknown values, but do not dismiss the whole result as noise. A single unexpected delete in the operation output deserves investigation before anyone proceeds with approval or execution in production.

Performance

Runtime performance is not directly affected by running the operation. The operational performance gain is speed and certainty during deployment review. Instead of manually reading a large Bicep module graph, engineers get a computed list of planned deltas. That helps them spot changes to scale units, cache tiers, load-balancer rules, database compute, or storage settings that could affect application performance. Very large templates can produce long outputs, so teams should summarize high-risk fields while retaining raw artifacts. The operation also saves pipeline time by stopping bad releases for large platform changes before create or update work begins during review cycles.

Operations

Operators use the what-if operation as a repeatable gate. They run it with the intended template and parameter set, check the scope, review change types, and store the result with the deployment record. During incidents, they can run it quickly to verify whether a proposed hotfix only touches the intended resource. During audits, saved output explains why a deployment was considered safe. Operational runbooks should define which change types require escalation, how to handle false positives, and who can override the gate. Output formatting matters during high-pressure production changes and incident recovery bridges because unreadable JSON causes teams to skip the review.

Common mistakes

  • Reviewing the operation output casually instead of defining which change types block deployment.
  • Assuming unknown property values are harmless without checking the resource provider behavior.
  • Saving only a screenshot of the operation instead of the raw output used by automation.
  • Running the operation under a different identity from the final deployment identity.
  • Forgetting that a successful operation preview still needs post-deployment health and compliance checks.