DEV Community

1suleyman
1suleyman

Posted on

🔧 Understanding Parameters in Bicep: Make Your Templates Smarter and More Reusable

#azure #cloud #beginners #documentation

Hey again! 👋

If you’ve been diving into Bicep to manage your Azure infrastructure (like I have!), you’ve probably noticed something pretty powerful — parameters.

Think of parameters like the "settings page" for your Bicep templates. Instead of hardcoding everything into your file, you give people a way to customize their deployment — whether it’s the environment name, a storage account SKU, or the number of app instances. It’s like turning your static template into a flexible blueprint.

Let’s explore how it works — in human terms. 😄

🏗️ What’s a Parameter, Really?

Imagine you’ve got a recipe for pancakes. Instead of saying “use 2 cups of flour,” you could say “use {amount} cups of flour” — that way, your friend who’s cooking for 10 people can bump that number up.

That’s a parameter. It's a placeholder for a value that someone provides when they run your template.

In Bicep, it looks like this:

param environmentName string
Enter fullscreen mode Exit fullscreen mode
  • param tells Bicep this is a parameter.
  • environmentName is what you'll call it inside your template.
  • string is the data type (text, in this case).

💡 Give Your Parameters Defaults

Don’t want to force someone to fill in every blank? You can set default values, like this:

param environmentName string = 'dev'
Enter fullscreen mode Exit fullscreen mode

Now, if nobody overrides it, dev will be used.

Even better, you can use expressions as default values. For example, default to the current resource group’s location:

param location string = resourceGroup().location
Enter fullscreen mode Exit fullscreen mode

Super handy!

🧩 Parameter Types: Not Just Text

You can use different types of parameters to make your templates smarter:

Type Description
string For text.
int For numbers.
bool True/false values.
object For structured data (like a group of properties).
array For lists (like a list of regions).

🧱 Object Example 

param appServicePlanSku object = {
  name: 'F1'
  tier: 'Free'
  capacity: 1
}
Enter fullscreen mode Exit fullscreen mode

Use this object in a resource:

sku: {
  name: appServicePlanSku.name
  tier: appServicePlanSku.tier
  capacity: appServicePlanSku.capacity
}
Enter fullscreen mode Exit fullscreen mode

📋 Array Example 

param cosmosDBAccountLocations array = [
  { locationName: 'eastus' }
  { locationName: 'westeurope' }
]
Enter fullscreen mode Exit fullscreen mode

Perfect for services that need multiple values — like Cosmos DB region replication.

🛡️ Secure Parameters (Because Secrets Matter)

You can mark a parameter as secure, so it won’t show up in logs or the CLI prompt:

@secure()
param sqlAdminPassword string
Enter fullscreen mode Exit fullscreen mode

Use this for passwords, API keys, and secrets.

🔐 Pro tip: Avoid putting secrets in plain text inside parameter files or templates. Use Azure Key Vault and reference the secret instead. Like this:

"sqlAdminPassword": {
  "reference": {
    "keyVault": {
      "id": "/subscriptions/xxxx.../vaults/mykeyvault"
    },
    "secretName": "sqlPassword"
  }
}
Enter fullscreen mode Exit fullscreen mode

🚦 Parameter Rules and Validation

Make your templates foolproof by setting rules with decorators. For example:

✅ Allowed values: 

@allowed([
  'dev'
  'test'
  'prod'
])
param environmentName string
Enter fullscreen mode Exit fullscreen mode

🔢 Length limits: 

@minLength(5)
@maxLength(24)
param storageAccountName string
Enter fullscreen mode Exit fullscreen mode

🔢 Number limits: 

@minValue(1)
@maxValue(10)
param instanceCount int
Enter fullscreen mode Exit fullscreen mode

This ensures you don’t end up with a deployment that fails later because someone typed “hello123” where a number was expected.

🧾 Parameter Descriptions = Built-in Documentation

Make life easier for others (or future you!) by adding descriptions:

@description('The number of instances for the App Service Plan (1-10).')
param instanceCount int
Enter fullscreen mode Exit fullscreen mode

These show up in tooling like the Azure portal or Visual Studio Code.

🗂 Parameter Files: Bundle Your Settings

If you’re deploying often or to multiple environments (like dev, staging, prod), use parameter files so you’re not typing values every time.

Here’s what a JSON parameter file might look like:

{
  "parameters": {
    "instanceCount": {
      "value": 3
    },
    "environmentName": {
      "value": "staging"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Deploy it like this:

az deployment group create \
  --template-file main.bicep \
  --parameters main.parameters.staging.json
Enter fullscreen mode Exit fullscreen mode

✨ Bonus: You can still override individual values on the command line:

--parameters instanceCount=5
Enter fullscreen mode Exit fullscreen mode

That override beats the value in the parameter file — just like how your microwave overrides the toaster if you’re trying to warm up pizza and toast at the same time. 😉

🎯 Summary

Here’s the deal: parameters make your Bicep templates powerful, safe, and easy to reuse. With types, constraints, secure values, and parameter files, you’re no longer writing rigid code — you’re building dynamic, deploy-anywhere blueprints.

They’re a key part of the “Infrastructure as Code” mindset — building your infra like you’d build a good app: modular, tested, and reusable.

💬 Learning Bicep too? Let’s connect on LinkedIn — drop me a message and say hey! I’m always down to chat about Bicep, Azure, or just learning in tech.

Top comments (0)