Bicep 0.48.1

Apply these rules to Bicep templates, modules, .bicepparam files, configuration, and the Azure deployments they produce. Bicep compilation, Azure Resource Manager validation, resource-provider behavior, and deployment clients are separate trust boundaries.

Toolchain

• Use the newest stable Bicep release after reviewing it; Bicep publishes fixes in new releases rather than maintaining older minor lines. Look up the release on the official releases page instead of relying on memory. The version in this prompt's title identifies the researched behavior, not a release to install.
• Verify the compiler actually invoked with az bicep version or bicep --version, and keep CI, developer, and deployment paths aligned. Azure CLI manages its own self-contained Bicep installation; Azure PowerShell uses a separately installed executable.
• Have an update bot refresh immutable build-image references, and review its changes. Select binaries for the worker's operating system and architecture.
• Select Azure CLI or Az PowerShell deployment clients from their own supported releases and check their capabilities separately from Bicep. Use a client that exposes --validation-level or -ValidationLevel for the validation steps below; the options first appeared in Azure CLI 2.76.0 and Az PowerShell 13.4.0.

Configuration and cloud trust

• Review every applicable bicepconfig.json, including nested files: Bicep merges the nearest ancestor configuration with defaults. Restrict moduleAliases, extensions, implicitExtensions, cloud profiles, credential precedence, analyzers,