Azure ARM Template Validator

An Azure Resource Manager (ARM) template is a JSON file that declaratively defines the Azure resources you want to deploy. The template describes the desired end state, and ARM handles the deployment order, parallel operations, and idempotency. ARM templates support parameters (for reusability), variables (for internal calculations), resources (the infrastructure to deploy), and outputs (values returned after deployment). They're the foundation of Infrastructure as Code on Azure.

The $schema field points to the JSON Schema definition for the template, which enables IDE validation and IntelliSense. Different schemas apply to different deployment scopes: 2019-04-01/deploymentTemplate.json# for resource group deployments (most common), 2018-05-01/subscriptionDeploymentTemplate.json# for subscription-level deployments (policy, RBAC), 2019-08-01/managementGroupDeploymentTemplate.json# for management group deployments, and 2019-08-01/tenantDeploymentTemplate.json# for tenant-level deployments.

Bicep is a domain-specific language (DSL) that compiles to ARM JSON. It offers cleaner syntax (no JSON boilerplate), better type safety, modules for reusability, and a simpler parameter file format. Bicep is now the recommended way to write Azure IaC — the Azure docs increasingly show Bicep first. ARM JSON is still valid and supported but verbose. You can convert existing ARM templates to Bicep with 'az bicep decompile'. Terraform is another popular alternative that supports Azure alongside other clouds.

Parameters with type 'string' are logged in deployment history, Azure Monitor logs, and visible in the Azure Portal. Using 'securestring' tells Azure to never log or display the value — it's treated as a secret throughout the deployment pipeline. Always use securestring for passwords, API keys, connection strings, and certificates. Combine with Azure Key Vault parameter references to avoid passing secrets on the command line at all: ARM can retrieve values directly from Key Vault at deploy time.

Hardcoding a location like 'eastus' makes the template non-portable — it fails if deployed to a subscription with restrictions or a different preferred region. Instead, use '[resourceGroup().location]' to automatically use the resource group's region (most common), or add a 'location' parameter with a default of '[resourceGroup().location]' to allow overrides. This makes the same template deployable to any region without modification.

Outputs return values from a deployment, such as resource IDs, connection strings, storage account keys, or public IP addresses. They're essential for chained deployments (where one template consumes outputs from another), CI/CD pipelines (capturing connection strings for configuration), and cross-resource-group deployments. Common outputs: storage account connection string, Key Vault URI, App Service default hostname. Access outputs with 'az deployment group show --query properties.outputs'.