This chapter covers Azure Resource Manager (ARM) What-If analysis, a powerful validation tool that lets you preview the impact of an ARM template deployment before actually executing it. For the AZ-104 exam, understanding What-If is critical because it directly tests your ability to plan and validate infrastructure deployments safely. Approximately 5-10% of exam questions touch on deployment validation and ARM template testing, with What-If being a key feature. You will learn how What-If works internally, how to use it with Azure CLI, PowerShell, and the portal, and how to interpret its output to avoid costly deployment mistakes.
Jump to a section
Imagine you're a construction project manager planning a building renovation. Before you order materials or hire contractors, you want to know exactly what changes your blueprint will cause—which walls will be demolished, which rooms added, and whether the structural load changes. You hand your blueprint to a senior engineer who runs a simulation: they compare your new plan against the current building's as-built drawings. The engineer produces a detailed report listing every change: 'Wall W-12 will be removed, Room R-3 will be added, the foundation load will increase by 5%.' No actual work begins; no materials are ordered. You can review the report, spot a mistake (e.g., you accidentally removed a load-bearing wall), and revise the blueprint before any real cost or safety risk. This is exactly how Azure Resource Manager's What-If analysis works: it simulates your ARM template deployment against the current Azure resource state, outputs a list of resource-level changes (create, delete, modify, no change), and lets you validate the impact before executing the deployment. No resources are actually provisioned, no costs incurred, and you can catch errors early—just like catching a load-bearing wall removal on paper rather than during construction.
What is ARM What-If Analysis?
Azure Resource Manager (ARM) What-If analysis is a feature that allows you to see the predicted changes that an ARM template deployment would make to your Azure environment without actually executing the deployment. It was introduced to address the need for safe deployment validation, especially in production environments where unintended changes can cause downtime or security breaches. What-If analysis is available for ARM template deployments (including linked templates) and can be invoked via Azure CLI, Azure PowerShell, or the Azure portal.
Why What-If Exists
Before What-If, the only way to validate an ARM template was to either:
Deploy to a test environment (time-consuming and may not mirror production exactly)
Manually review the template (error-prone)
Use Azure Policy or linters like PSRule (useful but not predictive of actual resource behavior)
What-If fills the gap by providing a deterministic preview of what Azure Resource Manager will do when processing your template. It leverages the same deployment engine that executes actual deployments, so the predictions are highly accurate.
How What-If Works Internally
When you run a What-If operation, Azure Resource Manager performs the following steps:
Template Parsing and Validation: ARM receives your template and parameters. It validates the template structure (schema, resource types, API versions) and resolves parameter values, including default values and parameter file references.
Resource State Retrieval: ARM queries the current state of all resources that are referenced in the template scope (resource group or subscription). This includes existing resources that match the template resource names and types.
3. Change Calculation: ARM compares the desired state (from the template) with the current state (from Azure). For each resource, it determines the change type:
- Create: Resource exists in template but not in current state.
- Delete: Resource exists in current state but not in template (only when deployment mode is Complete).
- Modify: Resource exists in both, but properties differ. ARM computes the specific property changes.
- NoChange: Resource exists in both and properties match.
- Ignore: Resource exists in template but is marked with ignore condition or is a child resource that is implicitly created.
Result Serialization: The changes are serialized into a structured response that includes resource IDs, change types, and property-level diffs (for Modify). The response is returned to the caller.
Key Components and Values
- Change Types: The five change types listed above. The most common exam scenarios involve Create and Modify; Delete only occurs in Complete mode.
- Property Diffs: For Modify changes, What-If shows the before and after values for each changed property. For example, if you change the sku of a storage account from Standard_LRS to Standard_GRS, the diff will show both values.
- Result Format: What-If returns a list of ResourceChange objects, each containing:
- resourceId: Full ARM resource ID.
- changeType: One of the five types.
- before and after property snapshots (for Modify).
- Scope: What-If can be scoped to a resource group or subscription. Subscription-level deployments are used for policy, role assignments, and management groups.
- Parameters: What-If uses the same parameters as the actual deployment, including inline parameters, parameter files, and default values.
- Modes: What-If respects the deployment mode (Incremental or Complete). In Incremental mode, resources not in the template are left unchanged; in Complete mode, they are deleted.
- Error Handling: If the template contains errors (e.g., invalid resource type), What-If will report the error and not proceed. It does not execute any resource creation.
Configuration and Verification Commands
Azure CLI:
az deployment group what-if \
--resource-group myResourceGroup \
--template-file azuredeploy.json \
--parameters @azuredeploy.parameters.json \
--result-format FullResourcePayloads--result-format: Controls the level of detail. FullResourcePayloads includes before/after property snapshots; ResourceIdOnly only lists resource IDs and change types.
Azure PowerShell:
New-AzResourceGroupDeployment -ResourceGroupName myResourceGroup `
-TemplateFile azuredeploy.json `
-TemplateParameterFile azuredeploy.parameters.json `
-WhatIfThe -WhatIf switch triggers What-If analysis. You can also use New-AzResourceGroupDeployment -WhatIfResult to capture the result object.
Azure Portal:
In the portal, when deploying a template via 'Deploy a custom template', you can click 'Edit parameters' and then 'Review + create'. There is a 'What-If' button in the review step that shows the changes.
Interaction with Related Technologies
Azure Policy: What-If does not evaluate Azure Policy during simulation. However, if a policy would deny the deployment, the actual deployment would fail even if What-If shows success. Always validate policies separately.
Resource Locks: What-If does not check resource locks. A delete operation predicted by What-If might fail if a lock is present.
Tags: What-If includes tag changes in property diffs. If you modify tags, they will appear as Modify changes.
Child Resources: What-If handles child resources (e.g., subnets, databases) as part of the parent resource. Changes to child resources are shown as part of the parent's Modify change.
Linked Templates: What-If can evaluate linked templates if you provide the full template URL. The nested templates are processed recursively.
Limitations
What-If does not simulate the actual runtime behavior of resources (e.g., it won't tell you if a VM extension fails).
It does not check quota limits or subscription limits.
It may not detect all property changes if the resource provider does not expose certain properties.
For some resources (e.g., Azure Policy assignments), the before/after diffs may be incomplete.
Best Practices
Always run What-If before any production deployment, especially when modifying existing resources.
Use --result-format FullResourcePayloads to see property diffs; this helps catch unintended changes like accidental SKU downgrades.
Combine What-If with Azure Policy compliance checks and cost estimation tools for comprehensive validation.
In CI/CD pipelines, include a What-If step that requires manual approval before actual deployment.
Prepare the ARM Template
Create or obtain your ARM template (JSON or Bicep) and parameter file. Ensure the template is syntactically valid by using tools like `az bicep build` or the ARM template toolkit. The template should be scoped to a resource group or subscription. For the exam, you'll often be given a template that modifies existing resources—like changing a storage account SKU or adding a subnet. Verify that the resource API versions are correct and the template references existing resources with the correct names.
Run the What-If Command
Use Azure CLI or PowerShell to execute the What-If operation against the target resource group. For example: `az deployment group what-if --resource-group prod-rg --template-file deploy.json --parameters @params.json`. The command sends the template to the ARM endpoint, which validates the template structure and retrieves the current state of all resources in the resource group. The response is a list of predicted changes. The operation typically completes in a few seconds, depending on the number of resources.
Interpret the What-If Output
The output shows each resource and its change type: Create, Delete, Modify, NoChange, or Ignore. For Modify changes, the output includes before and after property values. For example, if you changed the storage account SKU from Standard_LRS to Standard_GRS, the output will show the old and new SKU. Pay attention to unexpected Delete changes—these occur only in Complete mode and can wipe out resources. Also, note that some properties may show as 'null' in before/after if they are not defined.
Validate Changes Against Requirements
Compare the predicted changes with your intended changes. Check that every resource you wanted to create is listed as Create, and every existing resource you wanted to modify is listed as Modify with the correct property diffs. Look for any unexpected NoChange on resources you intended to modify—this could indicate a parameter mismatch or a typo in the template. Also, watch for Ignore resources that you expected to be created; this might happen if the resource is conditionally deployed with a false condition.
Proceed with Actual Deployment
After reviewing the What-If output and confirming it matches expectations, run the actual deployment using the same template and parameters. The actual deployment will produce the same changes as predicted, barring any policy or lock failures. The exam emphasizes that What-If is a validation step, not a replacement for testing in a non-production environment. Always combine What-If with other validation techniques like Azure Policy compliance checks and cost estimation.
Scenario 1: Production Storage Account SKU Upgrade
A financial services company needs to upgrade their production storage account from Standard_LRS to Standard_GRS for geo-redundancy. The infrastructure team uses an ARM template that modifies the sku property. Before deploying, they run What-If analysis against the production resource group. The output shows a Modify change on the storage account with the SKU change, and no other changes. However, the team notices that the blob soft-delete property is not defined in the template, so it appears as a Modify change because the template doesn't set it—What-If interprets this as a change to 'null' (delete the property). This would disable soft-delete inadvertently. The team updates the template to explicitly include the soft-delete property. This catch saves them from potential data loss. In production, What-If is run in a CI/CD pipeline with manual approval gates. The team also uses --result-format FullResourcePayloads to capture the full diffs in logs.
Scenario 2: Complete Mode Deployment for a Clean Slate
A startup wants to redeploy their entire development environment using a Complete mode deployment to remove orphaned resources. They run What-If with --mode Complete. The output lists all existing resources as Delete, and the new template resources as Create. The team reviews the list and realizes that a shared database resource (used by another team) would be deleted. They quickly change the deployment mode to Incremental and isolate the shared resource into its own resource group. This scenario highlights the danger of Complete mode and how What-If prevents accidental deletion.
Scenario 3: Subscription-Level Policy Assignment
An enterprise needs to assign a new Azure Policy to the entire subscription. They create a subscription-level ARM template. Running What-If at subscription scope (az deployment sub what-if) shows the policy assignment as Create. The output also shows any existing policy assignments that would be modified if the template changes them. This allows the governance team to preview the impact before applying policies that could affect thousands of resources.
Common Pitfalls:
Forgetting to specify --mode Complete when you intended Incremental, leading to unexpected Delete predictions.
Not parameterizing resource names, causing What-If to predict a Create when you intended to Modify an existing resource (because the name differs).
Ignoring property diffs that show 'null'—this often means the template is missing a property that is currently set on the resource, and the deployment will reset it to default.
AZ-104 Objective Coverage
What-If analysis falls under objective 3.4: 'Validate and deploy ARM templates.' The exam expects you to:
Understand the purpose and benefits of What-If analysis.
Know how to run What-If using Azure CLI, PowerShell, and the portal.
Interpret the output: change types (Create, Delete, Modify, NoChange, Ignore) and property diffs.
Understand the difference between Incremental and Complete modes and how they affect What-If results.
Identify scenarios where What-If might not catch issues (policy, locks, quotas).
Common Wrong Answers and Traps
'What-If can detect Azure Policy violations.' This is false. What-If does not evaluate policies. A deployment that passes What-If may still be denied by a policy. The exam tests this distinction.
'What-If in Complete mode will never show Delete changes.' Wrong. Complete mode shows Delete for resources not in the template. Candidates often confuse Incremental and Complete.
'What-If shows cost estimates.' No. What-If only shows resource changes. Cost estimation is a separate feature (Azure Pricing Calculator or cost management).
'What-If modifies resources during simulation.' False. What-If is read-only and does not change any resources.
Specific Numbers and Terms
The five change types: Create, Delete, Modify, NoChange, Ignore.
--result-format: FullResourcePayloads or ResourceIdOnly.
Modes: Incremental (default) and Complete.
Commands: az deployment group what-if and New-AzResourceGroupDeployment -WhatIf.
The portal button is labeled 'What-If' on the 'Review + create' tab.
Edge Cases and Exceptions
Conditional resources: If a resource has a condition that evaluates to false, What-If shows Ignore. Candidates may mistakenly think it shows NoChange.
Nested templates: What-If processes nested templates recursively, but the output may be less detailed for child resources.
Resource tags: Changing tags results in a Modify change. If the template omits tags, What-If may show a Modify that sets tags to null, which could remove existing tags.
Resource locks and policies: What-If does not account for these; the actual deployment may fail even if What-If shows success.
How to Eliminate Wrong Answers
If the question asks about validation before deployment, the answer is likely What-If, not Azure Policy or cost estimation.
If the question mentions Complete mode and deletion, remember that What-If will show Delete for resources not in the template.
If the question asks about detecting property changes, look for the Modify change type and property diffs.
Always choose the option that mentions 'preview changes without deploying' or 'simulate deployment.'
What-If analysis previews ARM template deployment changes without modifying any resources.
The five change types are: Create, Delete, Modify, NoChange, and Ignore.
Delete changes only occur in Complete deployment mode.
What-If does not evaluate Azure Policy, resource locks, or subscription quotas.
Use `az deployment group what-if` (CLI) or `New-AzResourceGroupDeployment -WhatIf` (PowerShell).
Set `--result-format FullResourcePayloads` to see before/after property values.
What-If is available at resource group and subscription scopes.
Always run What-If before production deployments to catch unintended changes.
These come up on the exam all the time. Here's how to tell them apart.
What-If Analysis
Predicts resource changes (create, modify, delete) from an ARM template.
Does not evaluate policy rules.
Read-only operation; no resources changed.
Outputs property-level diffs for modified resources.
Used before deployment to validate intended changes.
Azure Policy Compliance Check
Evaluates existing resources against policy definitions.
Can deny or audit non-compliant resources.
Can enforce compliance by modifying or denying deployments.
Does not show property diffs; only compliance state (compliant/non-compliant).
Used during and after deployment to enforce governance.
Mistake
What-If analysis actually deploys resources temporarily and then removes them.
Correct
What-If is a read-only operation that never creates, modifies, or deletes any resources. It only computes the predicted changes by comparing the template with the current state.
Mistake
What-If can detect Azure Policy violations and deny the deployment.
Correct
What-If does not evaluate Azure Policy. It only shows resource-level changes. Policy compliance must be checked separately using Azure Policy compliance tools.
Mistake
What-If in Incremental mode will show Delete changes for resources not in the template.
Correct
In Incremental mode, resources not in the template are left unchanged, so What-If shows NoChange for them. Delete changes only appear in Complete mode.
Mistake
What-If provides cost estimates for the deployment.
Correct
What-If does not provide cost information. Cost estimation is a separate capability available through the Azure Pricing Calculator or Azure Cost Management.
Mistake
What-If will show errors if the template references non-existent resources.
Correct
What-If validates the template structure and may show errors for invalid resource types or API versions, but it does not check whether referenced resources (e.g., parent resources) exist. It only compares the template with the current state of the deployment scope.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. What-If is a read-only simulation. It compares the ARM template against the current state of Azure resources and returns a list of predicted changes. No resources are created, modified, or deleted during the What-If operation.
Use `az deployment sub what-if` for Azure CLI, or `New-AzDeployment -WhatIf` for PowerShell. The template must be scoped to the subscription (e.g., deploying policy assignments, role assignments, or management groups).
Yes. What-If processes linked templates recursively, as long as the template URIs are accessible. The output will include changes for resources defined in nested templates, though the level of detail may be less granular for deeply nested resources.
Tags are properties of a resource. If your template includes tags that differ from the current tags (or if the template omits tags), ARM considers it a modification. If you want to preserve existing tags, you must explicitly include them in the template using the `tags` property.
Ignore means the resource is defined in the template but will not be deployed because the `condition` property evaluates to false, or the resource is a child resource that is implicitly created by its parent. It is not an error; it indicates the resource is intentionally skipped.
Yes. When deploying a custom template via the portal, after providing the template and parameters, you go to the 'Review + create' tab. There is a 'What-If' button that displays the predicted changes in a side pane.
Absolutely. You can run What-If as a step in Azure DevOps or GitHub Actions. The output can be captured and reviewed manually or automatically compared against expected changes. Many teams require What-If approval before actual deployment.
You've just covered What-If Analysis for ARM Deployments — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?