Infrastructure as Code (IaC) is the practise of managing your cloud environment — servers, databases, networks, and permissions — using human-readable definition files, not manual clicks or ad-hoc scripts. For the AZ-400 exam, IaC is the absolute foundation of modern DevOps, because it turns infrastructure setup from a risky, repetitive chore into a fast, repeatable, and auditable process.
Jump to a section
A simple way to picture Managing Infrastructure as Code Using Azure
Your friend's inherited house in a rainy city. The roof leaks every spring, the basement floods, and the wiring fizzes whenever the kettle boils. For years, the way to fix this was to call a plumber, an electrician, and a roofer separately, watch them each custom-build repairs on the spot, and hope they didn't break each other's work. If the roof fix needed the wiring moved, you'd pay double and wait weeks. Now imagine a different approach: you hire one architect who creates a single master blueprint for the entire house. That blueprint, written in a special language, describes every pipe, wire, and shingle precisely. You keep that blueprint in a shared folder where every tradesperson reads it. When you want a new window, you don't call a carpenter and hope for the best. You update the blueprint, upload the new version, and the architect's special machine automatically orders the glass, re-routes the wiring, and seals the frame. Every change is recorded in the blueprint's history, so if a wall sags, you can see exactly when and why the studs were changed. This is Infrastructure as Code. Instead of manually clicking buttons to set up servers and networks in the cloud, you write a master blueprint — code. The blueprint defines your entire IT environment. You store it in a shared repository, track every edit, and use an engine that reads the blueprint and builds the exact infrastructure described. If you want to change something, you change the code, not the live building. The engine compares your blueprint to what's currently built and makes only the necessary adjustments. No more manual clicking. No more mysterious untracked changes. Just a repeatable, auditable, reliable process.
Imagine you need to set up a new application in Azure. Without IaC, you would log into the Azure portal, click around to create a virtual machine (VM — a simulated computer running in Microsoft's data centre), configure its size, attach a storage disk, set up networking rules, and then manually install software. You would do this once, then pray you remembered every click when you needed a second identical environment for testing. With IaC, you write a single text file — often in a language called Bicep or Terraform — that declares everything: 'I want one VM of size Standard_D2s_v3, with 64 GB of managed disk, connected to virtual network 'app-vnet', with inbound port 443 open.' You store this file in a version control system like Git (think of it as a time-machine for text). When you run a command, a tool like Azure Bicep or Terraform reads your file, compares it to what currently exists in Azure, and makes exactly the changes needed to match your file. If nothing exists, it creates everything. If something is wrong, it fixes it. If you delete a line from your file, it deletes that resource from Azure.
Why does this exist? Because manual configuration is slow, error-prone, and impossible to scale. A single typo in a portal text box can bring down a production system. Worse, nobody can recreate exactly the same environment twice. IaC solves this by treating infrastructure the same way developers treat application code — it becomes testable, reviewable, and shareable.
The core concepts you need to know:
Declarative vs imperative: In a declarative approach (used by Bicep and Terraform), you declare the end state — 'I want five servers.' The tool figures out how to get there. In an imperative approach (old-school scripts), you spell out every step: 'Create server 1, then create server 2...' Declarative is preferred because it is simpler and less error-prone.
Idempotency: A fancy word meaning 'you can run the same IaC file ten times, and the result is exactly the same as running it once.' The tool checks what already exists and only makes changes if something is different. This prevents accidental duplication.
State file: Terraform uses a state file (a snapshot of your current infrastructure) to track what it has already created. Azure Bicep does not need a state file because it queries Azure directly. This is a key difference the exam tests.
Modules: Reusable blocks of IaC code. For example, you can create a 'web-server' module that defines a VM with a public IP and web software. Then you can reuse that module twenty times without rewriting it. Modules are like function calls in programming.
Source control: IaC files must be stored in Git or similar. Every change is tracked. You can roll back to a previous version if a deployment breaks. This is non-negotiable in DevOps.
Real example in plain language: Suppose you are deploying a simple web app on Azure. Your IaC file might contain:
A resource group (a logical container for all related resources).
An App Service plan (the pricing tier for your web app).
A web app (the actual application).
A database (Azure SQL Database).
A firewall rule (to allow only your app to talk to the database).
Running the IaC file once creates all five resources in the correct order, with the correct dependencies. If you need a second environment for testing, you run the same file in a different resource group. If you need to add a caching layer (like Azure Redis), you edit the IaC file, re-run it, and the caching layer is added without touching the existing resources.
The exam expects you to know the main tools: Azure Resource Manager (ARM) templates (JSON-based, the original Azure IaC), Bicep (a cleaner, easier-to-read language that compiles to ARM templates), and Terraform (a cloud-agnostic tool from HashiCorp). You will also see Azure Blueprints and Azure DevOps pipelines that deploy IaC automatically.
Author the IaC definition file
You write a Bicep or ARM template file that declares every Azure resource you need: virtual networks, VMs, databases, firewall rules, etc. This file acts as the single source of truth for your infrastructure.
Store the file in source control
You commit the IaC file to a Git repository (like Azure Repos or GitHub). This gives you version history, collaboration through pull requests, and the ability to roll back to a previous configuration if something goes wrong.
Define environment parameters
You create a parameter file (e.g., parameters.json) that holds environment-specific values like VM size, region, or admin password. This keeps your main IaC file reusable for dev, test, and production without code duplication.
Run the deployment
You execute a command — for example, `az deployment group create --resource-group my-rg --template-file main.bicep` — or trigger an Azure Pipeline. The tool reads your definition, compares it to the current Azure state, and creates or updates resources to match.
Review and validate the output
After deployment, you verify that resources are created correctly. You can run the deployment again with the same file to confirm idempotency — the tool should report 'No changes' the second time if nothing was altered elsewhere.
Iterate through code review and updates
When a developer requests a change (e.g., add a caching layer), you edit the IaC file, commit the change, and re-deploy. The tool automatically adjusts only the affected resources, leaving everything else intact.
You are a platform engineer at a mid-sized e-commerce company. The business runs a customer-facing web application plus a back-end order processing system. Both run on Azure. The head of engineering has just announced a new feature that requires three new environments: one for development, one for testing, and one for staging (a near-production replica for final checks). Your old process — manually clicking through the Azure portal for each environment — took two days per environment, and the last time you did it, someone forgot to enable the firewall, exposing the database to the internet for 24 hours.
Using IaC, your workflow changes completely:
You start by writing a Bicep file that defines the entire application architecture. It includes an Azure Kubernetes Service (AKS) cluster for the web app (this is a managed container orchestration service), an Azure SQL Database, a virtual network with subnets, and a Log Analytics workspace for monitoring. You wrap reusable parts into modules: one module for the AKS cluster, one for the database, one for networking.
You commit the Bicep file to an Azure DevOps Git repository. This is a version-controlled location where your team can see every change.
You create an Azure DevOps pipeline (a YAML file that defines automated steps) that deploys the Bicep file. The pipeline has a parameter called 'environment' that accepts values like 'dev', 'test', or 'staging'. The same Bicep file runs in three different Azure resource groups, with different size VMs for each environment to save money.
A developer asks for a change: they need an additional caching layer using Azure Cache for Redis. You update the Bicep file to include the Redis resource, commit the change, and the pipeline automatically deploys it to all three environments. No manual setup. No configuration drift.
When a security audit comes, the auditor asks: 'Show me exactly what infrastructure was running on March 15th.' You point to the Git commit history. Every resource change is recorded in the Bicep file. The auditor sees that on March 14th, a firewall rule was added, and on March 16th, it was removed. The audit is complete in minutes, not weeks.
The company decides to move to a multi-region architecture for disaster recovery. Instead of manually rebuilding everything in a second Azure region, you extract your Bicep modules, parameterise the region, and deploy the same IaC in West Europe. The tool handles regional differences — for example, a VM size that is unavailable in one region causes the deployment to fail gracefully with an error message, not a silent corruption.
This is the daily reality of an IT professional using IaC. You spend more time writing and reviewing code than clicking buttons. You catch errors early in code review, before they reach production. You sleep better knowing that rolling back a bad change is one Git revert away.
The AZ-400 exam tests IaC heavily across multiple question formats: multiple-choice, multiple-select, and case studies. Expect 10–15 questions on this topic. The exam writers love to trap candidates on the following specifics:
ARM templates vs Bicep vs Terraform: Know the exact differences. ARM templates are JSON and verbose. Bicep is a domain-specific language that compiles to ARM templates — it is easier to read and write. Terraform is cloud-agnostic (works with AWS and GCP too) and uses its own state file. The exam will ask which tool to use for a specific scenario, like 'You need to manage resources across Azure and AWS. Which tool?' Answer: Terraform. 'You want a native Azure experience with simpler syntax.' Answer: Bicep.
State file management: Terraform stores state in a local file by default, but that is dangerous (you could lose it or overwrite it). The exam expects you to know that state should be stored remotely, e.g., in an Azure Storage Account with locking enabled to prevent concurrent changes. Bicep does not use a state file — it queries Azure's Resource Manager directly to determine current state. This is a frequent trick question.
Azure Blueprints: This is not the same as IaC. Blueprints are for compliance and governance — they package role assignments, policies, and resource groups into a repeatable blueprint. IaC (Bicep, ARM templates, Terraform) is for deploying the actual resources. The exam will give you a scenario about 'setting a compliance standard across all subscriptions' — that's Blueprints, not IaC.
Desired State Configuration (DSC): DSC configures the operating system inside a VM after it is deployed (e.g., install IIS, enable specific Windows features). IaC deploys the VM itself. The exam will ask: 'You need to ensure every VM has the same set of Windows features.' Answer: Use DSC, not IaC. Many candidates confuse the two.
Parameter files: In ARM templates and Bicep, you use parameter files to pass environment-specific values (e.g., VM size for dev vs production). The exam asks why you should not hard-code values in the template — answer: hard-coding prevents reusability and forces manual changes per environment.
Deployment modes: ARM templates support Incremental (default) and Complete modes. Incremental adds resources and updates existing ones but does not delete resources not in the template. Complete mode deletes resources that are not in the template. The exam tests which mode to choose for a scenario — for example, 'You want to ensure orphaned resources are removed.' Answer: Complete mode. But Complete mode only applies to the resource group, not across subscriptions. This is a trap.
Nested and linked templates: ARM templates can be split into linked templates (separate files) for modularity. The exam tests how to reference linked templates using a URI, including SAS tokens for secure access when the templates are stored in a private storage account.
PowerShell and CLI deployment: You should know the command to deploy an ARM template: New-AzResourceGroupDeployment (PowerShell) and az deployment group create (CLI). For Bicep: az deployment group create --template-file main.bicep.
Escape hatches: In Bicep, when you need to do something not natively supported, you can use the existing keyword to reference existing resources, or use a resource-scoped loop with @batchSize to control deployment speed. The exam tests whether you know these advanced patterns exist.
Common traps: A question will say 'You need to deploy 50 identical VMs. Should you use IaC or Azure DevOps pipeline loops?' The answer is IaC with a resource loop (for in Bicep). The pipeline would handle code compilation and deployment, not the resource creation itself. Another trap: 'You need to deploy infrastructure and then run a configuration script on the VM.' The correct approach is to use a deployment script resource or a VM extension, not to add the script as a separate step in the pipeline without dependencies.
Infrastructure as Code (IaC) means writing human-readable definition files that describe your entire Azure environment, then using a tool to automatically create and update those resources.
The three main IaC tools for Azure are ARM templates (JSON), Bicep (simpler language that compiles to ARM), and Terraform (cloud-agnostic, uses its own state file).
IaC is idempotent: running the same definition file multiple times produces the same result, because the tool checks current state before making changes.
Never hard-code environment-specific values in IaC files; always use parameters or variables to keep your code reusable across development, testing, and production.
Terraform uses a state file to track existing infrastructure, while Bicep queries Azure's Resource Manager directly — a critical difference the AZ-400 exam tests.
Configuration drift happens when someone manually changes a resource in the Azure portal after IaC deployment; the only safe fix is to update the IaC file and re-deploy.
These come up on the exam all the time. Here's how to tell them apart.
ARM Templates
Written in JSON format, which is verbose and hard to read
Does not support modular structure natively — you must use linked templates
Directly deployed as-is by Azure Resource Manager
Bicep
Written in a clean, domain-specific language that reads like shorthand configuration
Supports native modules for reusing groups of resources across files
Compiles into ARM templates before deployment; adds abstraction
Bicep
Azure-specific — only works with Azure resources
No state file required — queries Azure Resource Manager directly for current state
Simpler to learn for Azure-only shops; tight integration with Azure portal
Terraform
Cloud-agnostic — works with Azure, AWS, GCP, and others
Uses a state file to track resources; state must be stored remotely and locked
More complex to set up but valuable for multi-cloud environments
IaC (Bicep / Terraform)
Deploys and manages Azure resources: VMs, networks, databases
Operates at the cloud resource level, not the OS level
Idempotency means re-running produces the same cloud infrastructure
Desired State Configuration (DSC)
Configures the operating system inside a VM after deployment: install software, set registry keys
Operates at the OS level (Windows or Linux) inside the VM
Idempotent at the OS level — ensures the VM's internal state matches the config
Incremental Deployment Mode (ARM)
Default mode for ARM template deployments
Adds new resources and updates existing ones
Does NOT delete any resources, even if they are missing from the template
Complete Deployment Mode (ARM)
Requires explicit opt-in with property `mode: Complete`
Adds, updates, and deletes resources to match the template exactly
Deletes any resource in the resource group that is not defined in the template
Mistake
IaC is only for large enterprises with many servers.
Correct
IaC benefits projects of any size. Even a single VM is better defined in code because it is reproducible, auditable, and can be recreated in minutes after a failure.
Beginners often think IaC is overkill because they have only ever set up a few resources manually. They do not yet understand the cost of manual errors and time spent rebuilding after a mistake.
Mistake
ARM templates and Bicep are the same thing, just different file extensions.
Correct
ARM templates are JSON files. Bicep is a separate, cleaner language that compiles into ARM templates. Bicep is not just a syntax variation of ARM templates — it is a completely different authoring experience with modules, symbolic names, and simpler syntax.
Because Bicep ultimately generates ARM templates, beginners assume they are interchangeable. They are not; Bicep adds abstraction and reduces boilerplate.
Mistake
Once you deploy IaC, you cannot make manual changes to the Azure resources.
Correct
You can make manual changes, but doing so creates 'configuration drift' — the real environment differs from the code. The next IaC deployment will either overwrite your manual change or fail if conflicts exist. The best practise is to never make manual changes and to always update the code.
Beginners hear 'infrastructure as code' and think it locks everything down. In reality, Azure does not prevent manual edits; it just makes them risky. People make manual changes out of convenience, then wonder why the next deployment breaks.
Mistake
IaC is only about creating new resources, not destroying them.
Correct
IaC is equally about destroying resources. When you remove a resource definition from your IaC file and re-deploy, the tool deletes that resource (unless you use protective mechanisms like resource locks). Proper IaC includes lifecycle management — creation, update, and deletion.
Most beginners focus on creation because that is the first thing they do. They do not think about the need to tear down test environments or clean up unused resources until they get a surprise bill.
Mistake
You need to be a developer or know programming languages like Python to use IaC.
Correct
Bicep and ARM templates are declarative — you say what you want, not how to achieve it. No programming logic (if/then, loops) is required for basic use. Advanced scenarios use loops and conditions, but they are simple to learn.
The word 'code' scares non-programmers. They assume it requires software engineering skills. In reality, IaC uses domain-specific languages designed for infrastructure, not general-purpose programming.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
ARM templates are JSON files that define Azure resources. Bicep is a newer, simpler language that compiles into ARM templates. Bicep is easier to read and write because it uses less boilerplate and supports modules natively.
No. You can deploy IaC directly from your local machine using the Azure CLI or PowerShell. However, Azure DevOps Pipelines are recommended for automation, collaboration, and consistent deployment across environments.
Yes. Terraform is a cloud-agnostic IaC tool that works with Azure, AWS, and GCP. It uses its own state file to track resources. Azure supports Terraform natively, and the AZ-400 exam includes Terraform questions.
That creates 'configuration drift'. The next time you deploy your IaC file, the tool will either overwrite the manual change (if it detects a difference) or fail with an error. The fix is to update the IaC file to reflect the desired state and re-deploy.
No. Azure Blueprints is for governance and compliance — it packages role assignments, policies, and resource groups. IaC (Bicep, ARM templates, Terraform) is for deploying actual resources. They are complementary but serve different purposes.
A state file is a JSON document that Terraform uses to track the current state of your infrastructure. It maps the resources in your IaC file to real resources in Azure. It should be stored remotely (e.g., in an Azure Storage Account) and locked to prevent corruption.
You've finished Managing Infrastructure as Code Using Azure. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?