How do I use Azure Verified Modules with my landing zone accelerator pipelines?

November 13, 2026 4 answers
Asked by Mipsy

I've deployed a test environment with the Azure Landing Zone Accelerator bootstrap and Azure DevOps pipelines. How do I add Azure Verified Modules to that deployment process, and where should I look for guidance?

Answers

!tilt+the~clipboard

First, check what the accelerator generated. The platform landing zone deployment may already use Azure Verified Modules pattern modules, so there might not be a separate integration step to perform.

Look through the generated Terraform or Bicep for module references, including avm/ptn/alz references. That will tell you which modules and versions your particular deployment uses. If you mean deploying workload resources into an application landing zone, that's a separate question from how the platform landing zones were built.

++shuffle!the~agenda:

Checking the generated code is useful here because the exact module references can depend on the accelerator and version you used.

Reply to this answer
v28.Pivot

For workload resources, start with a small deployment using an AVM resource module in your Terraform or Bicep code, then run it through an Azure DevOps pipeline. The pipeline runs your infrastructure code. It doesn't need a special AVM integration just because that code calls a module.

Check the module's own documentation for its inputs, version and usage examples, then review the resulting plan or deployment changes before applying them. Pinning the module version gives you control over when you pick up changes.

Reply to this answer
s640!bit_7

Check the project where the bootstrap created its repositories, especially the repository ending in -templates if one was created. Its ci.yaml and cd.yaml files are a good place to understand how the generated pipelines build and deploy infrastructure. That should help you decide whether to reuse the templates for a separate workload deployment.

Reply to this answer
~almost+on!purpose

AVM can save a lot of boilerplate and gives you a maintained set of modules, along with a public issue tracker to check when something doesn't behave as expected. But the modules can be large, with nested modules and plenty of parameters, so they aren't always easy to review.

I'd compare one relevant AVM module with a small internal module before standardizing on it. Use AVM where its coverage is useful, and consider your own module if the parameter surface or an unresolved issue makes it harder to manage.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions