L12. Infrastructure as Code: Bicep, ARM & Desired State Configuration
Bicep transpiles to the same ARM engine with cleaner syntax, what-if deployments preview changes before they happen, and Azure Automation State Configuration keeps in-guest VM settings from drifting.
ARM Templates vs Bicep
ARM (Azure Resource Manager) templates are JSON-based infrastructure definitions that Azure has supported since 2015. They are verbose but universally supported across all Azure services.
Bicep is a domain-specific language that transpiles to ARM JSON before deployment. It offers cleaner, more readable syntax with support for modules and reusable components, while deploying through the same ARM engine. Bicep has full day-one support for new Azure resource types because it transpiles to the same underlying ARM JSON that new resources use.
What-If Deployments: Preview Before You Deploy
The what-if operation evaluates a deployment against your current Azure resources and reports exactly what would be created, changed, or deleted without actually applying anything. This is the standard way to review an infrastructure change before it hits production.
What-if works for both ARM templates and Bicep files:
az deployment group what-if --resource-group myRg --template-file main.bicepOutput shows the exact changes, allowing you to catch unintended modifications before they happen.
Desired State Configuration: Enforce In-Guest Settings
Azure Automation State Configuration (DSC-as-a-service) is a declarative model for in-guest machine configuration. You assign a DSC configuration to a VM, and Azure Automation continuously checks whether the machine matches that configuration, auto-remediating drift.
Use cases include enforcing specific Windows features, registry settings, or required software to be present on every VM in a fleet.
Azure Machine Configuration: Policy-Driven Compliance
Azure Machine Configuration (formerly Guest Configuration) audits and can remediate in-guest settings through the Azure Policy framework. It serves the same goal as DSC (enforcing in-guest configuration) but is delivered through the policy system, making it easier to audit at scale across subscriptions.
Azure Deployment Environments: Self-Service Infrastructure
Azure Deployment Environments lets developers self-deploy pre-approved, governed infrastructure templates on demand for their own dev/test sandboxes. Templates are curated by platform teams, so developers get infrastructure guardrails without needing to understand ARM/Bicep syntax.
Benefits: cost (ephemeral environments torn down when done) and security (no risk of misconfiguration because templates are pre-approved).
IaC Strategy Fundamentals
Effective IaC follows these principles:
| Principle | Why It Matters |
|---|---|
| Source control | IaC definitions must be versioned alongside application code |
| Testing & validation | Use what-if to preview changes before applying them |
| Pipeline automation | IaC deployment and testing must be automated, just like application deployment |
| Idempotence | Running the same IaC should be safe multiple times |
Real-World IaC Workflow
A typical workflow: developer branches, updates a Bicep file, opens a PR. CI runs what-if to show the exact changes, reviewers approve, the PR merges, CD applies the deployment in staging first, then production after manual approval.
This keeps infrastructure changes transparent, auditable, and rollback-able because every change is tracked in Git. Exam tip: The AZ-400 exam heavily tests what-if as the standard way to validate IaC before applying it, and the distinction between Bicep (domain-specific) and ARM (JSON) in terms of features and day-one resource support.
- ✓Bicep is a DSL that transpiles to ARM JSON and deploys through the same ARM engine, giving it cleaner syntax and reusable modules while retaining full day-one support for new Azure resource types
- ✓Desired State Configuration (DSC), delivered as Azure Automation State Configuration, continuously enforces that a VM's in-guest configuration matches its assigned configuration and auto-remediates drift
- ✓Azure Machine Configuration (formerly Guest Configuration) audits and can remediate in-guest settings through the Azure Policy framework, addressing a similar problem to DSC through a different delivery mechanism
- ✓What-if deployment (available for both ARM templates and Bicep) previews exactly what an IaC deployment would change before it is actually applied, which is the standard way to validate an IaC change before it hits production
- ✓Azure Deployment Environments let developers self-deploy governed, pre-approved infrastructure templates on demand for their own sandboxes, reducing both cost (ephemeral, torn down when done) and risk (guardrails already built into the curated template)
1. Why might a team choose Bicep over writing ARM templates directly, given that both ultimately deploy through the same engine?
2. A team wants to preview exactly what changes an infrastructure-as-code deployment will make to their Azure resources before actually applying it, to catch an unintended change ahead of time. What should they use?
3. A team needs to ensure that every domain-joined VM in a fleet keeps a specific Windows feature enabled and a specific registry setting in place, and automatically corrects any machine that drifts from that configuration. What Azure service is purpose-built for this in-guest configuration enforcement?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.