This chapter covers ARM (Azure Resource Manager) Templates—Azure's native Infrastructure as Code (IaC) solution. You will learn what ARM templates are, how they work, their key components, and how they compare to other IaC tools. For the AZ-900 exam, this topic falls under 'Azure Management and Governance' (objective 3.4), which typically accounts for about 10-15% of the exam questions. Understanding ARM templates is essential because they are the foundation for automating and standardizing Azure resource deployments, a critical skill for cloud administrators and developers.
Jump to a section
Imagine you are building a custom mansion. You could hand-deliver instructions to each worker: the electrician gets a note about outlets, the plumber gets a sketch of pipes, and the framer gets a verbal description. This is like manually configuring Azure resources through the portal—error-prone, inconsistent, and impossible to replicate exactly. Now, imagine you hire an architect who creates a single, detailed blueprint that specifies every outlet, pipe, beam, and finish. That blueprint is your ARM template. It is a JSON file that declares every resource and its properties. When you hand that blueprint to a construction manager (Azure Resource Manager), they can build the mansion exactly as specified, every time, in any location. If you want a second identical mansion, you just reuse the blueprint. If you need to update a room, you modify the blueprint and the manager makes only the necessary changes. This is Infrastructure as Code: your cloud infrastructure defined in a file, version-controlled, and deployed consistently. ARM templates are that blueprint for Azure resources—declarative, repeatable, and auditable. They eliminate manual configuration drift and enable automated, reliable deployments across environments.
What is Infrastructure as Code (IaC)?
Infrastructure as Code is the practice of managing and provisioning cloud resources through machine-readable definition files, rather than manual configuration or interactive tools. The core idea is to treat infrastructure the same way developers treat application code: store it in version control, review it, test it, and deploy it automatically. IaC brings consistency, repeatability, and auditability to cloud deployments. It eliminates the 'snowflake' problem where each environment (dev, test, prod) is slightly different because someone clicked differently in the portal. With IaC, every environment is built from the same template, ensuring parity.
What are ARM Templates?
An ARM (Azure Resource Manager) template is a JSON (JavaScript Object Notation) file that defines the infrastructure and configuration for your Azure solution. The template uses a declarative syntax: you state what resources you want (e.g., a virtual machine, a storage account, a virtual network) and their properties, and Azure Resource Manager figures out the order and dependencies to create them. You do not write scripts to create resources sequentially; you simply describe the desired end state.
ARM templates are the native IaC tool for Azure. They are deeply integrated with the Azure platform, meaning they can manage any Azure resource that is available through the Resource Manager API. This includes virtually all Azure services: VMs, databases, networking, app services, and more.
How ARM Templates Work: Step-by-Step Mechanism
Authoring: You create a JSON file that contains the template. The file has a specific structure with sections like $schema, contentVersion, parameters, variables, resources, and outputs. You can author templates using any text editor, but Visual Studio Code with the Azure Resource Manager (ARM) Tools extension provides IntelliSense and validation.
Parameters: Instead of hardcoding values (like VM size or admin username), you define parameters. When deploying, you provide values for these parameters via a separate parameter file or inline. This makes the template reusable across environments—e.g., dev uses small VMs, prod uses large VMs.
Variables: You can define variables to simplify expressions and avoid repetition. For example, you might concatenate a naming prefix with a unique string to generate resource names.
Resources: This is the core section where you list all Azure resources to deploy. Each resource has a type (e.g., Microsoft.Compute/virtualMachines), apiVersion, name, location, and properties. The template can also express dependencies between resources using the dependsOn element, though Azure often infers dependencies from property references.
Deployment: You submit the template to Azure Resource Manager via the Azure portal, Azure CLI, Azure PowerShell, or REST API. Resource Manager validates the template, determines the deployment order based on dependencies, and then creates or updates resources in parallel where possible. The deployment is idempotent—running the same template multiple times results in the same configuration (unless you change parameters).
Outputs: After deployment, you can return values like the public IP address or connection string using the outputs section. This is useful for passing information to other automation tools.
Key Components of an ARM Template
$schema: URL pointing to the JSON schema that validates the template structure. For Azure global, it is typically https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#.
contentVersion: A version number for the template itself (not the resources). Use this to track changes in version control.
parameters: Define inputs that users must provide during deployment. Each parameter has a name, type (string, int, bool, object, etc.), and optionally a default value, allowed values, and constraints (e.g., minLength).
variables: Define values that are computed once and reused. For example, "uniqueName": "[concat('myresource', uniqueString(resourceGroup().id))]".
resources: Array of resource definitions. Each resource includes type, apiVersion, name, location, properties, and optional dependsOn, tags, sku, kind, etc.
outputs: Values returned after deployment, such as the resource ID or connection string.
ARM Template Deployment Modes
Incremental (default): Resources defined in the template are added to the resource group. Existing resources not in the template are left unchanged.
Complete: Resources defined in the template are added; resources in the resource group that are not in the template are deleted. This mode is useful for enforcing exactly the resources you want, but it is dangerous if not used carefully because it can delete existing resources.
ARM Templates vs. Other IaC Tools
Terraform: HashiCorp's Terraform is a cloud-agnostic IaC tool that uses its own HCL syntax. It supports multiple providers (Azure, AWS, GCP). ARM templates are Azure-only but have deeper integration, such as native support for Azure policies and role-based access control. Terraform requires managing state files, whereas ARM templates are stateless (Azure Resource Manager tracks the state).
Bicep: Microsoft's domain-specific language (DSL) that compiles to ARM templates. Bicep is simpler and more readable than raw JSON, but it is still ARM under the hood. For AZ-900, you only need to know ARM templates exist; Bicep is not tested.
Azure CLI / PowerShell: These are imperative scripting tools. You write scripts that execute commands sequentially. ARM templates are declarative: you describe the end state, and Azure handles the steps. Imperative scripts are prone to errors if the order is wrong or if resources already exist.
Business Scenarios
Standardized deployments: A company wants to deploy a three-tier application (web, app, database) in dev, test, and prod. An ARM template defines all resources. Each environment uses the same template with different parameter values (e.g., VM size, storage SKU). This ensures environments are identical except for scale.
Disaster recovery: A business needs to replicate its Azure infrastructure to a secondary region. An ARM template can deploy the entire environment in the secondary region with a single command, ensuring consistency.
Compliance: An organization must enforce tagging and specific SKUs. ARM templates can enforce these through parameters and resource definitions, making non-compliant deployments impossible.
Azure Portal and CLI Touchpoints
Portal: You can deploy an ARM template by going to 'Deploy a custom template' in the marketplace or via 'Template deployment (deploy using custom templates)' in the resource group. The portal also allows you to export an existing resource group as an ARM template (though it may need cleanup).
CLI: az deployment group create --resource-group myRG --template-file template.json --parameters parameters.json
PowerShell: New-AzResourceGroupDeployment -ResourceGroupName myRG -TemplateFile template.json -TemplateParameterFile parameters.json
Create the ARM Template JSON File
Start by authoring a JSON file that defines your infrastructure. Use a text editor or VS Code with ARM Tools extension. The file must include the `$schema` and `contentVersion` at minimum. Define parameters for values that change between deployments (e.g., admin username, VM size). Use variables for computed values like unique names. Then list each Azure resource you need in the `resources` array, specifying type, apiVersion, name, location, and properties. For example, to create a storage account, you would use type `Microsoft.Storage/storageAccounts` and set properties like `supportsHttpsTrafficOnly`. Optionally, define outputs for values you need after deployment. Ensure the JSON is valid—use a linter or the ARM Tools extension to catch errors.
Prepare the Parameter File (Optional)
Create a separate JSON file for parameter values if you want to avoid passing them inline. The parameter file has a similar structure: a `$schema`, `contentVersion`, and `parameters` object where each key matches a template parameter, and the value is an object with a `value` property. For example, if your template has a parameter `vmSize`, the parameter file would contain `"vmSize": {"value": "Standard_DS2_v2"}`. Using a parameter file makes deployments more repeatable and easier to automate. You can have multiple parameter files for different environments (dev.parameters.json, prod.parameters.json). If a parameter has a default value in the template, you can omit it from the parameter file.
Validate the Template Locally
Before deploying, validate the template to catch syntax errors and ensure Azure Resource Manager can parse it. Use the Azure CLI command `az deployment group validate --resource-group myRG --template-file template.json --parameters @parameters.json`. This dry-run checks that the template is valid and that all referenced resources and properties exist. It does not actually create resources. Alternatively, you can use `Test-AzResourceGroupDeployment` in PowerShell. Validation is crucial because invalid templates will fail during deployment, wasting time. The validation also checks for missing required properties and incorrect API versions.
Deploy the Template to a Resource Group
Submit the template to Azure Resource Manager using the CLI: `az deployment group create --resource-group myRG --template-file template.json --parameters @parameters.json`. Resource Manager receives the template, validates it again (server-side), determines the deployment order based on dependencies, and then creates or updates resources in parallel where possible. The deployment is asynchronous; you can check status with `az deployment group show`. By default, the deployment mode is Incremental, meaning existing resources not in the template are left unchanged. If you specify `--mode Complete`, resources in the resource group that are not in the template will be deleted—use with caution.
Monitor Deployment and Review Outputs
After initiating the deployment, monitor its progress in the Azure portal under the resource group's 'Deployments' blade or via CLI with `az deployment group list`. The deployment can take seconds to minutes depending on the number and complexity of resources. If the deployment fails, the error message usually indicates which resource and property caused the issue. Common failures include invalid names (e.g., storage account names must be globally unique and lowercase), quota limits, or policy violations. Once successful, check the outputs section to retrieve any values you defined (e.g., connection strings, public IPs). You can also view the deployment's template and parameters for auditing.
Scenario 1: E-Commerce Platform Deployment
A retail company needs to deploy its e-commerce platform across dev, test, and production environments. Each environment requires a web app, a SQL database, and a storage account for static assets. The team creates an ARM template that defines these resources with parameters for environment-specific values: web app SKU, database tier, and storage redundancy. The parameter file for dev uses the Free tier for the web app and Basic for the database; production uses Standard tiers with geo-redundant storage. The template is stored in a Git repository and deployed via Azure DevOps pipelines. This ensures that every environment is identical in configuration, reducing the 'it works on my machine' problem. Common issues: forgetting to change the storage account name (must be globally unique) leads to deployment failures. The team mitigates this by using a variable that concatenates a prefix with a unique string.
Scenario 2: Compliance-Driven Deployment
A financial services firm must ensure all Azure resources have specific tags (e.g., cost center, environment) and use only approved VM sizes. The firm creates an ARM template that hardcodes the required tags in each resource definition and restricts VM SKU to a list of allowed values in a parameter. The parameter file is provided by the compliance team. Developers are not allowed to modify the template—they can only supply parameter values. This enforces compliance at deployment time. If a developer tries to deploy a non-approved VM size, the template validation fails. The firm also uses Azure Policy to audit and enforce compliance, but the ARM template provides a first line of defense. Common mistake: developers try to bypass the template by manually creating resources in the portal, which the firm prevents using Azure Policy to deny creation of resources without required tags.
Scenario 3: Disaster Recovery Replication
A healthcare company runs its critical application in the East US region and needs a disaster recovery site in West US. They have an ARM template that defines the entire application stack, including networking, VMs, and databases. Once a week, they deploy the same template to the West US resource group with different parameters (e.g., smaller VM sizes for DR). In the event of a disaster, they can quickly redeploy the template to West US with production parameters. The template ensures that the DR environment is an exact replica of production, minimizing configuration drift. A common issue is that the template fails because some resources (like public IP addresses) are already in use or because the secondary region has different capacity limits. The team addresses this by using parameters for region-specific values and testing the deployment regularly.
Objective 3.4: Describe Infrastructure as Code (IaC) and ARM Templates
The AZ-900 exam tests your understanding of the *concept* of IaC and the *purpose* of ARM templates, not the ability to write or debug them. Expect 2-4 questions on this topic. Key areas: - Definition of IaC: Managing infrastructure through machine-readable definition files (not manual processes). - Benefits: Consistency, repeatability, version control, reduced configuration drift, automated deployments. - ARM templates: The native IaC tool for Azure; uses declarative JSON syntax. - Comparison to other tools: Know that ARM templates are Azure-specific, while Terraform is cloud-agnostic. Also know that Bicep is a simpler alternative that compiles to ARM templates (but Bicep itself is not tested).
Common Wrong Answers and Why Candidates Choose Them
'ARM templates are used to manage virtual machines only.' Wrong. ARM templates can manage any Azure resource—VMs, databases, networks, app services, etc. Candidates choose this because they associate ARM with VMs due to the name 'Azure Resource Manager'.
'ARM templates use imperative syntax.' Wrong. They use declarative syntax. Candidates confuse ARM with Azure PowerShell or CLI, which are imperative. Remember: declarative = *what* you want; imperative = *how* to do it.
'ARM templates cannot be version-controlled.' Wrong. They are JSON files and can be stored in any version control system like Git. Candidates think they are only used within Azure and cannot be exported. In reality, you can export templates from the portal and store them in Git.
'ARM templates are only for new deployments, not updates.' Wrong. ARM templates support both create and update operations. If a resource already exists, the template updates it to match the defined properties. This is idempotent behavior.
Specific Terms and Values That Appear on the Exam
Declarative syntax: The template describes the desired state, not the steps.
JSON format: ARM templates are written in JSON.
Resource Manager: The service that processes ARM templates.
Parameters and variables: Know the difference: parameters are user-provided inputs; variables are computed within the template.
Incremental vs. Complete deployment modes: Understand that Incremental is default and adds resources; Complete can delete resources not in the template.
Edge Cases and Tricky Distinctions
ARM templates vs. Azure Blueprints: Blueprints are a higher-level service that packages ARM templates along with policies and role assignments for creating entire environments. Blueprints can include multiple ARM templates. The exam may ask which service is best for a complete environment with governance rules.
Export template: The Azure portal allows you to export an existing resource group as an ARM template. However, the exported template may contain hardcoded values and need cleanup before reuse. The exam might test that you can export a template from an existing deployment.
Template spec: A newer feature that allows you to store an ARM template as a resource in Azure, making it shareable and versioned. Not heavily tested but good to know.
Memory Trick for Eliminating Wrong Answers
Use the acronym DRC (Declarative, Repeatable, Consistent). If an answer says ARM templates are imperative, not repeatable, or cause inconsistency, it is wrong. Also, remember that ARM is Azure-only—if an answer claims ARM templates work for AWS or GCP, it is false.
ARM templates are JSON files that define Azure infrastructure declaratively.
Infrastructure as Code (IaC) manages infrastructure through machine-readable definition files, enabling consistency and repeatability.
ARM templates use parameters for user inputs and variables for computed values.
Deployment modes: Incremental (default) adds resources; Complete can delete resources not in the template.
ARM templates can be deployed via portal, CLI, PowerShell, or REST API.
ARM templates are Azure-specific; Terraform is cloud-agnostic.
You can export an existing resource group as an ARM template from the Azure portal.
ARM templates support idempotent deployments: redeploying the same template updates resources to match the desired state.
These come up on the exam all the time. Here's how to tell them apart.
ARM Templates
Azure-native, declarative JSON syntax
No need to manage state files; Azure tracks state
Supports all Azure resources out of the box
Can be exported from existing resource groups
Integrated with Azure Policy and RBAC
Terraform
Cloud-agnostic, uses HCL syntax
Requires state file management (local or remote)
Supports multiple providers (Azure, AWS, GCP, etc.)
No built-in export from existing Azure resources
Separate provider for Azure; may lag behind new Azure features
Mistake
ARM templates are the same as Azure Resource Manager.
Correct
Azure Resource Manager is the management layer that handles all requests to Azure resources. An ARM template is a JSON file that you submit to Resource Manager to deploy resources. Resource Manager is the engine; the template is the instruction set.
Mistake
ARM templates can only be deployed via the Azure portal.
Correct
ARM templates can be deployed via the portal, Azure CLI, Azure PowerShell, REST API, and CI/CD pipelines like Azure DevOps. The portal is just one of many methods.
Mistake
ARM templates require you to specify the order of resource creation.
Correct
ARM templates use declarative syntax. You define resources and their dependencies (via `dependsOn` or implicit references), and Azure Resource Manager determines the correct order. You do not script the sequence.
Mistake
Once deployed, an ARM template cannot be reused.
Correct
ARM templates are designed for reuse. By using parameters and variables, you can deploy the same template to multiple environments (dev, test, prod) with different values. You can also redeploy the same template to update resources.
Mistake
ARM templates are only for new resource creation, not for updating existing resources.
Correct
ARM templates support both creation and update. If you redeploy a template to an existing resource group, resources that already exist are updated to match the template's properties (if they differ). This is called idempotent deployment.
An ARM template is a JSON file that defines the infrastructure and configuration for Azure resources using a declarative syntax. You specify what resources you want (e.g., VMs, databases) and their properties, and Azure Resource Manager handles the deployment. It is Azure's native Infrastructure as Code tool, enabling consistent, repeatable deployments.
ARM templates define a single set of resources. Azure Blueprints are a higher-level service that can include ARM templates, policies, role assignments, and resource groups to create a complete compliant environment. Blueprints orchestrate multiple ARM templates and enforce governance. For AZ-900, know that Blueprints are for full environment governance, while ARM templates are for resource deployment.
Yes. ARM templates support idempotent deployments: if you redeploy a template to an existing resource group, resources that already exist are updated to match the template's defined properties. This allows you to make changes to infrastructure by modifying the template and redeploying.
Incremental mode (default) only adds resources defined in the template; existing resources not in the template remain unchanged. Complete mode also adds resources, but deletes any resources in the resource group that are not defined in the template. Use Complete with caution as it can remove resources accidentally.
No. The AZ-900 exam tests conceptual understanding: what ARM templates are, their benefits, and how they compare to other tools. You do not need to write or debug JSON. Focus on definitions, declarative vs. imperative, and the fact that they are Azure-native.
ARM templates provide consistency (same deployment every time), repeatability (use for multiple environments), version control (store in Git), automation (CI/CD integration), and reduced manual errors. The portal is fine for one-off tasks but error-prone for repeatable deployments.
No. ARM templates are specific to Azure and can only deploy Azure resources. For multi-cloud deployments, you would use a cloud-agnostic tool like Terraform. ARM templates integrate deeply with Azure services like Policy and RBAC.
You've just covered ARM Templates — Infrastructure as Code — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?