Azure Resource Manager (ARM) templates let you define your infrastructure as code and deploy it consistently across environments. If you are still clicking through the Azure portal to provision resources, this is worth your time.
An ARM template is a JSON file that declares the Azure resources you want to deploy and their configuration. You describe the desired end state and Azure figures out how to get there. The template is idempotent: run it once, run it ten times, you get the same result.
Microsoft introduced ARM in 2014 as the replacement for the older Azure Service Management API. Every resource you create in Azure, from a VM to a storage account to an App Service, has an ARM representation. Templates are how you automate that at scale.
Every ARM template has the same top-level structure. The $schema field tells tooling which version of the template language you are using. contentVersion is a free-form string for your own versioning. parameters are inputs that let you customise a deployment. variables compute values you reuse across the template. resources is the array of things you actually want to deploy. outputs return values after deployment completes.
In my day‑to‑day work the VS Code ARM Tools extension is the first line of defense. It flags schema mismatches and warns about deprecated apiVersion values before the CI run. I also run the ARM‑TTK test kit as part of every pull request; on a recent micro‑service rollout it caught a missing location property that would have caused a 30‑minute deployment rollback in production.
A practical example of deploying a storage account shows the resource block looks like this: { "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2023-01-01", "name": "[parameters('storageAccountName')]",
"location": "[resourceGroup().location]", "sku": { "name": "Standard_LRS" }, "kind": "StorageV2" }
The [parameters()] and [resourceGroup()] syntax are ARM template functions. They evaluate at deploy time. ARM has around 50 built-in functions covering string manipulation, array operations, resource references, and conditionals.
When you start nesting deployments to break a monolith into reusable modules, the execution time can explode. In a production pipeline that stitched together ten nested templates, the overall deployment stretched from 4 minutes to over 12 minutes, and we hit the 60‑minute timeout on a nightly run. The fix was to flatten the most volatile resources into a single template and move static infra into separate incremental deployments.
Hard‑coding values in templates defeats the purpose. Parameters let you pass in environment‑specific values at deploy time. You define a parameter with a type, optional default, and optional allowed values list. Then you pass actual values using a separate parameters file.
This pattern means one template works across dev, staging, and production. The template defines the shape of your infrastructure. The parameters file defines the specifics for each environment. Keep templates in source control. Keep parameters files in source control. Never hard‑code secrets: use Azure Key Vault references in parameter files to pull secrets at deploy time.
In practice I never embed a Key Vault secret ID directly; I use a managed identity on the deployment service principal and let the template call the reference() function. That way secret rotation is transparent and we avoided a 2‑hour outage when a credential expired because the pipeline was still pointing at an old version.
The simplest way to deploy a template is using the Azure CLI: az deployment group create --resource-group myRG --template-file main.json --parameters @dev.parameters.json. This validates the template before deploying. If there is a syntax error or an invalid resource property, it tells you before any resources are created.
ARM templates vs Bicep: Bicep is a domain-specific language that compiles to ARM JSON. It has cleaner syntax, better type safety, and much less verbosity. If you are starting fresh in 2024, Bicep is the way to go. ARM JSON is still the underlying format and everything here applies conceptually to Bicep.
For teams on Terraform, the same infrastructure-as-code principles apply. ARM templates and Bicep are Azure-native. Terraform is cloud-agnostic. Pick what fits your organisation's existing toolchain.