Empower Bicep to Control its Destiny with Conditional Logic

One of the most valuable tools in Bicep’s toolkit is the conditional statement, which allows you to create flexible deployments by toggling the provisioning of resources based on specific conditions. Here’s a quick guide to mastering conditional statements in Bicep, along with best practices and examples to help you make the most of this feature.

Note: I also created a blog post that discusses conditional statements in Terraform.

Understanding Conditional Logic in Bicep

In Bicep, conditional statements can be applied at multiple levels to enable dynamic behavior. These statements help you customize resource deployment based on parameters, allowing for environments that automatically adapt based on inputs, such as different configurations for staging, testing, or production. By integrating conditionals, you can reduce complexity, improve reusability, and ensure more controlled deployments.

When and Why to Use Conditionals in Bicep

• Environment-based Deployments: Imagine needing specific resources only for your production environment, such as advanced security configurations. Conditional statements can check for the environment type and deploy resources accordingly.
• Customization for Different Tenants: If you’re deploying solutions to multiple tenants, you might want to enable or disable resources based on tenant needs or feature requirements.

Using conditionals allows you to achieve a higher level of control over deployments, which can lead to cost savings, operational efficiency, and overall improved management.

The Basics: IF Statements in Bicep

Bicep conditionals use an if statement at the resource level. The syntax is relatively straightforward:

param shouldDeployStorageAccount bool = true

resource myResource 'Microsoft.Storage/storageAccounts@2021-04-01' = if (shouldDeployStorageAccount) {
  name: 'storage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

In this example:

• The variable shouldDeployStorageAccount (likely a parameter or a conditional expression) determines whether the resource is created.
• If shouldDeployStorageAccount is true, the resource is deployed. If false, it is skipped.

Advanced Conditional Logic

To go beyond simple true or false evaluations, you can combine conditionals with parameters and expressions, achieving more complex decision-making within your templates.

For instance, you could use a parameter that specifies the environment type and then apply logic to decide which resources to deploy:

param environment string = 'development'

resource resourceGroup2 'Microsoft.Resources/resourceGroups@2024-03-01' = if (environment == 'production') {
  name: resourceGroupName
  location: location
}

In this example, the resource only deploys if environment is set to “production”. This flexibility allows you to write a single template that serves multiple scenarios.

Conditional Logic to determine specific settings

Not only can you determine whether or not a resource gets deployed, but also how the resource should be configured, based on conditional logic.

In this example, we’ll use an environment parameter to determine whether the storage account should be configured with GRS or LRS. If the environment is set to “production,” the storage account will use GRS; otherwise, it defaults to LRS.

param storageAccountName string
param location string = resourceGroup().location
param environment string = production // Expected values: 'production', 'development', 'staging', etc.

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: storageAccountName
  location: location
  sku: {
    // Conditional replication setting based on environment
    name: environment == 'production' ? 'Standard_GRS' : 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    // Additional properties as needed
  }
}

We can extend the template by adding conditional logic to set the kind of the storage account based on whether a function parameter is set to "share". This example will demonstrate using conditional logic for both the sku.name (replication) and kind properties, making the template adaptable to different storage requirements based on function and environment.

param storageAccountName string
param environment string // Expected values: 'production', 'development', etc.
param function string = 'general' // Expected values: 'datalake', 'general'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: storageAccountName
  location: location
  sku: {
    // Conditional replication setting based on environment
    name: environment == 'production' ? 'Standard_GRS' : 'Standard_LRS'
  }
  // Conditional kind setting based on function type
  kind: function == 'share' ? 'fileStorage' : 'StorageV2'
  properties: {
    // Additional properties as needed
  }
}

Explanation

• sku.name: Sets the replication type based on the environment:
  • Production: Sets to 'Standard_GRS'.
  • Non-production: Defaults to 'Standard_LRS'.
• kind: Uses a conditional to select the storage kind based on the function parameter:
  • If function is "share": Sets kind to 'fileStorage', which is typically used for SMB or NFS Shares.
  • Otherwise: Sets kind to 'StorageV2', appropriate for general-purpose storage accounts.

Best Practices for Using Conditionals

• Keep Conditionals Simple: Complex conditionals can make templates difficult to read and debug. Aim to use them sparingly and only when they add clear value.
• Document Parameters and Conditions: When working with multiple environments, provide clear comments on parameters and conditions. This helps users understand when and why each resource is deployed.
• Test Extensively: Ensure that each conditional path is tested to prevent unexpected behaviors during deployment.

Conditionals are Awesome

Using conditional statements in Bicep allows for flexible, reusable, and cost-efficient templates. By mastering the basics and best practices, you can create templates that dynamically adapt to different environments, streamline your deployment processes, and avoid redundant resources. Integrate these conditionals thoughtfully, and watch your infrastructure as code efforts become more manageable and efficient.