Bicep Parameter Decorators

Decorators attach extra rules and notes to a parameter. A decorator starts with the @ symbol and sits on the line above the parameter. Rules such as "accept only these three values" or "hide this password" live in decorators, and Bicep enforces them before any resource is created.

Imagine a doorkeeper at an event. Guests with the right ticket walk in, and everyone else stops at the door. Decorators act as the doorkeeper for parameter values.

How a Decorator Guards a Parameter

  Value typed by user
          │
          ▼
  ┌───────────────────┐
  │   @allowed list   │──── value missing from list ───► Deployment stops
  └─────────┬─────────┘
            │ passes
            ▼
  ┌───────────────────┐
  │ @minLength / max  │──── wrong length ───────────────► Deployment stops
  └─────────┬─────────┘
            │ passes
            ▼
     Resource is created

@description

The description explains a parameter in plain words. The Azure portal and editor tools display it as help text.

@description('Name prefix used for all resources')
param appName string

@allowed

The allowed list restricts a parameter to approved values. Anything else fails validation.

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Premium_LRS'
])
param storageSku string = 'Standard_LRS'

@minLength and @maxLength

Length limits apply to strings and arrays. Storage account names need three to twenty-four characters, so the limits match the Azure rule.

@minLength(3)
@maxLength(24)
param storageName string

@minValue and @maxValue

Value limits apply to integers. A web farm that must run between one and ten servers uses both.

@minValue(1)
@maxValue(10)
param instanceCount int = 2

@secure

The secure decorator marks passwords, keys, and tokens. Azure keeps secure values out of the deployment history and logs.

@secure()
param adminPassword string

Rules for Secure Parameters

Never give a secure parameter a default value that contains a real secret. Never send a secure parameter into an output. Pass the value at deployment time or read it from Azure Key Vault.

@metadata

Metadata stores extra information, such as an author or a ticket number. Azure ignores the content during deployment.

@metadata({
  owner: 'platform-team'
  ticket: 'OPS-1042'
})
param costCenter string

Stacking Several Decorators

One parameter accepts many decorators. Each decorator sits on its own line, and the order does not matter.

@description('Number of web servers')
@minValue(1)
@maxValue(10)
param serverCount int = 2

@description('Administrator password for the virtual machine')
@secure()
@minLength(12)
param vmPassword string

What an Error Looks Like

Passing 15 for serverCount triggers a validation message that names the parameter and the allowed range. The failure appears in seconds, and no resource gets created. Catching a bad value early saves time and avoids half-finished deployments.

Decorators on Other Elements

Recent Bicep versions apply decorators to variables, outputs, and resources as well. The @description decorator suits outputs well, since it documents what a caller receives.

@description('Resource ID of the storage account')
output storageId string = storage.id

Why Validation Matters

Cloud deployments cost time and sometimes money. A typo in a storage account name can fail a deployment after several minutes of work. Decorators move the failure to the editor, where the fix takes seconds. Teams that share templates gain even more, since a decorator documents the expected input for every person who runs the file. New teammates read the rules in the template and skip the guessing.

Summary

Decorators add rules and documentation to parameters. The @allowed, @minLength, @maxLength, @minValue, and @maxValue decorators validate input. The @secure decorator protects sensitive values, and @description and @metadata record helpful notes. Stacking decorators builds clear, safe templates.