Bicep Conditions

Deploy resources conditionally

You can use conditions in your Bicep code to deploy resources only when specific constraints are in place. You can use a condition to only deploy resources in certain conditions. This is great if you have a Production and Development environments where you want more expensive resources in your Production environment. Examples include when you’re creating app service or storage accounts where you may or may not want to use private link. So you can configure your Bicep code to only deploy private link if it’s needed. Or if your deploying VMs you may or may not want a shutdown schedule for the VM. You can use the one template for either scenario and just specify via a condition if you need a resource or not.

When you deploy a resource in Bicep, you can provide the if key word followed by a condition. You can also include expressions in your conditions so an evaluation happens.

The below example only creates a storage account if the parameter deployStorageAccount is equal to true. We’re using a boolean parameter type so the parameter can either be true or false.

You can also use conditions based on an environment as in the below example. We have an environmentName parameter with an allowed value of either Production or Development. We then have an if statement in the auditingSettings resource that uses the environmentName parameter and states, only deploy the resource if the environment is Production.

We can simplify this even further to make it more readable for anyone else who will be using your template by using a variable and using the variable in the condition. We declare the environmentName in the variable auditingEnabled to Production and then change the if statement to reference this variable as below.

This does the same thing as referencing the parameter in the if statement but is cleaner and more readable code.

Depend on conditionally deployed resources

When you deploy resources conditionally, you sometimes need to be aware of how Bicep evaluates the dependencies between them.

In the example below we are creating a storage account conditionally if the environment is Production and deploying auditing settings using the storage account if the environment is Production.

You’d expect the above example to work, but it doesn’t. The issue is with the storageEndpoint and storageAccountAccessKey properties and referencing the storage account. The issue is the auditing settings resource won’t be able to find the storage account if the environment is Development. It’s strange because the auditing settings shouldn’t deploy if the environment is Development. It seems to be an issue with the backend ARM template that gets deployed when the Bicep template is translated to an ARM template at deployment. To make the template work you need to add some more conditioning to the storageEndpoint and storageAccountAccessKey properties.

The below example has the additional conditioning and will function as expected. What we’ve done is add a condition to say if the environment is Production then configure the auditing setting, if the environment isn’t Production then do nothing. So, anything after the ? will get done if the condition is true, and anything after the : will get done if the condition is false.

About the author