Skip to article
Management and Governance Infrastructure as code

Template spec

A template spec stores an ARM template or Bicep deployment artifact as a versioned Azure resource.

Source: Microsoft Learn - Azure Resource Manager template specs Reviewed 2026-05-27

Exam trap
Granting broad contributor access and letting teams overwrite trusted infrastructure patterns without platform review.
Production check
Run az ts list and confirm the expected spec name, owner tags, and resource group placement.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Template spec, template spec, Azure Template spec, ARM Template spec, Azure template spec, Microsoft.Resources/templateSpecs
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-27
Review level
field-manual-complete
Article depth
field-manual-complete
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A template spec is a reusable infrastructure package stored inside Azure. Instead of emailing an ARM template, publishing it from a storage account, or asking teams to copy files from a repository, you publish the template as an Azure resource. Other users can deploy it when they have the right Azure RBAC permissions. Template specs are useful when a platform team wants to offer approved building blocks, such as a network baseline, logging setup, or secure storage account pattern, without giving every consumer permission to edit the source template.

Why it matters

Template specs matter because they solve a common platform problem: how to share approved infrastructure code without letting every team fork, edit, or lose the current version. Storage-account URLs and SAS tokens are awkward for governance, and local copies drift quickly. A template spec gives the template an Azure resource identity, RBAC boundary, deployment history, and version list. Consumers can deploy a known pattern while platform owners retain control over updates. This improves security, consistency, auditability, and onboarding speed. It also makes infrastructure libraries easier to integrate into pipelines because deployments can reference a stable resource ID instead of a fragile file path.

Official wording and source

A template spec is an Azure resource that stores an ARM template, including linked templates, for later deployment. It lets platform teams share approved infrastructure templates through Azure RBAC, version them, and deploy them with standard tools such as Azure CLI, PowerShell, portal, REST, or SDKs.

Open Microsoft Learn

Technical context

Template specs are Microsoft.Resources/templateSpecs resources stored in resource groups and available through Azure Resource Manager. A template spec contains a main ARM template and can package linked templates. It supports versions, RBAC, tags, location metadata, and deployment through standard ARM clients. Architecturally, it sits between infrastructure source control and deployment execution: the platform publishes a reviewed artifact, consumers deploy a version by resource ID, and ARM applies the template at resource group, subscription, management group, or tenant scope. It is a control-plane sharing and governance mechanism.

Exam context

Compare with

ARM template Bicep

Where it is used

Where you see it

  1. In the Azure portal, template specs appear as resources in a resource group with versions, descriptions, tags, access control, and deployment options. during operational review
  2. In Azure CLI, az ts list and az ts show display template spec names, locations, resource IDs, versions, descriptions, and metadata used by pipelines. during operational review
  3. In deployment commands or ARM links, a template spec appears as a Microsoft.Resources/templateSpecs resource ID with a versions segment identifying the deployable artifact.

Common situations

  • Publish approved landing-zone or workload modules so application teams deploy standards without cloning platform repositories.
  • Replace storage-account template links and SAS tokens with RBAC-protected Azure resources that are safer to share.
  • Give pipelines a stable resource ID for a reviewed template package instead of a mutable branch path.
  • Distribute secure baseline patterns for diagnostics, tagging, networking, or storage while limiting who can edit them.
  • Export and inspect a deployed template version during audits, incident reviews, or rollback planning.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Insurer publishes approved network templates safely Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A property insurer needed every application team to deploy the same hub-connected spoke network pattern. Teams were copying old templates from chat threads, creating inconsistent NSGs and missing diagnostics.

Goals
  • Publish one approved network baseline for application teams.
  • Limit template modification rights to the platform pipeline.
  • Cut onboarding time for new application spokes by at least 60%.
  • Provide auditors with evidence of which baseline version was deployed.
Approach using Template spec

The platform team moved the reviewed ARM template into a template spec stored in a dedicated resource group. Only the CI service principal and two platform owners received contributor access; application teams received Template Spec Reader. Each release created a new version with a description referencing the source commit. Deployment pipelines used the template spec version resource ID rather than a Git branch or storage URI. The spec required parameters for address space, environment, owner tag, and diagnostic workspace. Operators used az ts show and az ts export during audits to prove the published content matched the approved network standard.

Potential outcomes
  • Application spoke onboarding dropped from 11 days to 3 days.
  • NSG rule drift in new spokes fell from 23 findings per quarter to 2.
  • Audit evidence collection for network baselines dropped from 16 hours to 2 hours.
  • No application team had permission to alter the published template content.
What to learn

Template specs help platform teams distribute trusted infrastructure patterns while keeping publishing control separate from deployment rights.

Scenario 02 University standardizes research lab deployments Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A university cloud center supported research labs that needed storage, managed identities, budgets, and diagnostic settings. Every lab had different Azure skills, so copied templates produced security gaps.

Goals
  • Give labs a self-service deployment path for approved research environments.
  • Keep identity, diagnostic, and tagging standards consistent.
  • Reduce platform engineer involvement in routine lab setup.
  • Retain versioned evidence for grant and data-handling reviews.
Approach using Template spec

The cloud center published a research-environment template spec with versions for standard lab, sensitive-data lab, and GPU-prep variants. Researchers had read access to deploy the appropriate version but could not change the template. The spec accepted parameters for grant ID, data classification, lab owner, and region. It deployed storage accounts with required tags, diagnostic settings, and managed identities, then returned outputs for onboarding documentation. Platform engineers published updates only after validation and a pilot deployment. Older versions stayed available for active grants until their workloads migrated.

Potential outcomes
  • Routine lab setup effort fell from 12 engineer-hours to 90 minutes.
  • New research environments reached 98% tag and diagnostic compliance.
  • Grant review packets included template spec version IDs for every sampled lab.
  • Sensitive-data labs stopped deploying from unreviewed local template copies.
What to learn

A template spec is useful when less-specialized teams need repeatable infrastructure but the platform team must protect the standard.

Scenario 03 Manufacturer replaces SAS-linked deployment templates Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A global manufacturer stored deployment templates in a private storage account and shared SAS URLs with factory IT teams. Tokens expired during maintenance windows, and old URLs kept deploying obsolete monitoring settings.

Goals
  • Remove SAS URL dependency from factory deployment pipelines.
  • Publish approved monitoring and backup patterns as Azure resources.
  • Reduce failed maintenance-window deployments caused by expired links.
  • Make obsolete patterns visible and retire them deliberately.
Approach using Template spec

The infrastructure group published each factory baseline as a template spec. Pipelines were changed to deploy by template spec resource ID, while RBAC gave factory teams reader rights only. Version descriptions included the approved change record and minimum supported region list. The team used az ts list to find outdated specs, az ts show to verify active versions, and az ts export for quarterly review. New releases were validated against a pilot factory subscription before publishing broadly. Retirement notices were attached to old version descriptions and tracked in the operations calendar.

Potential outcomes
  • Expired-link deployment failures dropped from nine in one quarter to zero.
  • Factory monitoring baseline adoption rose from 64% to 96% in five months.
  • Quarterly review time fell by 70% because versions were listed centrally.
  • Three obsolete backup patterns were retired without breaking active pipelines.
What to learn

Template specs replace brittle template sharing with RBAC-protected, versioned Azure artifacts that fit real deployment operations.

Azure CLI

As an Azure engineer, I prefer CLI for template specs because the useful work is inventory, publishing, version inspection, and pipeline integration. The portal is fine for browsing, but CLI gives repeatable az ts create, list, show, export, update, and delete operations with the exact resource group, version, and template file. I can publish the same artifact from CI, capture the resource ID, assign RBAC, and deploy that version in another pipeline. CLI also makes it easier to audit which versions exist, export one for review, and prevent teams from using an unapproved template copy. That evidence is easier to trust than screenshots.

Useful for

  • Create a template spec from a reviewed Bicep or ARM file during a release pipeline.
  • List template specs by resource group to inventory approved deployment patterns.
  • Show a specific template spec version and capture its resource ID for downstream deployments.
  • Export a version to compare published content with the source repository during an audit.
  • Delete or update obsolete versions only after confirming no active pipelines reference them.

Before you run a command

  • Confirm the publishing subscription, resource group, location, and naming convention for shared template specs.
  • Verify you have Template Spec Contributor or equivalent rights before creating, updating, or deleting a spec or version.
  • Validate the source template first, because az ts create packages content but does not make bad architecture safe.
  • Check template size and linked template structure so the package does not hit template spec size limits.
  • Confirm RBAC assignments for deployers separately from permissions required to create the resources inside the template.

What the output tells you

  • az ts create output confirms the template spec name, version, location, ID, tags, and published metadata.
  • az ts list shows whether a resource group contains the expected shared templates or old versions that need cleanup.
  • az ts show with a version confirms the exact resource ID consumers should use in deployment commands.
  • az ts export writes the stored artifact to disk so reviewers can inspect the template actually published in Azure.
  • Delete and update output should be treated as change evidence because consumers may depend on existing versions.

Mapped commands

Template spec publishing and deployment commands

direct 
az ts create --resource-group <resource-group> --name <template-spec-name> --version <version> --location <region> --template-file main.bicep --version-description "<release-notes>"
az tsprovisionManagement and Governance
mutating Microsoft Learn 
az ts list --resource-group <resource-group> --name <template-spec-name> --output table
az tsdiscoverManagement and Governance
read-only Microsoft Learn 
az ts show --resource-group <resource-group> --name <template-spec-name> --version <version> --output json
az tsdiscoverManagement and Governance
read-only Microsoft Learn 
az ts export --resource-group <resource-group> --name <template-spec-name> --version <version> --output-folder <folder>
az tsoperateManagement and Governance
read-only Microsoft Learn 
az deployment group create --resource-group <resource-group> --template-spec <template-spec-version-resource-id> --parameters @main.bicepparam
az deployment groupsecureManagement and Governance
mutating Microsoft Learn

Architecture context

In a well-run Azure platform, template specs act like a governed infrastructure catalog. Source code still belongs in Git, tests still run in CI, and Bicep may still be the authoring language. The template spec is the published, deployable artifact that consumers reference. I use it for patterns that many teams need but should not reinvent: policy-compliant storage, network spokes, diagnostic settings, and application landing-zone components. RBAC separates publishers from deployers. Versioning separates stable releases from experimental changes. The architecture should define who can publish, who can deploy, how versions are named, and how retirement works. This keeps the catalog useful instead of ceremonial.

Security
Security impact is direct because a template spec controls who can read, deploy, update, or delete an approved infrastructure template. Azure RBAC is the main boundary: Template Spec Reader can deploy a version, while contributors can change the artifact. A weak contributor assignment lets someone publish insecure firewall, identity, or logging settings under a trusted name. Template contents should not contain secrets, SAS tokens, or environment-specific confidential values. Use secure parameters and Key Vault references for sensitive inputs. Monitor changes to template spec versions, restrict publishing to trusted pipelines, and review any template that creates role assignments or public endpoints.
Cost
Template specs have no major compute meter, but they can indirectly drive significant spend through the resources they deploy. A shared pattern that defaults to premium storage, zone redundancy, high log retention, or large compute can multiply across many teams. Template spec sprawl also creates operational cost when dozens of near-duplicate patterns must be reviewed and patched. FinOps ownership should review template content before publishing, require tags, document SKU defaults, and monitor adoption. Keep template specs grouped by lifecycle and retire unused versions so teams do not deploy obsolete, expensive patterns because they are still visible. Review Template spec behavior with production-like inputs before release.
Reliability
Reliability improves when consumers deploy stable, reviewed versions instead of copying templates. A template spec can reduce drift across teams and make rollback clearer because the deployed resource ID includes a version. Reliability still depends on version discipline. Updating or deleting a version that pipelines rely on can break releases. Publishing an oversized or poorly tested template can fail at scale. Reliable operations keep old versions available during transition, test deployments in representative scopes, document compatibility notes, and avoid bundling unrelated resources with different lifecycles. Treat a template spec like a release artifact, not a scratchpad. Version availability should be part of release readiness.
Performance
Template specs do not affect application runtime performance directly. Their performance impact is architectural and operational: they accelerate deployment by giving teams a tested artifact, and they can standardize performance-related settings such as SKU, capacity, caching, storage type, and diagnostics. Poorly designed specs can slow deployments if they package too many unrelated resources, linked templates, or optional branches. They can also propagate underpowered settings everywhere. Review template size, module boundaries, and default capacity before publishing. Use what-if and representative test deployments to confirm the spec produces resources that meet latency, throughput, and scale expectations. Review Template spec behavior with production-like inputs before release.
Operations
Operators manage template specs by publishing versions, listing available artifacts, checking RBAC, exporting versions for review, tagging ownership, and documenting consumer guidance. Day-to-day tasks include confirming which version a pipeline deployed, comparing exported content to source control, retiring outdated versions, and investigating failed deployments that reference a template spec ID. Operational runbooks should include naming conventions, resource group placement, version retention, approval workflow, and rollback rules. Because consumers may not see the source repository, descriptions and version notes need to be clear. Audit template spec changes alongside deployment and policy evidence. That keeps consumers from guessing during incidents. Release evidence keeps Template spec operations review practical for operators.

Common mistakes

  • Granting broad contributor access and letting teams overwrite trusted infrastructure patterns without platform review.
  • Publishing secrets, tenant-specific values, or environment-specific IDs inside a shared template spec.
  • Deleting old versions before confirming release pipelines and rollback plans no longer reference them.
  • Treating a template spec as source control instead of publishing it from reviewed repository content.
  • Bundling resources with unrelated lifecycles, making every consumer accept more infrastructure than they need.