In brief
What-if predicts how an ARM deployment may change the current environment without applying those changes. It is a critical review input, but not a guarantee of deployment success or application health.
Key takeaways
- Run what-if at the exact scope with the intended parameters and identity.
- Review deletes, replacements, and security-sensitive property changes first.
- Investigate noisy or ignored changes rather than training reviewers to ignore output.
- Verify the deployed resource and workload after Resource Manager succeeds.
Generate the right what-if result
Use the same Bicep revision, parameter values, deployment scope, tenant, subscription, region, and identity intended for the real deployment. A resource-group result does not describe subscription- or management-group changes, and a test parameter file does not prove the production change set.
What-if requires permission to inspect existing resources and evaluate the deployment. Missing access, unresolved references, short-circuit behavior, limits, or provider responses can reduce detail. Treat diagnostics and ignored changes as review findings, not harmless noise.
Review the change categories by risk
Start with deletions and changes that can replace resources, remove data, rotate identity, alter network access, or cause restart and downtime. Then review creates for naming, quotas, region, SKU, zones, private connectivity, diagnostics, backup, and ownership. Finally inspect ordinary property changes and unchanged dependencies.
Property expressions, defaults, API-version behavior, and reference functions can produce results that are difficult to interpret. Compare the Bicep source, compiled template when needed, current Azure state, and provider documentation. Do not approve an unexplained difference only because it has appeared in previous deployments.
- Confirm all Delete actions are intentional and recoverable.
- Review identity, RBAC, firewall, TLS, public access, and private endpoint changes.
- Check SKU, capacity, zones, retention, backup, locks, and diagnostics.
- Confirm parameter and module versions are the approved production inputs.
Understand what what-if cannot prove
What-if predicts Resource Manager changes; it does not execute application tests, confirm capacity will remain available, prove that every policy evaluation stays unchanged, or guarantee that a workload will start. Remote state and provider behavior can change between preview and deployment.
Validation also cannot replace a rollback decision. Before deployment, define the signals that require stopping or reverting, the recoverable unit, backup or retention requirements, and the people authorized to make that decision.
Deploy with traceability and verify
Use a meaningful deployment name and retain the reviewed artifact and parameters according to policy. Monitor deployment operations and Azure Activity Log. If the result differs materially from what-if, stop and understand the difference before continuing with dependent changes.
After Resource Manager reports success, verify the actual configuration, security controls, diagnostics, and service behavior. Test the intended user transaction and watch workload health. Infrastructure deployment success is only one layer of production verification.