Managed Templates: the Template Library¶
Managed Templates (XMT) is a library of ready-made, tested infrastructure modules in Terraform and Bicep. Workload teams use them to build their resources in a spoke in a way that follows the standards of the platform, without having to keep up with every policy and baseline themselves. The library also contains an IaC Accelerator: a working example project that shows how to structure your code, call the modules and deploy with a pipeline.
This section serves two readers. Workload teams find how to use the library in Use Managed Templates, the module catalogue and the IaC Accelerator. The people who maintain the library find how it is built, tested and released.
An optional offering, separate from the platform
The template library is not part of the core MCP hub and spoke code, and it has its own repository, pipelines, tests and versions. Whether your platform has it, who maintains it and how the modules are delivered to you is set by your platform team (Operating models). The pages describe how the library is built in its reference form. Your library may differ.
What the library is¶
| Property | What it means |
|---|---|
| A module per Azure resource type | Each module wraps one resource type (for example a storage account or a Key Vault), with the settings a workload team needs. Some Terraform modules are patterns that combine several modules. See the module catalogue. |
| Built on Azure Verified Modules | The modules call the Azure Verified Modules (AVM) of Microsoft and pass on their parameters and outputs. The library adds the platform's standards on top. A few modules own their resource logic (see the catalogue). |
| Policy-compliant by design | Values that an Azure Policy checks are fixed in the module, so that a team cannot deploy a resource that breaks the baseline. The target baselines are CIS Microsoft Azure Foundations Benchmark 2.0, ISO 27001:2013 and the Microsoft cloud security benchmark. See Policy compliance. |
| Tested | Every module is deployed in a test subscription and checked against the Azure policies of the platform. See Testing. |
| Versioned per module | A team pins the version of each module and decides when to upgrade. See Versioning. |
| Documented | The reference of each module (parameters, outputs) is generated from the code. See Release and documentation. |
| Terraform and Bicep | Both technologies live in one repository and one product, in separate folders. |
| Maintained | The library is tested on every change and on a weekly schedule, and the modules are updated when the baselines or the upstream modules change. |
Who does what¶
The library has a maintaining team and consuming teams. Who fills which role depends on the operating model of your platform (Operating models).
| Role | Under a managed-service contract | When self-managed |
|---|---|---|
| Maintaining team: builds, tests, versions and releases the modules, and delivers them to the consumer | XMMS | The team of the customer that owns the library |
| XMT Ambassador: arranges access and onboarding on the consumer side, and is the first contact for questions | A person of the customer | A person of the customer platform team |
| Workload team: calls the modules in its own code, pins versions, deploys through a pipeline | The workload team | The workload team |
The workload team stays responsible for its own infrastructure code and for deploying it. A module reduces the policy work, but it is not a guarantee that a workload is compliant (Responsibilities).
What is in this section¶
| Page | Content |
|---|---|
| Use Managed Templates | Reference a module, get access in a pipeline, choose and upgrade versions |
| Module catalogue | All modules by service, with what they deploy and whether they exist in Terraform and Bicep |
| IaC Accelerator | The ready-to-copy example project with structure, pipeline and automated dependency updates |
| Policy compliance | How modules enforce policies, and the findings you can still see in Azure Policy |
| Set up access (XMT Ambassador) | The one-time setup and the access management on the consumer side |
| Repository structure | The folders of the repository and what each one holds |
| Testing | The test approach: integration tests, Azure Policy compliance, shared resources |
| Pipelines and scripts | The pipelines and the helper scripts of the repository |
| Versioning | Module-level semantic versioning, the changelog and upgrade notes |
| Release and documentation | Release process, generated documentation, delivery to consumers |
| Create and contribute modules | Create a new module, fixes of upstream modules, contribution guide |
| Decision summaries | The decisions behind the design, in short |
How it fits the platform¶
flowchart LR
avm["Azure Verified Modules (upstream)"] --> xmt["Managed Templates library"]
pol["Azure Policy of the platform"] --> xmt
xmt -->|"versioned releases"| ws["Workload team code in a spoke"]
acc["IaC Accelerator (example project)"] -.->|"copy and adapt"| ws
ws --> spoke["Spoke (baseline of the platform)"]The modules assume the baseline of a spoke: private connectivity, the policies on the management groups, and the shared resources. They are a way to comply, not a way around the policies. A resource that a module cannot create in a compliant way is a reason to extend the module, or to request an exemption (Policy exemptions).