Infrastructure as code for beginners: what it is and how it works on Azure

The first time you build something in the cloud, you click. You open the portal, fill in forms, press Create, and a network appears. It works. Then someone asks you to build the exact same thing again in a second environment — and you realize you can't remember half the boxes you ticked. That gap is the whole reason infrastructure as code exists.

New to cloud? CAMPUX is a free, build-first course. Start here →

Here is the plain definition. Infrastructure as code means describing the cloud resources you want in text files, and letting a tool read those files and build the resources for you — instead of clicking through the portal by hand. The file says "I want a virtual network with this address range, a virtual machine of this size, and a storage account with these settings." A tool reads it and makes the cloud match. Microsoft puts it this way: infrastructure as code "uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure," and "just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys."

That last sentence is the point. The portal is a series of one-time actions you can't easily repeat. A file is a permanent, exact recipe you can run as many times as you like.

Why clicking through the portal stops working

Clicking is fine for one thing, once. It falls apart the moment you need the same setup twice, or need three people to agree on what "the setup" even is. Microsoft has a good name for what goes wrong: environment drift. Without infrastructure as code, each environment gets tuned by hand over time until it becomes what they bluntly call a "snowflake" — a unique configuration nobody can reproduce automatically. Your test environment and your production environment slowly diverge, and one day something breaks in production that worked fine in test, and nobody can say why. This is the origin of the dreaded "well, it worked on my subscription."

When the setup lives in a file instead, the whole class of problem disappears. A few things you get more or less for free:

• Repeatable. Deploy the same file into a new subscription and you get the same environment, down to the setting. No forgotten checkboxes.
• Reviewable. A change to your infrastructure is now a change to a file. A teammate can read the diff and catch the mistake before it hits production, the same way they review application code.
• Version-controlled. The file goes in Git. You can see who changed what, when, and why — and roll back to last week's known-good version if a change goes wrong.

The portal remembers nothing. A file remembers everything, exactly, forever.

The mental model: describe the end state, not the steps

The idea that makes this click for beginners is declarative. You describe the end state you want, and the tool figures out how to get there. You do not write "create the network, then wait, then create the VM, then attach it." You write "I want a network and a VM attached to it," and the tool works out the order and the steps.

The opposite approach — writing out every step in sequence — is called imperative, and it is the thing you are trying to avoid. Declarative files are shorter, and they survive being run more than once. That property has a name worth knowing: idempotent. Microsoft's own phrasing is that an idempotent deployment means "you can deploy the same file many times and get the same resource types in the same state." Run it against an empty subscription and it builds everything. Run it again against a subscription that already matches, and it changes nothing. The file describes the destination; the tool is responsible for getting reality there, whatever state reality started in.

How this works specifically on Azure

Azure has a clean story here, and it is worth learning the three pieces by name.

First, the engine. Every deployment in Azure goes through Azure Resource Manager (ARM) — the service that receives your desired configuration and creates the resources, in the right order, in parallel where it can. You never really bypass it; everything eventually talks to Resource Manager.

Second, the original file format. You can hand Resource Manager a template written in JSON — an ARM template. It works, but JSON is verbose and full of bracketed expressions, and it gets painful to read fast. (If you want the longer version, here is what an ARM template is.)

Third, the readable language most people learn today: Bicep. Microsoft describes Bicep as "a domain-specific language that uses declarative syntax to deploy Azure resources," and the key detail for a beginner is how it relates to the JSON. Bicep is "a transparent abstraction over a Resource Manager JSON template" — you write the clean, concise Bicep, and during deployment the tool converts your file into an ARM JSON template that Resource Manager runs. Same engine, same result, far friendlier to write. Anything valid in an ARM template is valid in Bicep, and Bicep supports every Azure resource type the day it ships.

Why this is the skill to show first

If you are trying to prove you can operate in the cloud, nothing signals it faster than handing someone a file that builds a working environment. It shows you think in repeatable systems, not one-off clicks. It shows you understand review, version control, and rollback — the habits that separate a hobbyist from someone you'd trust with production. And it is genuinely learnable early: because declarative tools like Bicep are not general programming languages, Microsoft notes they don't "require prior knowledge of programming languages." You describe what you want; you don't write algorithms. Reading and editing structured text and using Git is a much lower bar than learning to code, and it pays off immediately.

The takeaway

Infrastructure as code is describing your cloud in files instead of clicking it into being — so it becomes repeatable, reviewable, and version-controlled, and your environments stop drifting into snowflakes. On Azure, Resource Manager is the engine, ARM templates are the original JSON format, Bicep is the readable language that compiles down to that JSON, and Terraform is the multi-cloud alternative. Learn to write one small Bicep file that builds a resource group and a storage account, run it twice, and watch the second run change nothing. The moment that clicks, you've stopped clicking — and that is the whole job changing under you for the better.

Questions people also ask

What is infrastructure as code in simple terms?

It is describing your cloud resources in text files instead of clicking through the portal by hand. You write down what you want — a network, a virtual machine, a database — in a file, and a tool reads that file and makes the cloud match it. The file becomes the source of truth, and you deploy it as many times as you need to get the same result.

Is Bicep infrastructure as code?

Yes. Bicep is Microsoft's domain-specific language for describing Azure resources in a declarative way. You state the resources and properties you want, and the Bicep tooling converts your file into an Azure Resource Manager template that Azure then deploys. It is one of the two native ways to do infrastructure as code on Azure, the other being raw ARM JSON templates.

What is the difference between ARM templates and Bicep?

They deploy the same things through the same engine, but ARM templates are written in verbose JSON with bracketed expressions, while Bicep is a cleaner language that reads far more easily. During deployment the Bicep tool converts your file into an ARM JSON template, so Bicep is a friendlier front end over the same underlying format. Anything valid in ARM is valid in Bicep.

What problem does infrastructure as code solve?

It solves environment drift — the slow slide where each environment becomes a unique, hand-tuned snowflake that nobody can reproduce. When the setup lives in a file under version control, every environment is built from the same description, changes are reviewed like any other code, and you never again hear that something worked on one subscription but not another.

Do I need to know how to code to use infrastructure as code?

No. Declarative tools like Bicep are not general programming languages — you describe the end state you want rather than writing step-by-step logic. Microsoft notes that Bicep does not require prior knowledge of programming languages. You do need to get comfortable reading and editing structured text files and using version control, but that is a much lower bar than learning to program.