How to preview Bicep changes with what-if

The what-if command in the Azure CLI shows which resources a Bicep file will create, change or remove, before you apply anything. It works like a preview — a diff of your infrastructure — and it is the simplest way to avoid surprises in production. Best of all, it changes nothing: it is a safe, read-only operation. Here you will use what-if with an example Storage Account and learn how to read the output.

Prerequisites

• An active Azure subscription with permissions to create resources.
• The Azure CLI installed and signed in with az login.
• A resource group for testing, for example rg-demo.
• A text editor (VS Code with the Bicep extension helps, but is not required).

Step 1: Create a simple Bicep file

Create a file named main.bicep that declares a Storage Account. This is the resource that what-if will analyse:

param location string = resourceGroup().location
param storageName string

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

A Storage Account name must be globally unique: lowercase letters and numbers only, between 3 and 24 characters.

Step 2: Make sure the resource group exists

what-if needs a scope to compare against. If you do not have one yet, create the resource group:

az group create --name rg-demo --location westeurope

Step 3: Run what-if

Now ask the Azure CLI to calculate the difference between your file and what already exists in the resource group. Because the Storage Account does not exist yet, the result should be a create:

az deployment group what-if --resource-group rg-demo --template-file main.bicep --parameters storageName=stbconceptsdemo01

what-if sends your template to Azure, which compares it with the current state and returns only the differences. No resource is changed at this stage. Replace stbconceptsdemo01 with a free name that follows the rules from Step 1.

Step 4: Read the output

what-if prints each resource with a symbol and a colour in front of it. These are the ones you will see most often:

• + Create: the resource will be created.
• ~ Modify: the resource already exists and will change; the output shows it property by property.
• - Delete: the resource will be removed.
• = NoChange: it stays exactly the same.
• ! Ignore: it is outside the scope and is not touched.

On this first run you should see a line starting with + and the path Microsoft.Storage/storageAccounts/stbconceptsdemo01, a sign that the create is ready to go.

Step 5: Trigger a Modify

To see what-if detect a change, do the real deploy first and only then edit the file. Apply the Bicep:

az deployment group create --resource-group rg-demo --template-file main.bicep --parameters storageName=stbconceptsdemo01

Open main.bicep and change the SKU from Standard_LRS to Standard_GRS. Run the Step 3 command again: instead of Create, you should now see ~ Modify, with the sku.name line moving from one value to the other.

Check the result

You know it works when the final what-if summary reflects your intent. The CLI ends with a count such as Resource changes: 1 to create on the first run and 1 to modify after you touch the SKU. If you see 0 to create, 0 to modify when you expected changes, confirm you are pointing at the right resource group and that you saved the file.

Conclusion

With what-if you get a reliable preview of every Bicep deploy, which greatly reduces the risk of creating, changing or deleting something by accident. The natural next step is to put this command in your CI/CD pipelines, so that every Pull Request shows the infrastructure impact before approval. A handy day-to-day tip: use az deployment group create --confirm-with-what-if to see the diff and confirm the deploy in the same command. Where in your workflow would this preview give you the most peace of mind?