Writing ARM Templates

ARM templates let you define Azure infrastructure as code in JSON format. This enables repeatable, consistent deployments that can be version-controlled alongside your application code. Templates are idempotent — running the same template multiple times produces the same result, making them safe to re-apply after changes.

Every ARM template starts with a $schema property pointing to the template schema URL, followed by a contentVersion string. The schema tells the Azure portal and editor extensions how to validate and provide IntelliSense for your template. The five main sections that follow are parameters, variables, functions, resources, and outputs.

Parameters make templates reusable by accepting inputs at deployment time. Each parameter has a type (string, int, bool, object, array, secureString), an optional defaultValue, and optional allowedValues for validation. Using secureString for passwords ensures the value is never logged in deployment history.

Variables store values computed from parameters or template functions, reducing repetition and making templates easier to maintain. Variables are evaluated once and referenced throughout the resources section using the [variables('name')] expression. A common pattern is building a resource name by concatenating a parameter with a unique suffix.

The resources array is the heart of an ARM template. Each element describes one Azure resource with mandatory fields: type, apiVersion, name, and location. The apiVersion pins the resource provider schema version — always use a recent stable version to access the latest features and avoid deprecated properties.

ARM template expressions are wrapped in square brackets [...] and support built-in functions for strings, arrays, objects, and resource IDs. Common functions include concat(), resourceGroup(), resourceId(), uniqueString(), and parameters(). These functions are evaluated server-side by ARM at deployment time, not locally.

The outputs section defines values ARM returns after a successful deployment. Outputs are essential for chaining templates — you deploy a network template and output the subnet resource ID, then pass it as a parameter to a VM template. Outputs can reference any expression, including resource properties from the deployment.

For complex architectures, ARM supports linked templates (referencing external template URLs) and nested templates (embedding a template inside the resources array using type Microsoft.Resources/deployments). This lets you break a large infrastructure deployment into modular, reusable pieces while keeping a single orchestration template as the entry point.

Instead of passing parameters on the command line, store them in a separate parameters file — a JSON file with a parameters object containing name-value pairs. Parameters files can be environment-specific (e.g., dev.parameters.json, prod.parameters.json) and committed to source control, keeping sensitive values in Azure Key Vault references rather than plain text.

Use the Azure CLI command az deployment group create to deploy a template to a resource group. Before deploying to production, run az deployment group validate to catch schema and logic errors, and az deployment group what-if to preview resource changes. These three commands form a safe deployment pipeline: validate, preview, deploy.

Follow these ARM template best practices: use parameters for environment-specific values, use variables to avoid repetition, pin API versions to stable versions, use secureString for passwords, add metadata descriptions to parameters, and separate large templates into linked modules. Store templates in a Git repository and deploy them through a CI/CD pipeline for auditability.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: ARM templates are JSON documents that declaratively define Azure infrastructure, parameters and variables make templates reusable and maintainable, and the validate, what-if, deploy workflow enables safe, repeatable deployments. Next up we explore Bicep, a modern abstraction over ARM JSON.