
Azure Verified Modules
Author or review Azure Terraform modules so they meet Azure Verified Modules (AVM) certification requirements before publishing or handing off to platform teams.
Install
npx skills add https://github.com/hashicorp/agent-skills --skill azure-verified-modulesWhat is this skill?
- Maps mandatory AVM Terraform requirements (TFFR1 module cross-referencing and related specs) for Resource and Pattern mo
- Covers Azure provider requirements, code style, variables, outputs, locals, and Terraform configuration blocks
- Includes testing, documentation, breaking-change policy, and contribution standards aligned to azure.github.io/Azure-Ver
- Provides a compliance checklist section for certification-oriented self-review before PR or registry publish
Adoption & trust: 1.3k installs on skills.sh; 654 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
Recommended Skills
Journey fit
AVM work happens while building reusable infrastructure modules—the canonical shelf is integrations because Terraform modules wire Azure resources into your stack. Module cross-referencing, provider pins, variables/outputs, and tests are integration-layer contracts between your product and Azure—not one-off app UI.
Common Questions / FAQ
Is Azure Verified Modules safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Azure Verified Modules
# Azure Verified Modules (AVM) Requirements This guide covers the mandatory requirements for Azure Verified Modules certification. These requirements ensure consistency, quality, and maintainability across Azure Terraform modules. **References:** - [Azure Verified Modules](https://azure.github.io/Azure-Verified-Modules/) - [AVM Terraform Requirements](https://azure.github.io/Azure-Verified-Modules/specs/terraform/) ## Table of Contents - [Module Cross-Referencing](#module-cross-referencing) - [Azure Provider Requirements](#azure-provider-requirements) - [Code Style Standards](#code-style-standards) - [Variable Requirements](#variable-requirements) - [Output Requirements](#output-requirements) - [Local Values Standards](#local-values-standards) - [Terraform Configuration Requirements](#terraform-configuration-requirements) - [Testing Requirements](#testing-requirements) - [Documentation Requirements](#documentation-requirements) - [Breaking Changes & Feature Management](#breaking-changes--feature-management) - [Contribution Standards](#contribution-standards) - [Compliance Checklist](#compliance-checklist) --- ## Module Cross-Referencing **Severity:** MUST | **Requirement:** TFFR1 When building Resource or Pattern modules, module owners **MAY** cross-reference other modules. However: - Modules **MUST** be referenced using HashiCorp Terraform registry reference to a pinned version - Example: `source = "Azure/xxx/azurerm"` with `version = "1.2.3"` - Modules **MUST NOT** use git references (e.g., `git::https://xxx.yyy/xxx.git` or `github.com/xxx/yyy`) - Modules **MUST NOT** contain references to non-AVM modules --- ## Azure Provider Requirements **Severity:** MUST | **Requirement:** TFFR3 Authors **MUST** only use the following Azure providers: | Provider | Min Version | Max Version | |----------|-------------|-------------| | azapi | >= 2.0 | < 3.0 | | azurerm | >= 4.0 | < 5.0 | **Requirements:** - Authors **MAY** select either Azurerm, Azapi, or both providers - **MUST** use `required_providers` block to enforce provider versions - **SHOULD** use pessimistic version constraint operator (`~>`) **Example:** ```hcl terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 4.0" } azapi = { source = "Azure/azapi" version = "~> 2.0" } } } ``` --- ## Code Style Standards ### Lower snake_casing **Severity:** MUST | **Requirement:** TFNFR4 **MUST** use lower snake_casing for: - Locals - Variables - Outputs - Resources (symbolic names) - Modules (symbolic names) Example: `snake_casing_example` ### Resource & Data Source Ordering **Severity:** SHOULD | **Requirement:** TFNFR6 - Resources that are depended on **SHOULD** come first - Resources with dependencies **SHOULD** be defined close to each other ### Count & for_each Usage **Severity:** MUST | **Requirement:** TFNFR7 - Use `count` for conditional resource creation - **MUST** use `map(xxx)` or `set(xxx)` as resource's `for_each` collection - The map's key or set's element **MUST** be static literals **Example:** ```hcl resource "azurerm_subnet" "pair" { for_each = var.subnet_map # map(string) name = "${each.value}-pair" resource_group_name = azurerm_resource_group.example.name virtual_network_name = azurerm_virtual_network.example.name address_prefixes = ["10.0.1.0/24"] } ``` ### Resource & Data Block Internal Ordering **Severity:** SHOULD | **Requirement:** TFNFR8 **Order within resource/data blocks:** 1. **Meta-arguments (top)**: - `provider` - `count` - `for_each` 2. **Arguments/blocks (middle, alphabetical)**: - Required arguments - Optional arguments