azure-verified-modules_skill

Overview

This skill codifies Azure Verified Modules (AVM) requirements and best practices for developing and certifying Azure Terraform modules. It helps module authors and reviewers ensure compliance with AVM rules for providers, variable/output handling, code style, testing, and documentation. Use it to reduce certification rework and keep modules consistent with Azure governance expectations.

How this skill works

The skill inspects module structure, Terraform configuration, provider constraints, naming and ordering conventions, variable and output definitions, locals, lifecycle patterns, and testing/tooling requirements. It highlights mandatory (MUST) and recommended (SHOULD/MAY) rules such as allowed providers and versions, snake_case naming, dynamic nested blocks, sensitive handling, and automated docs via terraform-docs. It also summarizes breaking-change patterns and contribution/branch-protection expectations to guide maintenance and reviews.

When to use it

• When creating a new Azure Terraform Resource or Pattern module intended for AVM certification.
• When reviewing an existing module prior to submitting for AVM verification.
• When enforcing consistent provider versions and required_providers block rules.
• When auditing variables, outputs, locals, and lifecycle blocks for AVM compliance.
• When preparing module documentation and automated terraform-docs generation.

Best practices

• Declare required_providers with allowed providers (azurerm >=4.x <5.0, azapi >=2.x <3.0) and use pessimistic constraints (~>).
• Use lower snake_case for variables, locals, outputs, resources, and module symbolic names.
• Define precise variable types (avoid any), mark sensitive inputs/outputs appropriately, and avoid nullable=true unless needed.
• Use dynamic blocks for optional nested objects and use count or static map/set for conditional creation; avoid git or non-AVM module sources.
• Automate docs with terraform-docs, include a .terraform-docs.yml, and run required tests (terraform fmt/validate/test, tflint, Checkov, terrafmt).

Example use cases

• Authoring a network module that must pin azurerm and azapi provider versions and expose computed attributes as discrete, possibly sensitive outputs.
• Refactoring a module to replace inline provider blocks with passed-in provider aliases and to convert deprecated variables into a deprecated_variables.tf file.
• Reviewing a module to ensure lifecycle.ignore_changes uses unquoted identifiers and dynamic blocks are used for optional nested resources.
• Preparing a release that adds a new resource behind a feature toggle variable to avoid breaking existing consumers.