Academmia

Infrastructure as code (IaC)

az-900•mixed•

Management and governance

Infrastructure as code (IaC)

Short Summary

Infrastructure as Code (IaC) means defining your cloud infrastructure in machine-readable files instead of setting it up manually in the portal. Those files help you deploy the same environment repeatedly with fewer “surprises” between development, test, and production. In Azure, common IaC options are Azure Resource Manager (ARM) templates (JSON) and Bicep.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define Infrastructure as Code (IaC) in one clear sentence.
  • List the main benefits of IaC (consistency, repeatability, automation, version control).
  • Contrast declarative and imperative approaches at a high level.
  • Identify common Azure IaC tools (ARM templates and Bicep).
  • Explain the difference between Azure Resource Manager (ARM) and the files you deploy (templates/Bicep).

Core Concepts

Infrastructure as Code (IaC) means you describe infrastructure using files (templates/definitions), rather than creating everything manually. When infrastructure lives in files, you can apply the same definition repeatedly and get more consistent results.

Why IaC is useful

IaC is popular because it supports:

  • Consistency: the same definition can create environments that look and behave alike.
  • Repeatability: you can deploy again (or rebuild) without “remembering every click.”
  • Automation: deployments can run as part of a pipeline or scripted process.
  • Version control: because the definition is code, you can review changes, track history, and roll back to a previous version.

Declarative vs imperative (rule of thumb)

You’ll often hear IaC described as declarative:

  • Declarative: you describe the desired end state (what you want deployed).
  • Imperative: you describe the steps to run (how to get there, in order).

Both can automate work, but IaC in Azure is commonly declarative because the file stays reusable as the “source of truth” for what the environment should look like.

ARM vs ARM templates vs Bicep (don’t mix these up)

In Azure, these terms are related but not the same:

  • Azure Resource Manager (ARM) is the deployment and management layer for Azure resources.
  • ARM templates are JSON (JavaScript Object Notation (JSON)) files you write to describe what you want deployed.
  • Bicep is a domain-specific language (DSL) that gives you a cleaner authoring experience and is compiled (transpiled) into JSON ARM templates for deployment.

A simple mental model: ARM is the service; templates/Bicep are the definitions you feed into it.

Practical Understanding

Practical Situation 1: “Dev and prod keep drifting apart”

Your team builds test environments manually and later rebuilds production by repeating the same steps. Over time, small differences appear (a missed setting, different sizes, extra resources).

How to think about it: IaC reduces drift because you deploy from the same definition files each time.

Common misunderstanding: “I’m careful in the portal, so it’s fine.” Manual work is hard to repeat perfectly, especially as the environment grows.

Practical Situation 2: “We want to recreate an environment quickly”

You need a fresh test environment, or you need to rebuild after a failure. You want the new environment to match what you had before.

How to think about it: With IaC, you redeploy from versioned definition files to recreate the environment predictably.

Common misunderstanding: “Automation is the same as IaC.” Automation can exist without a reusable infrastructure definition; IaC is specifically about keeping the infrastructure definition in files you can reuse.

Practical Situation 3: “Someone says IaC is just running scripts”

A teammate describes IaC as “a bunch of commands we run in order,” and assumes that’s the whole idea.

How to think about it: IaC is usually about describing the desired end state, then letting the platform apply that definition. Step-by-step scripts can help, but they don’t automatically give you the same desired-state model and repeatability.

Common misunderstanding: “If it’s automated, it’s IaC.” IaC is about the infrastructure being defined in machine-readable files you can redeploy reliably.

Practical Situation 4: “ARM vs ARM templates vs Bicep gets mixed up”

You hear people use “ARM” to mean the service, the template files, and Bicep all at once.

How to think about it: ARM is the deployment/management layer. Templates and Bicep are the IaC definitions that describe what to deploy.

Common misunderstanding: “ARM templates are ARM.” Templates/Bicep are inputs; ARM is the layer that processes deployments.

Common Pitfalls

  • Mistake: Treating IaC as only step-by-step scripts and command sequences. Correction: IaC focuses on versioned, machine-readable definitions of the desired end state, which improves repeatability.

  • Mistake: Assuming IaC only applies to a single resource type like a virtual machine (VM). Correction: IaC can define whole environments, including networking, storage, and identity-related resources.

  • Mistake: Assuming manual portal setup is “good enough” for multi-environment deployments. Correction: IaC improves consistency and makes it easier to recreate environments and reduce drift.

  • Mistake: Confusing Azure Resource Manager (ARM) with ARM templates or Bicep. Correction: ARM is the deployment layer; templates and Bicep are the IaC definitions you deploy through ARM.

  • Mistake: Memorizing syntax before you understand the goal. Correction: Start with the “why” (consistency, repeatability, version control), then learn just enough syntax to recognize the tools and scenarios.

Check Your Understanding

  • Describe, in your own words, what makes IaC different from doing the same steps manually in the Azure portal.
  • List four benefits of IaC and explain how they work together in a real project.
  • Explain the difference between declarative and imperative approaches using one sentence each.
  • Describe a situation where storing infrastructure definitions in version control would help your team.
  • Explain the “service vs definition” mental model for Azure Resource Manager (ARM) versus ARM templates/Bicep.

Further Reading