Tired of hardcoding values in your Bicep templates? It’s a common pitfall that can lead to repetitive deployments and potential errors. But what if there was a cleaner, more flexible way to manage your Azure infrastructure configurations?
Bicep parameters are the answer, allowing you to easily customize deployments without touching your core Bicep code. In this guide, we’ll dive deep into how you can leverage Bicep parameters to make your deployments more dynamic, secure, and reusable. Get ready to supercharge your Azure automation!
Before we dive in, this is part 4 of the Bicep tutorial. Feel free to review the previous tutorial here
Azure Automation with Bicep – Resource Declaration (Part 3)
Master Azure Infrastructure Automation with Bicep – The Basics (Part 2)
Master Azure Infrastructure Automation with Bicep – Introduction (Part 1)
Table of Contents
Understanding Bicep Parameters
At the heart of making your Bicep deployments reusable and adaptable are Bicep parameters. Think of parameters as inputs that you can provide to your Bicep templates (.Bicep file), allowing you to customize deployments without altering the core template code. This is crucial for managing resources across different environments, such as development, staging, and production, where configurations like resource names, sizes, or locations might vary.
What are Bicep parameters?
In Bicep, parameters define inputs in your template and accept values during deployment. These values can range from simple strings for resource names to more complex types like arrays or objects for complex configurations. When you deploy your Bicep template, you pass values to these parameters, and Azure uses them to create or update your resources.
Why use parameters in Bicep?
The primary advantage of using parameters in Bicep is reusability. Instead of writing multiple templates for slightly different deployments, you can write one template and use parameters to tailor it for various scenarios. This not only saves time and effort but also promotes consistency in your infrastructure. For instance, you might have a standard virtual machine configuration, but the VM size or administrator username needs to differ between your development and production environments. Parameters handle this perfectly.
Defining Parameters in Bicep
Declaring parameters in your Bicep templates is straightforward, and Bicep provides robust options for defining their types, constraints, and metadata. This approach validates the inputs and keeps your deployments predictable.
What is the syntax for declaring a parameter?
Declaring a parameter in Bicep is simple. You use the param keyword, followed by the parameter name, and then optionally, its type and a default value.
Here’s the basic syntax:
param <parameter-name> <type = 'string'> = '<default-value>'For example, to declare a parameter for a storage account name:
param storageAccountName string = 'mystorageaccount'How to specify parameter types (string, int, bool, array, object)?
Bicep supports several built-in data types for parameters, ensuring type safety and preventing deployment errors.
string: For text values, like resource names or descriptions.
param resourceName string = 'myResource'
int: For whole numbers, useful for counts or sizes.
param instanceCount int = 1
bool: For true/false values, often used for enabling/disabling features.
param enableMonitoring bool = true
array: For ordered lists of values.
param locationArray array = ['eastus', 'westus']
object: For collections of key-value pairs, useful for complex configurations.
param tagsObject object = {
environment: 'development'
project: 'bicep-demo'
}
Bicep dont use the double-quote, it uses a single quote… so keep this point in mind
Using The Decorators
Bicep decorators are optional annotations that you apply to parameters, variables, and outputs to add validation rules and guidance without changing the deployment logic itself. They let you describe a value, restrict the input, or improve usability in tools like the Azure Portal and VS Code by providing clearer prompts and validation feedback.
Decorators always start with @<DecoratorName>() and its placed just above the param word
Understanding and Using Allowed Decorator
The @allowed decorator is a simple way to restrict a parameter’s input to a predefined list of values. Instead of letting the user type anything (and risk a failed deployment), you provide a safe set of options that the deployment must follow.
For example, you can restrict regions or SKUs so the template accepts only a specific set of values. If the user tries to pass a value that isn’t in the allowed list, the deployment will fail early with a clear validation error.
The following example limits the storage SKU to two valid options. It prevents accidental choices like unsupported SKUs and helps keep deployments consistent across environments.
@allowed([
'Standard_LRS'
'Standard_ZRS'
])
param storageSku string = 'Standard_LRS'
Understanding the minLength and maxLength Decorators in Bicep
The @minLength and @maxLength decorators are used to control the length of string parameters in a Bicep file. They help ensure that user input meets Azure naming rules and avoids deployment failures caused by values that are too short or too long. These decorators are commonly used for resource names, prefixes, or identifiers that must follow strict length requirements. If the provided value falls outside the allowed range, the deployment fails immediately with a clear validation message. Using them makes your templates safer and more user-friendly
In the following example, the parameter must be at least 3 characters and no more than 11 characters long.
@minLength(3)
@maxLength(11)
param namePrefix string = 'app'
Understanding Secure Parameters in Bicep
Use secure parameters to pass sensitive values into a deployment without exposing them in clear text.
In Bicep, you mark a parameter as secure using the @secure() decorator, which tells Azure to treat the value as a secret so it won’t be shown in deployment outputs, logs, or the portal in plain text.
@secure()
param SecureadminPassword string
resource vm 'Microsoft.Compute/virtualMachines@2023-07-01' = {
name: ......
location: .......
properties: {
osProfile: {
computerName: ......
adminUsername: ......
adminPassword: SecureadminPassword <-- The Secure Parameter value
}
// ...other required VM properties
}
}
Using Parameter Files Effectively
A Bicep parameter file is a text file with .bicepparam extension that contains the values for the parameters defined in your Bicep template. Instead of passing each parameter individually during deployment, you can provide a single file that holds all the necessary values. This is useful for large templates with many parameters or when you need to reuse the same set of parameters across multiple deployments.
How To Create a Bicep Parameter File?
The structure of a Bicep parameter file directly reflects the parameters defined in your Bicep template. Each entry in the parameter file matches a parameter name from the Bicep file, and the value you provide is what gets passed into that parameter during deployment.
The parameter file begins with a using statement, which points to the Bicep template file it belongs to. After that, it lists the parameters expected by the template and assigns values to each one for use during deployment.
using '<path>/<file-name>.bicep'
param <first-parameter-name> = <first-value>
param <second-parameter-name> = <second-value>
param <third-parameter-name> = <variable-name>Let’s take a moment to step back and consider a quick example. Let’s say that we have a Bicep file with the following parameter
param StrAccName as string
@allowed([
'uaenorth'
'eastus'
])
param reslocation 
Now, let’s take a look at the Bicep parameter file. The using statement points to the path of the Bicep template file, establishing the link between the parameter file and the template. After that, each parameter is defined using the same parameter names from the Bicep file, and values are assigned to them inside the .bicepparam file.
using './StroageAcc-template.bicep'
param StrAccName = 'corp1storageacc'
param reslocation = 'uaenorth'Review the Bicep template to identify parameters that have default values defined. For those parameters, supplying a value in the parameter file is optional—but if you do provide one, it will override the default value specified in the Bicep file.
Creating Azure Bicep Parameter File Automatically
If you don’t want to manually create a .bicepparam file, Azure CLI can generate one for you automatically using az bicep generate-params. This command reads your main.bicep, detects all declared parameters, and then creates a ready-to-edit parameter file for you
You can customize the command to either including all parameters (even the ones with defaults) or only the required parameters that don’t have default values.
To generate a .bicepparam file that includes all parameters (even the ones that already have default values), use --include-params all with --output-format bicepparam. This is useful when you want a complete “fill in everything” baseline, especially for sharing templates with others or documenting all configurable inputs. Microsoft Learn
az bicep generate-params --file main.bicep --output-format bicepparam --include-params allIf you don’t include --include-params all, the generated output will only include parameters that don’t have default values (the required ones). This is great when you want the smallest possible parameters file, only the values you must provide to make the deployment work.
az bicep generate-params --file main.bicep --output-format bicepparam Deploying the Bicep Template
Once your .bicep file is ready, deploying it with Azure CLI (AZ) is straightforward. First, make sure you’re authenticated using az login, then target the right subscription if you have more than one. From there, you deploy the template to a resource group using az deployment group create, pointing to your Bicep file with --template-file and then you can pass the parameter inline or use a parameter file.
Deploying Azure Bicep Templates with Inline Parameters
This deployment approach allows you to pass parameter values directly in the Azure CLI command. It’s a quick and convenient option for testing templates or running simple deployments where only a few parameters are required
# (1) Sign in
az login
# (2) Deploy to a Resource Group
az deployment group create \
--resource-group MyResourceGroup \
--template-file main.bicep \
--parameters location=eastus namePrefix=app # <-- Here are the list of parameters
az deployment group create means you’re creating a deployment at the resource group scope (so resources will be deployed into a specific RG).
--resource-group MyResourceGroup tells Azure which resource group to deploy into.
--template-file main.bicep points to the Bicep file you want to deploy.
--parameters location=eastus namePrefix=app supplies parameter values inline. Here, location is set to eastus, and namePrefix is set to appthese must match the parameter names you defined in your Bicep file.
If your deployment targetting a subscription, such as creating Resource Group, the use az deployment sub create
Deploying Azure Bicep Templates Using a Bicep Parameters File
Deploying Azure Bicep templates using a Bicep parameters file .bicepparam is the cleanest way to manage configuration without cluttering your deployment command. Instead of typing values inline every time, you keep environment-specific settings, like names, locations, SKUs, and feature flags in a dedicated file and reference it during deployment.
This makes your deployments more consistent and repeatable when you have multiple environments (dev/test/prod) because you can reuse the same Bicep template while simply switching the parameter file.
az deployment group create --name ExampleDeployment --resource-group ExampleGroup --parameters storage.bicepparam <--- The Parameter fileWhat happens if a required parameter is missing?
If your Bicep template defines a required parameter (one without a default value) and you do not provide a value for it during deployment, the deployment will fail. Azure Resource Manager (ARM) will report an error indicating that a required parameter is missing. This built-in validation helps ensure that your deployments have all the necessary information to succeed.
home/azure/mainstorageaccount.bicepparam(1,7) : Error BCP258: The following parameters are declared in the Bicep file but are missing an assignment in the params file: “storageAccountName”. [https://aka.ms/bicep/core-diagnostics#BCP258]
Conclusion
In this post, we explored how Bicep parameters make your templates flexible, reusable, and easier to manage across different environments. We covered how to define and validate parameters, how defaults and decorators improve safety, and the different ways to supply values during deployment, whether inline with Azure CLI or through a dedicated parameters file.
