Azure Bicep what-if: review resource changes before running a deployment

Review the deployment that will actually run

Bicep describes Azure resources declaratively, while parameter values select the environment-specific configuration. A useful pre-deployment review uses the same template, scope and parameters as the intended deployment. Reviewing a development parameter file and then deploying production values is a different operation, even when the template file has not changed.

Start by recording the subscription, target resource group or other deployment scope, template artifact and parameter file. Keep secrets in supported secure parameter paths rather than embedding them in ordinary source files or command output. A reviewed change needs enough non-sensitive metadata to identify what was proposed.

Use what-if to inspect the resource-level difference

The Azure Resource Manager what-if operation previews proposed resource changes without applying that deployment. It can identify resources expected to be created, modified or removed and show property differences. Use those results to focus the review on changes with operational consequences, including identity, networking, names and dependencies.

What-if has documented limitations. Some expressions and provider behavior cannot be fully evaluated in advance, and a preview can contain differences that require interpretation. Treat an unexpected change as an investigation item rather than dismissing all output as noise. A clean-looking preview is not a guarantee that the deployment will succeed or that the application will remain healthy.

Make the preview part of a deliberate sequence

1. Validate the template and identify the exact target scope.
2. Review the intended environment parameter values and secret-handling path.
3. Run what-if using that same scope and input set.
4. Inspect every create, modify or delete result with operational impact.
5. Apply the reviewed deployment and verify resource state and application health.

For a resource-group deployment, the Azure CLI deployment group what-if command accepts the selected resource group and Bicep template. Include the intended subscription explicitly in operational commands so a familiar resource-group name in another subscription cannot redirect the change. Store the reviewed result with the corresponding artifact identity.

Parameters need their own consistency checks

Resource names, location, SKUs and network identifiers can alter the meaning of a template. Validate permitted values and environment conventions in deployment code where practical. A parameter that points to an existing shared subnet or identity deserves the same attention as a newly created resource because it changes a real trust or lifecycle boundary.

Avoid placing a default production secret in a template as a shortcut. Secure parameters protect the appropriate deployment representation, while runtime secret storage and application configuration remain separate responsibilities. Verify that deployment logs and saved artifacts contain only the non-sensitive values needed for review.

Close the gap between preview and application outcome

After deployment, inspect the resulting resource properties and run the application's health and representative operation checks. Confirm that identities can reach their dependencies and that outputs match the intended environment. Bicep and what-if make infrastructure changes reviewable; verification connects that resource plan to the behavior the application actually needs.

References

• Bicep What-If: Preview Changes Before Deployment - Azure — Microsoft Learn
• Parameters in Bicep files - Azure Resource Manager — Microsoft Learn