infrastructure-as-code

Infrastructure as Code (IaC)

What it is

Infrastructure as Code (IaC) is the practice of defining and managing infrastructure in machine-readable files, rather than relying only on portal clicks or one-off commands. Teams place those files under version control and use tools such as Bicep, ARM templates, or terraform to create and update infrastructure in a repeatable way.

Why it exists

Portal work can be useful for learning and diagnosis, but it is hard to reproduce exactly. IaC gives infrastructure a change history, review process, validation opportunity, reusable modules, and more consistent deployments across development, test, and production. A provisioning-pipeline can apply the reviewed definition.

Key ideas

• Declarative IaC: you describe the desired resources and properties rather than writing every creation step. Bicep is Azure’s declarative language and compiles to an ARM template.
• Repeatable does not mean harmless: deploying the same valid Bicep file repeatedly aims for the same declared state. A changed template, deployment mode, provider behavior, or parameter can still update or delete resources. Review changes before production deployment.
• Versioned & reviewed: definitions live in git; changes go through pull requests and code review.
• Environments from the same source: one definition parametrized by environment (dev/stage/prod) gives parity and removes environment drift at deploy time.
• Preview and review: use a change preview such as Bicep/ARM what-if, peer review, and environment-appropriate validation. A preview helps expose create, update, and delete operations; it is not a substitute for testing.
• Separate concerns: IaC can provision infrastructure. Application release strategies such as blue/green or canary deployment and practices such as immutable infrastructure need their own design.

Northwind example

Northwind keeps a Bicep definition for the ordering application’s resource group, storage account, and monitoring settings. Luis proposes a pull request that changes a network rule. The team reviews the diff and what-if output, deploys to a test environment, then promotes the approved change. The Bicep file gives them a repeatable description; it does not automatically make the network rule correct or remove the need to protect secrets in pipeline configuration.

How it fits (diagram)

IaC definition → review and validation → deployment pipeline → Azure Resource Manager → Azure resources
                       ↑                         │
                     what-if                     └─ records deployment result

Exam notes

• IaC = the umbrella term; Bicep/ARM templates are Azure-native, terraform is cross-cloud.
• Core contrast: imperative scripts describe steps; declarative templates describe the intended resources and properties.
• Always review a production deployment’s proposed changes, especially when a template or mode can remove resources.
• IaC is a pillar of the AZ-400 value stream: source control → CI → IaC → releases.

Related

bicep · arm-template · terraform · desired-state · configuration-drift · immutable-infrastructure · provisioning-pipeline

📘 Source: Microsoft Learn — What is Bicep?