🚦 Deploy Resources Conditionally with Bicep

Hey! 👋

Back with another Bicep tip! So, your templates are getting smarter and more reusable — great! But what if you want certain resources to only deploy under specific conditions?

Like, maybe you're deploying to both production and dev environments. In prod, you want to enable SQL auditing and spin up extra monitoring resources. But in dev? Nah — keep it lean.

Bicep lets you handle this beautifully with conditional deployments.

Let me walk you through it 👇

🧠 The Basics: Using if in Bicep

In Bicep, you can use an if statement right in your resource declaration. If the condition is true, the resource is deployed. If not — it’s skipped.

🔍 Example:

param deployStorageAccount bool

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (deployStorageAccount) {
  name: 'teddybearstorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  // ...
}

💡 If deployStorageAccount is true, you get the resource. If false, it’s ignored. Clean!

🧾 Use Expressions in Conditions

You’re not limited to just true/false parameters. You can use expressions, too.

🎯 Example:

@allowed([
  'Development'
  'Production'
])
param environmentName string

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2024-05-01-preview' = if (environmentName == 'Production') {
  parent: server
  name: 'default'
  properties: {}
}

Only want to deploy the auditingSettings if we’re in Production? No problem. Bicep’s got you.

🧹 Make It Tidy with Variables

For readability, define your condition as a variable:

var auditingEnabled = environmentName == 'Production'

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2024-05-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {}
}

✅ It makes your template easier to follow and reuse.

🧩 Conditional Dependencies — Handle Carefully!

Here’s where things get interesting.

Let’s say your auditingSettings resource depends on a storage account… but that storage account is also conditionally deployed. You’d think if both have the same condition, you’re safe, right?

Wrong!

Azure evaluates expressions before checking conditions. So you need to guard those property values, too:

🧠 Example:

properties: {
  state: 'Enabled'
  storageEndpoint: auditingEnabled ? auditStorageAccount.properties.primaryEndpoints.blob : ''
  storageAccountAccessKey: auditingEnabled ? listKeys(auditStorageAccount.id, auditStorageAccount.apiVersion).keys[0].value : ''
}

If you don’t wrap the properties with the condition, the deployment will try to access a resource that doesn't exist — and crash with a ResourceNotFound error.

⛔ Don't Use the Same Name for Conditional Resources

You can't declare two resources with the same name in the same Bicep file and then use if to choose one to deploy. Even if only one ends up deployed, the template will still fail.

❌ This won’t work:

resource someResource '...' = if (conditionA) { ... }

resource someResource '...' = if (!conditionA) { ... }  // Conflict!

If you need different setups for different environments, you’re better off using modules with conditional declarations.

✨ TL;DR

• Use if on resource declarations to conditionally deploy based on parameters or expressions.
• Use variables for complex or repeated conditions to improve readability.
• Always guard any dependent resource properties inside if conditions.
• Don’t declare multiple resources with the same name, even if they’re conditionally deployed.
• When in doubt — move logic into modules!

Conditional deployments in Bicep give you the flexibility to write once, deploy smart. You’re not stuck managing separate templates for each environment — just pass in a parameter and let Bicep do the thinking.

Hope this helped! 🚀

Got more Bicep tricks? Let’s connect on LinkedIn — drop me a message and say hey! 👋

More Bicep coming soon 🛠️