Module 7: Provisioning Infrastructure (IaC)

"Clicking around the Azure portal to create resources doesn't scale. Infrastructure as code makes your cloud repeatable, reviewable, and reliable."

Level: Beginner · Time: ~3 days · Prerequisites: Module 5

Learning Objectives

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

• Explain what infrastructure as code (IaC) is
• Understand how azd uses Bicep to provision resources
• Read a simple Bicep file
• Run and re-run azd provision safely

1. Infrastructure as Code

Infrastructure as code (IaC) means describing your cloud resources — servers, databases, storage — in text files instead of clicking through a portal. Those files live in version control, get reviewed like any code, and produce the same environment every time.

It also makes change reviewable: a teammate can read a pull request and see exactly which resources will appear, resize, or disappear before anything touches the live cloud. Nothing happens by surprise, and every change has an author and a date in the Git history.

2. Bicep: Azure's IaC Language

azd uses Bicep, a clean, readable language for defining Azure resources. A snippet that creates a storage account:

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

You declare what you want; Bicep and Azure figure out how to make it so. Under the hood Bicep compiles to ARM (Azure Resource Manager) templates — the JSON that Azure ultimately consumes — but it's far easier to read and write. Related resources can be grouped into reusable modules, so even large infrastructures stay organized.

3. How azd Provisions

When you run:

azd provision

azd reads the Bicep in your infra/ folder and asks Azure to make reality match it. New resources get created; unchanged ones are left alone. azd up runs this automatically before deploying your code.

azd first makes sure a resource group exists to hold everything, then submits the Bicep as a single deployment. Azure works out the correct order — a database before the app that depends on it — so you never have to script the sequence yourself.

4. Declarative and Idempotent

Bicep is declarative — you describe the desired end state, not step-by-step instructions. It's also idempotent: run it once or ten times and you get the same result. Change one value, re-run, and only that difference is applied.

This is why re-running azd up after a small edit is safe: Azure compares your Bicep to what already exists and applies only the delta, instead of tearing everything down and rebuilding from scratch.

5. Why This Matters

IaC is what makes azd's "one command, whole environment" promise real. Because your infrastructure is code, you can review it in pull requests, roll it out to multiple environments, and rebuild it from scratch if disaster strikes — all with confidence it'll be identical.

✅ Checkpoint

1. What is infrastructure as code?
2. What language does azd use to define Azure resources?
3. What does "idempotent" mean for provisioning?

Answers: 1) Describing cloud resources in version-controlled text files instead of clicking a portal. 2) Bicep. 3) Running it repeatedly produces the same result; only real differences get applied.

Further Learning

• What is Bicep?
• azd infrastructure guide

Part of "AZD for Beginners." Adapted from Microsoft's open AZD curriculum (MIT License).