We have seen various articles about creating resources using Azure Bicep. We have seen how to pass parameters in order to dynamically set some properties of the resources. The problem is – we may need to create variety of resources and every resource may need multiple parameters. In this article we are going to have a look at the pattern which may help to reduce the parameters and will help to manage the input values more effectively.

The Problem Statement

As stated earlier, a bicep module may create more than one resources. Each resource may need one or more than one parameters. This means that soon the number of parameters may grow and it may become tedious job to manage those. While using the bicep files, it may be tedious to set all those parameters separately.

Some may say that that we can use bicep parameters file in order to reduce the headache of setting each parameter separately. That is true. But there is another problem. If we allow consumers to set each parameter value separately then there is a risk that a consumer may try untested combinations of the parameter values. This may cause issues and may result in spending the time in some unplanned activities (like, bugs, failures, etc.).

So, what is the solution ?

The Solution

The idea is to have a single parameter which may help to deduce other parameter values. For example, an environment setup may need :

• An app service
• A storage account, which should have a blob container and a table storage
• An Azure SQL instance (managed instance)
• A CosmosDB instance
• A queue triggered function

We may want to have various pricing tiers for dev and test environments. On the other hand, we may need highest pricing tier for production. The scaling requirements may be different as well.

So, we can take only one variable to define which environment we are deploying. Then we can create a map variable (which is the configuration set). This is basically an object which defines the specific configuration depending on the environment type. Then we can use this map variable in the bicep script.

Let’s have a look at the code snippet given below.  Here there is a single parameter, there are only three allowed values. Then there is a map variable, which shows only two objects – production and dev. Similarly, there can be another object for test or any other environment which we want to deploy.

We can also extract the map variable into another file and load it using File Functions.

I hope you find this information helpful. Let me know your thoughts.