Bicep Tips and Tricks | #5 | From Documentation to Deployment-Time Validation: Conditional Parameter Requirements
Overview
In Bicep templates, we sometimes encounter scenarios where certain parameters should be mandatory based on the value of another parameter. For example, when deploying to production environments, you might require additional configuration parameters that are optional for development environments.
One of the common ways in which I have seen this handled is through documentation, which can lead to deployment failures and inconsistent configurations across environments. This post explores how to implement fail-fast validation using Bicep’s built-in capabilities to enforce these conditional requirements at deployment time.
Example of a Documentation-Only Approach
Handling conditional parameter requirements through documentation alone:
@description('Environment to deploy to')
@allowed([
'dev'
'test'
'prod'
])
param environment string
@description('Resource configuration - REQUIRED for prod environment!')
param resourceConfig string = ''
// Additional parameters that should be required in prod
@description('Monitoring configuration - REQUIRED for prod environment!')
param monitoringConfig object = {}
@description('Backup configuration - REQUIRED for prod environment!')
param backupRetentionDays int = 0
Problems with this approach:
- No enforcement at deployment time
- Deployments can succeed with missing critical configuration
- Relies on human memory and documentation
- Inconsistent environments due to missing parameters
- Production issues from misconfiguration
Recommended Approach: Fail-Fast Validation
I would recommend using the Bicep fail()
function combined with conditional logic to validate parameters early in the deployment process. This approach provides immediate feedback and prevents deployments with invalid configurations, such as in the following examples:
- Production environments - Storage deployments requiring backup retention settings for production
- Key Vault requiring network access rules when public access is disabled
@description('Environment to deploy to')
@allowed([
'dev'
'test'
'prod'
])
param environment string
@description('''Resource Configuration:
- **Optional** When environment is dev / test.
- **Required** When environment is prod.''')
param resourceConfig string = ''
@description('Resource Configuration Validation Result')
var resourceConfig_Result = environment == 'prod' && empty(resourceConfig)
? fail('resourceConfig is required to deploy this template in the prod Environment.')
: {
value: resourceConfig
valueProvided: !empty(resourceConfig)
}
⚠️ Note: Make deployment failures informative and actionable, helping your team understand exactly what’s needed to fix the issue.
Why this approach is useful
- Enforces deployment rules: Prevents deployment in “prod” if critical configuration is missing, ensuring required configuration is provided before any resources are created.
- Fail-fast validation: Catches configuration errors at the start of deployment, saving time and preventing partial deployments.
- Conditional resource creation: You can use the
valueProvided
property to conditionally deploy resources or set properties only when configuration is supplied. - Parameter validation: Centralizes validation logic, making it easier to maintain and extend checks for other environments or parameters in the future.
- Compliance requirements: Ensures production environments always meet security and operational standards.
Summary
Conditional mandatory parameters in Bicep templates are a powerful way to enforce deployment standards and prevent configuration errors. Remember to make deployment failures informative and actionable, helping your team understand exactly what’s needed to fix the issue. Hope this helps, and happy Bicep-ing!
For the original version of this post see Andrew Wilson's personal blog at Bicep Tips and Tricks | #5 | From Documentation to Deployment-Time Validation: Conditional Parameter Requirements