azure-verified-modules
Azure Verified Modules (AVM) requirements and best practices for developing certified Azure Terraform modules. Use when creating or reviewing Azure modules that need AVM certification.
Security Assessment
About azure-verified-modules
A reference guide encoding the mandatory and recommended requirements for Azure Verified Modules (AVM) certification of Azure Terraform modules. It consolidates the AVM specification into an actionable checklist of numbered requirements (for example TFFR1, TFFR3, and the TFNFR series), each labeled with a severity of MUST, SHOULD, or MAY, so authors can tell hard rules apart from advisory guidance while building or reviewing a module.
Coverage spans the full surface of a compliant module: cross-referencing other modules only via pinned HashiCorp registry sources (never git or non-AVM references); allowed Azure providers and their version bounds (azapi >= 2.0 < 3.0, azurerm >= 4.0 < 5.0) enforced through required_providers with pessimistic constraints; and code-style rules such as lower snake_casing for locals, variables, outputs, resources, and modules. It also details resource and block internal ordering (meta-arguments like count and for_each first, arguments alphabetized, depends_on and lifecycle last), count-versus-for_each usage with static-literal keys, dynamic blocks for optional nested objects, unquoted ignore_changes, and coalesce or try patterns for defaults. Variable requirements cover mandatory types, precise descriptions, sensitive-data handling, non-nullable collection defaults, and the prohibition of module-wide toggles like enabled or module_depends_on.
Reach for it when creating a new Azure Terraform module intended for AVM certification, or when auditing an existing module against the standard before submission. Because each rule carries a requirement ID and severity, it doubles as a review rubric: walk the listed sections, confirm MUST items are satisfied, and treat SHOULD items as strong defaults. The document references the official AVM site and the Terraform specification for the authoritative source.
FAQ
Which Azure providers and versions are allowed for an AVM module?
Authors must use only azapi (>= 2.0, < 3.0) and azurerm (>= 4.0, < 5.0), and may pick either or both. Versions must be enforced with a required_providers block, and the pessimistic constraint operator (~>) is recommended.
How should modules reference other modules?
Cross-references must use a HashiCorp Terraform registry source pinned to a version (for example source = "Azure/xxx/azurerm" with version = "1.2.3"). Git references and references to non-AVM modules are not allowed.
What naming convention does the guide require?
Lower snake_casing is required (a MUST under TFNFR4) for locals, variables, outputs, resource symbolic names, and module symbolic names.
Can a module define a boolean 'enabled' variable to switch the whole module on or off?
No. Module owners must not add variables like enabled or module_depends_on that control the entire module's operation, though boolean feature toggles for specific resources are acceptable.
How should optional nested blocks be created conditionally?
They must use a dynamic block whose for_each is a conditional list, such as for_each = <condition> ? [<item>] : [], with the block body inside a content {} section.
Install azure-verified-modules
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
hashicorp/agent-skills