Azure Template Specs

Azure Template Specs are a resource type (Microsoft.Resources/templateSpecs) that allows you to store ARM templates as versioned, immutable artifacts within Azure. Introduced in 2020, they solve the problem of managing ARM templates outside Azure—in GitHub, storage accounts, or as files—by providing a built-in, governed registry. Each Template Spec can contain one or more versions, and each version is immutable once created (you cannot modify it, only create a new version). This immutability ensures that deployments using a specific version always use the exact same template, eliminating drift.

Before Template Specs, teams had to manage ARM templates in external repositories or storage accounts. This led to several problems: - Versioning chaos: Different teams might use different versions of the same template, leading to inconsistent deployments. - Permission sprawl: You had to manage access to storage accounts or Git repos separately from Azure RBAC. - Governance gaps: No built-in way to enforce that only approved templates are used. - Audit difficulty: Tracking which template version was used for a deployment required manual logging.

Template Specs address these by integrating templates directly into Azure Resource Manager, leveraging Azure RBAC for access control, and providing native versioning.

When you create a Template Spec, you define it in a specific Azure region and resource group. The Template Spec resource itself is a container for versions. Each version is a separate sub-resource that contains the ARM template JSON (or Bicep file) and any linked templates. The version is identified by a semantic version string (e.g., "1.0.0").

Internally, Template Specs are stored in Azure Resource Manager's backend, which replicates the data within the region. When you deploy a Template Spec, Azure Resource Manager reads the template from the spec, validates it, and executes the deployment. The deployment is tracked in Azure Activity Log, which records the Template Spec resource ID and version used.

You can manage Template Specs using the Azure portal, Azure CLI, Azure PowerShell, or ARM API. Below are the key commands:

Create a Template Spec (Azure CLI):

# Create the Template Spec resource (container)
az ts create \
  --name MyTemplateSpec \
  --resource-group MyResourceGroup \
  --location eastus \
  --display-name "My Template Spec" \
  --description "This is a template spec for web app deployment"

# Create a version from a local ARM template file
az ts version create \
  --name MyTemplateSpec \
  --resource-group MyResourceGroup \
  --version "1.0.0" \
  --template-file azuredeploy.json

Deploy a Template Spec:

az deployment group create \
  --resource-group TargetResourceGroup \
  --template-spec "/subscriptions/{sub-id}/resourceGroups/MyResourceGroup/providers/Microsoft.Resources/templateSpecs/MyTemplateSpec/versions/1.0.0" \
  --parameters "{...}"

List versions:

az ts version list --name MyTemplateSpec --resource-group MyResourceGroup

Delete a version:

az ts version delete --name MyTemplateSpec --resource-group MyResourceGroup --version "1.0.0"

PowerShell equivalents:

# Create Template Spec
New-AzTemplateSpec -Name MyTemplateSpec -ResourceGroupName MyResourceGroup -Location eastus

# Add version
New-AzTemplateSpecVersion -ResourceGroupName MyResourceGroup -TemplateSpecName MyTemplateSpec -Version "1.0.0" -TemplateFile azuredeploy.json

# Deploy
New-AzResourceGroupDeployment -ResourceGroupName TargetResourceGroup -TemplateSpecId "/subscriptions/.../versions/1.0.0"

Template Specs integrate with: - Azure Policy: You can enforce that deployments must use only approved Template Specs via Azure Policy. For example, deny deployments that do not reference a specific Template Spec. - Azure Blueprints: Blueprints can reference Template Specs as artifacts, allowing you to include governed templates in a blueprint definition. - Bicep: Bicep files can be published as Template Specs using the bicep build command to generate ARM JSON, then publishing that JSON. Bicep also supports deploying a module directly from a Template Spec. - Azure DevOps: In CI/CD pipelines, you can use the AzureResourceManagerTemplateDeployment task to deploy a Template Spec version. - Azure Resource Manager: Template Specs are a first-class resource, meaning you can manage them through ARM, use tags, and apply locks.

When you deploy a Template Spec, Azure Resource Manager performs these steps: 1. Authentication: The user or service principal must have Microsoft.Resources/templateSpecs/read on the Template Spec version, and Microsoft.Resources/deployments/write on the target resource group. 2. Template retrieval: ARM reads the template JSON from the Template Spec version. If the template includes linked templates, those are retrieved from the packaged .zip file. 3. Validation: The template is validated for syntax, resource types, and parameter requirements. 4. Deployment execution: ARM processes the template, creating or updating resources as defined. 5. Audit logging: The deployment is logged in Activity Log with the Template Spec resource ID and version.

Because versions are immutable, you should plan a versioning strategy. Common approaches: - Semantic versioning: Major.Minor.Patch (e.g., 2.1.0). Major changes for breaking changes, minor for new features, patch for fixes. - Date-based: e.g., 2024.01.15. Useful for compliance. - Sequential: e.g., v1, v2. Simple but less informative.

You can also use tags (like "latest") by creating a version with that name, but it's not recommended because tags are not immutable.

On the AZ-104 exam, you may be asked to:

A large enterprise with multiple development teams uses Template Specs to enforce standardized infrastructure. The cloud center of excellence (CCoE) publishes approved ARM templates for common workloads (e.g., web apps, VMs, databases) as Template Specs in a central resource group. Each team has Reader access to the specs and Contributor access to their own resource groups. When a team needs to deploy a web app, they use the approved spec version 2.1.0. This ensures all web apps follow security baselines (e.g., mandatory NSG rules, encryption). If a team tries to deploy a custom template, Azure Policy denies it unless it references an approved Template Spec. The CCoE updates the spec to version 2.2.0 with new compliance requirements; teams slowly migrate by changing their deployment scripts to reference the new version. This prevents drift and reduces audit findings. Performance is not an issue because Template Specs are lightweight; the bottleneck is the deployment itself. Misconfiguration occurs when teams are granted too broad permissions (e.g., Contributor on the spec resource group), allowing them to create their own versions, defeating governance.

A financial services company uses Template Specs to store disaster recovery (DR) templates. They have two Azure regions: primary (East US) and DR (West US). They create identical Template Specs in both regions, each containing the same versions. In the primary region, they deploy the spec version 1.0.0 to production. For DR, they have a runbook that deploys the same spec version from the West US spec. Because Template Specs are regional, they must manually synchronize versions between regions. They use Azure DevOps pipelines to publish new versions to both regions simultaneously. A common mistake is assuming Template Specs are geo-replicated—they are not. During a regional outage, if the primary spec is unavailable, the DR region spec must be created beforehand. They also use Azure Policy to ensure that all deployments use the spec from the correct region based on the deployment location.

A healthcare organization needs to prove that all deployments use approved templates. They use Template Specs exclusively and disable the ability to deploy raw ARM templates via Azure Policy (deny deployment if templateLink is not a Template Spec). Each deployment is logged with the spec version. Auditors can query Activity Log to see which version was used for each resource group. The organization uses a versioning scheme like YYYY.MM.DD.REV (e.g., 2024.03.15.2). When a compliance update is required, they publish a new version and update policy to require the latest version. This ensures all new deployments use the updated template. A common pitfall is forgetting to update existing deployments—the policy only affects new deployments, not existing ones. They must also ensure that the Template Specs themselves are backed up, as they are not automatically replicated.