Bicep

What it is

Bicep is a domain-specific language (DSL) that lets you define Azure infrastructure declaratively as code, with an easy-to-read, concise syntax. It transpiles to ARM template JSON before deployment, so it is a friendlier authoring layer over the same Azure Resource Manager deployment engine.

Why it exists

ARM templates (JSON) are verbose, hard to read, and error-prone. Bicep gives you the same declarative infrastructure-as-code power — variables, parameters, modules, loops, conditions, dependencies — with syntax like a modern language, plus native tooling (formatter, linter, VS Code extension, preview of changes).

Key ideas

• Transpilation: bicep build compiles a .bicep file → ARM JSON; you deploy that, or deploy .bicep directly (az deployment group create -f main.bicep).
• Declarative: you state the target state; ARM computes the diff from current state and applies it (idempotent, no re-provisioning of unchanged resources).
• Modules (module child './x.bicep') reuse template pieces; parameters and variables make templates configurable.
• Resource dependencies are inferred automatically (Bicep figures out the order).
• Compiles to full ARM JSON → all ARM features (expression evaluation, functions) still apply.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: azure-resource-manager/bicep/overview

Exam notes

• Bicep compiles to (maps 1:1 to) an ARM template — they are two views of the same deployment.
• Files end in .bicep; az deployment targets resource-group or subscription scope.
• In AZ-104 pop quiz: “declarative, readable language for Azure IaC” → Bicep (vs imperative CLI/portal); preferred over hand-writing JSON.
• Same deployment engine as ARM templates → idempotent diff-based apply.

Related

Path MOC · arm-template · azure-cli · azure-vm

📘 Source: Microsoft Learn — Bicep