AZ-400 exam questions on IaC focus on 'which tool to choose and when.' Understanding why ARM Templates and Bicep are closely related yet distinct, why Terraform is preferred in multi-cloud environments, and where DSC and Cloud-Init appear — all through concrete scenarios — is the key. Rather than memorizing tool names, grouping them by 'what they declare' makes everything cleaner.
Why IaC Matters: Clicks Leave No Memory
Imagine assembling IKEA furniture without the instruction booklet. You finish it, but six months later you need two more identical pieces and have no idea where to restart. Clicking through the Azure portal to create resources has the same problem — no record of who built what or with which settings, so reproducing the environment in staging means starting from scratch.
IaC (Infrastructure as Code) declares the 'desired state' of infrastructure as code. Storing that code in Git creates a change history, pull requests enable peer review, and CI/CD pipelines automate deployment. Two main approaches exist.
: describe the end state; the tool compares with the current state and acts. ARM Templates, Bicep, and Terraform all work this way. : list each step to execute in order. Azure CLI scripts and PowerShell work this way.
The exam focuses primarily on declarative tools because they guarantee — run the same template ten times and the result is always the same.
ARM Templates: The Blueprint for Azure Resources
Before construction begins, an architect draws detailed blueprints specifying column positions, window sizes, and floor counts. ARM Template is that blueprint for Azure resources. Written in JSON, it is read by Azure Resource Manager, which creates and configures the requested resources.
Main sections of an ARM Template:
: values supplied at deployment time (environment name, VM size, etc.) : reusable intermediate computed values : the list of Azure resources to create (the core section) : values returned after deployment (URLs of created resources, etc.)
The main drawback is JSON's verbosity. Comments are not allowed, and expressing repeated resources requires loops that hurt readability. Bicep was created to solve exactly this problem.
Bicep: ARM Templates Made Human-Readable
Think of the difference between a professional chef's technical document (measurements in exact grams) and a home cook's recipe ('a handful,' 'to taste'). The dish produced is identical. That is the ARM Template–Bicep relationship.
Bicep is a DSL (Domain-Specific Language) built on top of ARM Templates. When you write a Bicep file, Azure CLI or Azure Pipelines internally transpiles it to ARM Template JSON before deployment. Key characteristics:
: every Bicep line maps to an ARM Template equivalent. The reverse also works (). Supports comments (, ), shorter syntax, and type safety. The keyword lets you compose reusable Bicep files.
Half the lines for the same resource. In AZ-400 exam scenarios, Bicep is the 'Azure-native IaC choice.' If the team is Azure-only and needs tight ARM ecosystem integration, Bicep is the answer.
Terraform: A Common Language for Multi-Cloud
When traveling across many countries, communicating in one shared language is far more efficient than learning each country's native tongue separately. For an organization running Azure, AWS, and GCP simultaneously, Terraform plays that shared-language role.
Terraform is an open-source IaC tool by HashiCorp, written in HCL (HashiCorp Configuration Language). Core concepts:
: cloud-vendor plug-in (azurerm, aws, google, etc.) that abstracts each vendor's API calls. : a file () recording the current status of all managed resources. Terraform compares declared code against this file to determine what needs changing. : a preview of changes — 'add 5, change 1, destroy 0' — before anything is executed. : executes the actual changes. : stores the state file in Azure Blob Storage or Terraform Cloud instead of locally. Essential for team collaboration.
| Criterion | Bicep | Terraform | |-----------|-------|-----------| | Target cloud | Azure only | Multi-cloud | | Language | DSL (ARM-based) | HCL | | State management | Not needed (ARM handles it) | Required () | | Latest Azure APIs | Immediate support | Requires provider update |
In exam scenarios, 'multi-cloud,' 'HashiCorp,' 'HCL,' or 'tfstate' all point to Terraform.
!Bicep versus Terraform
DSC, Cloud-Init and Ansible: Tools That Manage Inside the OS
If IaC tools are blueprints for 'creating VMs,' configuration management tools govern 'what is installed and configured inside those VMs.' This distinction confuses many exam candidates.
is a PowerShell-based configuration management tool. It declares what software must be installed, which Windows services must be running, and what file-system settings apply inside the VM. Integrated with Azure Automation State Configuration, it monitors a large VM fleet centrally and automatically remediates configuration drift.
is an initialization script that runs the first time a Linux VM boots. Package installations, user creation, and file writes are defined in YAML format. Azure, AWS, and GCP all support Cloud-Init for Linux VMs.
Ansible, Chef, and Puppet also belong to this category:
: agentless — connects to target servers over SSH to apply configuration. : Ruby-based DSL; uses Cookbook and Recipe terminology. : declarative DSL with a Master-Agent architecture.
Key distinction: ARM / Bicep / Terraform handle infrastructure provisioning. DSC / Cloud-Init / Ansible / Chef / Puppet handle OS and software configuration management.
IaC Security Scanning: Catching Vulnerabilities Before Deployment
A fire safety inspection on a finished building costs far more than reviewing evacuation routes at the design stage. IaC security scanning works on the same principle. Before Terraform code or ARM Templates reach Azure, automated tools inside the pipeline detect insecure configurations.
Key tools:
: Python-based static analysis that supports Terraform, ARM, Bicep, Kubernetes, and more. Running scans all IaC files in the current directory in one command. : Terraform-focused static analysis tool aligned with Azure Security Center recommendations.
Positioning IaC scanning before the step in a CI/CD pipeline means code with insecure settings never reaches . This topic connects directly to security pipeline integration covered in the next post.
Exam Key Takeaways
'Azure-native IaC, DSL built on ARM' → Bicep 'Multi-cloud, HCL, tfstate, HashiCorp' → Terraform 'Convert ARM Template to readable syntax' → 'Preview Terraform changes before applying' → 'Store Terraform state for team collaboration' → Remote Backend (Azure Blob Storage or Terraform Cloud) 'Declaratively manage software and services inside a VM' → Azure DSC 'Initialization script on first Linux VM boot' → Cloud-Init 'Agentless configuration management over SSH' → Ansible 'Declarative vs imperative' → ARM / Bicep / Terraform = declarative; Azure CLI scripts = imperative 'IaC static analysis, Terraform vulnerability scanning' → Checkov or tfsec 'Preview ARM Template / Bicep changes before deployment' →
Bicep = Azure-native declarative, Terraform = multi-cloud declarative, DSC = OS configuration management.