Bicep Parameters

Parameters are the inputs of a Bicep template. They allow the same Bicep file to deploy different configurations without changing a single line of code. A parameter works like a form field — the template defines the field, and the person or pipeline deploying it fills in the value.

Think of a hotel room booking form. The form is the same for every guest (the template), but each guest fills in different dates, room type, and special requests (the parameters). The hotel (Azure) uses those inputs to prepare the right room (resource).

Basic Parameter Syntax

param <parameterName> <dataType> = <defaultValue>

The default value is optional. When provided, the deployment uses that value if no input is given. When omitted, the deployment fails unless a value is supplied at runtime.

// Parameter WITH a default value
param location string = 'eastus'

// Parameter WITHOUT a default value (required at deployment time)
param storageAccountName string

// Parameter with an integer type and default
param instanceCount int = 2

Parameter Data Types

Bicep supports six built-in data types for parameters. Each type enforces the correct kind of value and prevents mistakes.

Parameter Examples by Type

String Parameter

param location string = 'eastus'
param appName string = 'mywebapp'

Integer Parameter

param replicaCount int = 3
param port int = 8080

Boolean Parameter

param enableHttpsOnly bool = true
param isProduction bool = false

Object Parameter

param tags object = {
  environment: 'production'
  project: 'e-commerce'
  owner: 'platform-team'
}

Array Parameter

param allowedLocations array = [
  'eastus'
  'westus'
  'centralus'
]

Secure String Parameter

@secure()
param adminPassword string

The @secure() decorator prevents the value from appearing in deployment logs or Azure Portal history. Always use secureString for passwords and secrets — never store them as plain string parameters.

Parameter Decorators – Adding Rules and Descriptions

Decorators add validation rules and metadata to parameters. They appear on the line directly above the parameter declaration and start with the @ symbol.

+--------------------------------------------+
|          Common Parameter Decorators        |
+----------------------+---------------------+
|  Decorator           |  What It Does        |
+----------------------+---------------------+
|  @description()      |  Adds a description  |
|  @allowed()          |  Restricts values    |
|  @minLength()        |  Minimum characters  |
|  @maxLength()        |  Maximum characters  |
|  @minValue()         |  Minimum number      |
|  @maxValue()         |  Maximum number      |
|  @secure()           |  Hides the value     |
+----------------------+---------------------+

@description Decorator

@description('The Azure region where all resources will be deployed.')
param location string = 'eastus'

@allowed Decorator

@description('The environment type. Only these three values are allowed.')
@allowed([
  'dev'
  'staging'
  'prod'
])
param environment string = 'dev'

When someone tries to deploy with environment = 'test', Bicep rejects it before any resource is created. This prevents typos and wrong environment deployments.

@minLength and @maxLength Decorators

@description('Storage account name must be 3 to 24 characters.')
@minLength(3)
@maxLength(24)
param storageAccountName string

@minValue and @maxValue Decorators

@description('Number of VM instances. Must be between 1 and 10.')
@minValue(1)
@maxValue(10)
param vmCount int = 2

Combining Multiple Decorators

@description('Admin username for the virtual machine.')
@minLength(4)
@maxLength(20)
param adminUsername string = 'azureAdmin'

@description('Admin password. Must meet Azure complexity requirements.')
@secure()
@minLength(12)
param adminPassword string

How Parameters Flow into Resources

Parameters pass their values into resource properties by referencing the parameter name directly inside the resource block.

Deployment Command
      │
      │  --parameters location=westus appName=myapp
      ▼
+------------------+
|   Bicep File     |
|                  |
|  param location  ◄──── 'westus'
|  param appName   ◄──── 'myapp'
|                  |
|  resource {      |
|    name: appName │──── used here
|    location:     │
|      location    │──── used here
|  }               |
+------------------+
      │
      ▼
  Azure Creates: App with name 'myapp' in 'westus'

Complete Example – Parameters in Action

// Parameters with decorators and defaults
@description('Azure region for all resources.')
@allowed(['eastus', 'westus', 'centralus'])
param location string = 'eastus'

@description('Name of the storage account. Must be globally unique.')
@minLength(3)
@maxLength(24)
param storageAccountName string

@description('Storage redundancy SKU.')
@allowed(['Standard_LRS', 'Standard_GRS', 'Standard_ZRS'])
param storageSku string = 'Standard_LRS'

@description('Resource tags.')
param tags object = {
  environment: 'dev'
  createdBy: 'Bicep'
}

// Resource using the parameters
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  tags: tags
  sku: {
    name: storageSku
  }
  kind: 'StorageV2'
}

Parameter Files – Supplying Values Separately

Instead of passing parameter values on the command line, Bicep supports parameter files. A parameter file (with extension .bicepparam) stores all values for a specific environment.

Structure of a Parameter File (.bicepparam)

using 'main.bicep'

param location = 'eastus'
param storageAccountName = 'prodstorageabc123'
param storageSku = 'Standard_GRS'
param tags = {
  environment: 'production'
  createdBy: 'Bicep'
}

How to Use a Parameter File at Deployment

az deployment group create \
  --resource-group myResourceGroup \
  --template-file main.bicep \
  --parameters main.bicepparam

Environment-Specific Parameter Files

The recommended pattern for managing multiple environments is one Bicep file and separate parameter files for each environment.

project/
│
├── main.bicep              ← Single template file
│
├── dev.bicepparam          ← Development values
├── staging.bicepparam      ← Staging values
└── prod.bicepparam         ← Production values

This structure keeps the infrastructure logic in one place while the environment-specific values stay separate. Deploying to development uses dev.bicepparam and deploying to production uses prod.bicepparam — the same template, different inputs.

Summary

Parameters make Bicep templates reusable and flexible. Bicep supports six data types: string, int, bool, object, array, and secureString. Decorators like @description, @allowed, @minLength, and @secure add validation and metadata. Parameter files separate environment-specific values from the template logic, enabling clean multi-environment deployments from a single Bicep file.