What is Infrastructure as Code on Azure

Infrastructure as Code (IaC) is the practice of managing and provisioning cloud resources through machine-readable configuration files rather than manual processes such as clicking through the Azure Portal. On Azure, IaC enables you to define virtual machines, networks, databases, and every other resource in a declarative or imperative format that can be version-controlled, reviewed, tested, and reused.

---

Why Infrastructure as Code?

The Problem with Manual Provisioning

Imagine you need to deploy a web application to Azure. You open the Azure Portal, create a resource group, provision an App Service Plan, deploy a Web App, configure a SQL Database, set up networking rules, and wire everything together. It works — but then you need to do it again for staging, and again for production, and again in a second region.

Manual provisioning leads to:

• Configuration drift — subtle differences between environments that cause unexpected bugs
• Inconsistency — no guarantee that staging matches production
• Slow recovery — rebuilding infrastructure after a failure requires remembering every step
• Lack of audit trail — no record of who changed what and when
• Knowledge silos — only the person who clicked the buttons knows the configuration

The IaC Solution

With IaC, you describe your infrastructure in files. Those files become the single source of truth:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "mystorageaccount",
      "location": "[resourceGroup().location]",
      "sku": { "name": "Standard_LRS" },
      "kind": "StorageV2"
    }
  ]
}

This JSON file is an ARM template — Azure's native IaC format. It declares a storage account. You can deploy it with a single command, store it in Git, and reproduce the exact same resource every time.

---

Declarative vs Imperative IaC

Approach	You describe...	Azure examples
Declarative	The desired end state	ARM templates, Bicep, Terraform
Imperative	The exact steps to execute	Azure CLI scripts, Azure PowerShell scripts

Declarative Example (Bicep)

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

You state what you want. Azure Resource Manager figures out how to create or update it.

Imperative Example (Azure CLI)

az storage account create \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --location uksouth \
  --sku Standard_LRS \
  --kind StorageV2

You tell Azure the exact command to run. If the storage account already exists, you may need additional logic to handle updates.

Best practice: Prefer declarative IaC for production infrastructure. Imperative scripts are useful for one-off tasks and automation glue.

---

IaC Tools on Azure

Azure supports a rich ecosystem of IaC tools:

Tool	Type	Language	Maintained by
ARM templates	Declarative	JSON	Microsoft
Bicep	Declarative	Bicep DSL	Microsoft
Terraform	Declarative	HCL	HashiCorp
Pulumi	Declarative	TypeScript, Python, Go, C#	Pulumi
Azure CLI	Imperative	Bash	Microsoft
Azure PowerShell	Imperative	PowerShell	Microsoft
Ansible	Imperative/Declarative	YAML	Red Hat

In this course, we focus on ARM templates, Bicep, and Terraform on Azure — the three most widely used declarative IaC tools in the Azure ecosystem.

---

Benefits of IaC on Azure

1. Repeatability

Deploy the same template to dev, staging, and production with identical configurations.

2. Version Control

Store templates in Git. Review changes through pull requests. Roll back to a previous version if something breaks.

3. Automation

Integrate deployments into CI/CD pipelines using Azure DevOps, GitHub Actions, or any other CI system.

4. Compliance and Governance

Use Azure Policy and template validation to enforce organisational standards before resources are created.

5. Cost Management

Define resource SKUs, sizes, and auto-scaling rules in code. Destroy entire environments when they are no longer needed.

6. Disaster Recovery

If a region fails, redeploy the same templates to another region within minutes.

---

How Azure Resource Manager Enables IaC

All IaC tools on Azure ultimately interact with Azure Resource Manager (ARM) — the deployment and management service that processes API requests. Whether you use the Azure Portal, Azure CLI, Bicep, or Terraform, every operation passes through ARM.

User / Tool  →  ARM API  →  Resource Provider  →  Azure Resource

ARM provides:

• Consistent management layer — all tools use the same API
• Idempotent deployments — deploying the same template twice produces the same result
• Dependency resolution — ARM deploys resources in the correct order
• Rollback capabilities — failed deployments can be rolled back
• Role-based access control (RBAC) — fine-grained permissions for who can deploy what

---

A Simple IaC Workflow on Azure

1. Write — author your template (ARM JSON, Bicep, or Terraform HCL)
2. Validate — run syntax and linting checks locally
3. Plan / What-If — preview what changes will be made
4. Deploy — apply the template to an Azure subscription
5. Verify — confirm resources are created and configured correctly
6. Iterate — modify templates, review changes, and redeploy

---

Summary

Infrastructure as Code transforms Azure resource management from a manual, error-prone process into a repeatable, version-controlled, and automated discipline. Azure supports multiple IaC tools — ARM templates, Bicep, Terraform, and more — all of which interact with Azure Resource Manager. In the following lessons, we will explore ARM in detail, learn template syntax, and progress to Bicep and Terraform on Azure.