Deploying Azure as code: infrastructure as code, Azure Resource Manager and ARM templates

Why this matters

An environment built by hand is a one-off. The person who built it remembers most of the settings, the portal remembers some, and nobody can rebuild it exactly when it breaks or when a second copy is needed for testing. Over time the test environment drifts from production, and a bug that only appears in production becomes impossible to reproduce. Infrastructure as code fixes this by writing the environment down in files that a machine can build from, again and again, the same way each time.

A manager needs this idea because it changes how teams work: changes become reviewed, recorded and repeatable, and a full environment can exist only for the hours it is needed. A salesperson will hear "can we automate our deployments?" from almost every technical buyer. A junior administrator needs to know that Azure Resource Manager sits behind every tool they use, which explains why permissions, locks and policies apply the same way everywhere. This lesson covers both the idea and Azure's own way of doing it.

The lesson

Infrastructure as code

Infrastructure as code (IaC) means describing infrastructure, such as networks, virtual machines, databases and their settings, in definition files rather than building it by hand in the portal. A tool reads the files and creates the resources. Because the definition is just text, it can be handled like application code.

The benefits follow from that:

• Consistency. The same file builds the same environment every time. Development, test and production come out alike, apart from the differences you deliberately choose.
• Repeatability on demand. Environments can be recreated whenever needed. A pipeline can build a full test environment each night, run automated tests and delete it afterwards, so the company pays only while the environment exists.
• Version control. The files live in source control, so every change is reviewed, recorded and can be rolled back. You can see who changed a firewall rule and why.
• Speed and fewer mistakes. Nobody clicks through forms, so nobody forgets a step.

What IaC does not do is equally testable. It does not remove the need for access control, it does not make resources free, and it does not guarantee that resources never fail. It also is not the same as lift-and-shift migration, which moves existing workloads to the cloud largely unchanged and says nothing about how new environments are defined.

Declarative and imperative. There are two styles of IaC, and the exam expects you to tell them apart.

• Imperative: you write the steps. A PowerShell or Azure CLI script that runs one command to create a network, then another to create a virtual machine, is imperative. It says how to reach the result, step by step and in order.
• Declarative: you describe the end state, and the platform works out how to get there. You say "there should be a network and a virtual machine in it, with these settings", and the tool decides the steps and their order.

ARM templates, Bicep and Terraform are declarative. Scripts are imperative.

Azure Resource Manager and ARM templates

Azure Resource Manager (ARM) is Azure's deployment and management service. Every request to create, update or delete an Azure resource passes through it, whichever tool sent it: the Azure portal, the Azure CLI, Azure PowerShell, the REST API or an SDK. Because there is one front door, behaviour is consistent across all of them.

When a request arrives, Resource Manager:

1. authenticates the caller, using the identity that Microsoft Entra ID provides (lesson 10);
2. authorises the request by checking Azure RBAC permissions (lesson 11), the same checks for a CLI request as for a portal click;
3. passes the request to the Azure service that does the work.

Microsoft Entra ID supplies the identity, but it does not create or change resources itself; Resource Manager does. Nor does any user gain Owner rights simply by signing in.

Resource Manager also gives you features that work across every resource type:

• Manage a solution as a group. The resources that make up an application can be deployed, managed and deleted together, usually through a resource group (lesson 6), rather than one at a time.
• Organisation and governance. Tags (lesson 12), resource locks and Azure Policy (lesson 13) and RBAC are all applied through Resource Manager.
• Dependencies. It understands which resources depend on others and deploys them in the right order.

Resource Manager does not move resources to cheaper regions or copy them to a paired region for recovery. Replication comes from features such as geo-redundant storage or Azure Site Recovery. And Resource Manager works in Azure; it is Azure Arc (lesson 14) that extends the same management layer to servers and clusters outside Azure.

ARM templates are Azure's native IaC files. An ARM template is a JSON (JavaScript Object Notation) file that declares the resources to deploy and their properties. It is not YAML, XML or HTML. Keep the two terms apart: ARM is the service; a template is a file that the service reads and deploys.

A template has a small number of sections:

• parameters: values supplied at deployment time, such as a virtual machine size or a region;
• variables: values worked out inside the template and reused;
• resources: the resources to create and their settings;
• outputs: values returned after deployment, such as an address.

The properties of ARM templates that the exam probes:

• Declarative syntax. You describe what the finished environment contains, and Resource Manager decides the steps.
• Idempotent. Deploying the same template twice to the same resource group gives the same result. The second run does not create duplicates, does not fail because the resources already exist, and does not delete and re-create them. The resources simply stay in the state the template describes.
• Validated first. Resource Manager validates the template before it deploys anything, so a template with validation errors is rejected before any resource is created.
• Orchestration. You submit the template once, and Resource Manager orchestrates the whole deployment as one operation. If a virtual machine must sit in a virtual network, the template declares that the machine depends on the network, and Resource Manager builds the network first. Resources that do not depend on each other are created in parallel, which makes deployment faster. Nothing is created in alphabetical order, and no one approves each step.
• Parameters for each environment. One template can serve development, test and production, each with its own virtual machine size, by supplying different parameter values. Copying the template for each environment works, but the copies drift apart. Tags only label resources; they do not change their configuration.
• Modular. A large template that has become hard to maintain can be split into smaller linked or nested templates, which are combined at deployment and reused across projects.
• Broad coverage. Templates cover almost every Azure resource type, not only virtual machines, and a parameterised template works in any region.
• Many ways to deploy. A template can be deployed from the portal, the Azure CLI, Azure PowerShell or a CI/CD pipeline. Cloud Shell is one option, not a requirement.
• Export. If someone built a resource group by hand in the portal and wants to reproduce it in another subscription, the quickest start is to export a template from the existing resources and adjust it. Azure Migrate does not do this; it moves on-premises workloads into Azure.
• Deployment history. The portal keeps a history of deployments for each resource group and subscription, showing which template ran, when, with which parameter values, and whether it succeeded.

Bicep is a simpler language for the same job. It is a domain-specific language with cleaner syntax than JSON. A Bicep file is compiled into ARM template JSON and deployed by Resource Manager in the usual way. Bicep is not a separate deployment engine and does not replace Resource Manager, so Bicep files and JSON templates get exactly the same deployment features.

Other tools. Azure does not insist on its own formats. Terraform, a popular third-party IaC tool, has a provider for Azure that calls the Resource Manager APIs. A company that already uses Terraform elsewhere can define Azure infrastructure the same way, without converting anything to Bicep. Whatever the tool, the request still ends up at Resource Manager.

What the exam is really asking

• IaC benefits. Consistent, repeatable environments and changes tracked in version control. Not free resources, not "no access control", not "never fails".
• Declarative vs imperative. A template describes the end state; a script lists the steps. A sequence of commands is imperative even when it is saved in a file.
• Resource Manager vs a template. Resource Manager is the service behind every request; a template is a JSON file it deploys. Swapping the two is a common distractor.
• One front door. Portal, CLI, PowerShell, REST and SDK requests all go through Resource Manager, which checks RBAC every time.
• Idempotent, validated, orchestrated. Redeploying gives the same state; errors are caught before anything is built; dependencies set the order and independent resources go in parallel.
• Parameters and modules. Parameters let one template serve many environments; linked templates break up a large one.
• Bicep. A friendlier language that compiles to ARM JSON, not a new engine.
• Resource Manager vs Arc. Resource Manager manages Azure; Arc extends it beyond Azure.