Module Specifications
This section documents all the specifications for Azure Verified Modules (AVM) and their respective IaC languages.
Specifications by IaC Language
| Category | Bicep | Terraform | ||||
|---|---|---|---|---|---|---|
| Resource | Pattern | Utility | Resource | Pattern | Utility | |
| 9 | 8 | 8 | 9 | 8 | 8 | |
| 4 | 3 | 4 | 2 | 2 | 2 | |
| 25 | 18 | 9 | 20 | 14 | 9 | |
| 2 | 2 | 2 | 31 | 31 | 31 | |
| 14 | 11 | 10 | 14 | 11 | 10 | |
| 14 | 13 | 13 | 10 | 10 | 9 | |
| 5 | 5 | 5 | 4 | 4 | 4 | |
| 5 | 5 | 5 | 4 | 4 | 4 | |
| Summary | 78 | 65 | 56 | 94 | 84 | 77 |
What changed recently?
See what specifications changed in the last 12 months...How to navigate the specifications?
The “Module Specifications” section uses tags to dynamically render content based on the selected attributes, such as the IaC language, module classification, category, severity and more. The tags are defined in header of each specification page.
To make it easier for module owners and contributors to navigate the documentation, the specifications are grouped to distinct pages by the IaC language (Bicep | Terraform) and module classification ( resource | pattern | utility). The specifications on each page are further ordered by the category (e.g., Composition, CodeStyle, Testing, etc.), severity of the requirements (MUST | SHOULD | MAY) and at what stage of the module’s lifecycle the specification is typically applicable (Initial | BAU | EOL).
To find what you need, simply decide which IaC language you’d like develop in and what classification your module falls under, then navigate to the respective page to find the specifications that are relevant to you.
Info
All specifications have a 4-9 character long unique ID - a combination of letters and numbers. These letters only carry legacy meaning only leveraged by the AVM core team and are no longer used to group the specifications in any visible way. The ID is used to reference the specification in the code, documentation, and discussions.
Specification Tags
The following tags are used to qualify the specifications:
| Key | Allowed Values | Multiple/Single |
|---|---|---|
| Language | Bicep, Terraform | Multiple |
| Class | Resource, Pattern, Utility | Multiple |
| Type | Functional, NonFunctional | Single |
| Category | Testing, Telemetry, Contribution/Support, Documentation, CodeStyle, Naming/Composition, Inputs/Outputs, Release/Publishing | Single |
| Severity | MUST, SHOULD, MAY | Single |
| Persona | Owner, Contributor | Multiple |
| Lifecycle | Initial, BAU, EOL | Single |
| Validation | Bicep: BCP/Manual, BCP/CI/Informational, BCP/CI/Enforced Terraform: TF/Manual, TF/CI/Informational, TF/CI/Enforced | Single per language |
Each tag is a concatenation of exactly one of the keys and one of the values, e.g., Language-Bicep, Class-Resource, Type-Functional, etc. When it’s marked as Multiple, it means that the tag can have multiple values, e.g., Language-Bicep, Language-Terraform, or Persona-Owner, Persona-Contributor, etc. When it’s marked as Single, it means that the tag can have only one value, e.g., Type-Functional, Lifecycle-Initial, etc.
Why are there language specific specifications?
While every effort is being made to standardize requirements and implementation details across all languages (and most specifications in fact, are applicable to all), it is expected that some of the specifications will be different between their respective languages to ensure we follow the best practices and leverage features of each language.
How to read the specifications?
Important
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
As you’re developing/maintaining a module as a module owner or contributor, you need to ensure that your module adheres to the specifications outlined in this section. The specifications are designed to ensure that all AVM modules are consistent, secure, and compliant with best practices.
There are 3 levels of specifications:
- MUST: These are mandatory requirements that MUST be followed.
- SHOULD: These are recommended requirements that SHOULD be followed, unless there are good reasons for not to.
- MAY: These are optional requirements that MAY be followed at the module owner’s/contributor’s discretion.