Help & Support

Summary

This section provides information about AVM’s support.

GitHub Links

Issue Triage

This section provides information about the issue triage process and its automation, implemented across various AVM repositories.

AVM Issue Triage

“AVM Core Team Triage” Explained

This page provides guidance for members of the AVM Core Team on how to triage module proposals and generic issues filed in the AVM repository, as well as how to manage these GitHub issues throughout their lifecycle.

During the AVM Core Team Triage step, the following will be checked, completed and actioned by the AVM Core Team during their triage calls (which are currently twice per week).

Note

Every module needs a module proposal to be created in the AVM repository.

Tip

During the triage process, the AVM Core Team should also check the status of following queries:

Open items that need triaging: Needs: Triage 🔍
- Bicep items (that need triaging): Language: Bicep 💪 & Needs: Triage 🔍
- Terraform items (that need triaging): Language: Terraform 🌐 & Needs: Triage 🔍
Open items that need triaging AND aren’t being triaged yet: Needs: Triage 🔍 & NOT Status: In Triage 🔍
Open items that need attention: Needs: Attention 👋
Open items that need owners: Needs: Module Owner 📣
Open items with no recent activity: Status: No Recent Activity 💤
Open question/feedback items: Type: Question/Feedback 🙋‍♀️
Open items with long term status: Status: long-term ⏳
Open items that are not in a project.

Module Proposal triage

An issue is considered to be a module proposal if

it was opened through the “New AVM Module Proposal 📝” template,
it has the labels of Needs: Triage 🔍 and Type: New Module Proposal 💡 applied to it, and
it is assigned to the “AVM - Module Triage” GitHub project.

Follow these steps to triage a module proposal:

Add the Status: In Triage 🔍 label to indicate you’re in the process of triaging the issue.
Check module proposal issue/form:
- Check the Bicep or Terraform module indexes for the proposed module to make sure it is not already available or being worked on.
- Ensure the module’s details are correct as per specifications - naming, classification (resource/pattern) etc.
- Check if the module is added to the “Proposed” column on the AVM - Modules Triage GitHub project board.
- Check if the requestor is a Microsoft FTE.
- If there’s any additional clarification needed, contact the requestor through comments (using their GH handle) or internal channels - for Microsoft FTEs only! You can look them up by their name or using the Microsoft Open Source Management Portal’s People finder: “Linked people across Microsoft organizations”. Make sure you capture any decisions regarding the module in the comments section.
- Make adjustments to the module’s name/classification as needed.
- Change the name of the issue to reflect the module’s name, i.e.,
  - After the “[Module Proposal]:” prefix, change the issues name to the module’s approved name between backticks, i.e., ` and `, e.g., avm/res/sql/managed-instance for a Bicep module, or avm-res-compute-virtualmachine for a Terraform module.
  - Example:
    - “[Module Proposal]: avm/res/sql/managed-instance”
    - “[Module Proposal]: avm-res-sql-managedinstance”
- Check if the GitHub Policy Service Bot has correctly applied the module language label: Language: Bicep 💪 or Language: Terraform 🌐
Apply relevant labels
- Module classification (resource/pattern/utility): Class: Resource Module 📦 , Class: Pattern Module 📦 or Class: Utility Module 📦

Triaging pattern modules

As part of the triage of pattern modules, the following points need to be considered/clarified with the module requestor:

Shouldn’t this be a resource module? What makes it a pattern - e.g., does it deploy multiple resources?
What is it for? What problem does it fix or provides a solution for?
What is/isn’t part of it? Which resource and/or pattern modules are planned to be leveraged in it? Provide a list of resources that would be part of the planned module.
Where is it coming from/what’s backing it - e.g., Azure Architecture Center (AAC), community request, customer example. Provide an architectural diagram and related documentation if possible - or a pointer to these if they are publicly available.
Don’t let the module’s scope to grow too big, split it up to multiple smaller ones that are more maintainable - e.g., hub & spoke networking should should be split to a generic hub networking and multiple workload specific spoke networking patterns.
The module’s name should be as descriptive as possible.
Adopt strict name-to-scope mapping - e.g., hub & spoke networking shouldn’t deploy monitoring.

Scenario 1: Requestor doesn’t want to / can’t be module owner

Note

If requestor is interested in becoming a module owner, but is not a Microsoft FTE, the AVM core team will try to find a Microsoft FTE to be the module owner whom the requestor can collaborate with.

If the requestor indicated they didn’t want to or can’t become a module owner (or is not a Microsoft FTE), make sure the Needs: Module Owner 📣 label is assigned to the issue. Note: the GitHub Policy Service Bot should automatically do this, based on how the issue author responded to the related question.
Move the issue to the “Looking for owners” column on the AVM - Modules Triage GitHub project board.
Add a comment on the issue with the #RFRC tag to indicate that the repository should be created. Keep the proposal issue available to the community and potential module owners.
Find module owners - if the requestor didn’t volunteer in the module proposal OR the requestor does not want or cannot be owner of the module:
- Try to find an owner from the AVM communities or await a module owner to comment and propose themselves on the proposal issue.
When a new potential owner is identified, continue with the steps described as follows.

Scenario 2: Requestor wants to and can become module owner

If the requestor indicated they want to become the module owner, the GitHub Policy Service Bot will add the Status: Owners Identified 🤘 label and will assign the issue to the requestor.

You MUST still confirm that the requestor is a Microsoft FTE and that they understand the implications of becoming the owner! If any of these conditions aren’t met, remove the Status: Owners Identified 🤘 label and unassign the issue from the requestor.

Make sure the requestor is a Microsoft FTE. You can look them up by their name or using the Microsoft Open Source Management Portal’s People finder: “Linked people across Microsoft organizations”.
Clarify the roles and responsibilities of the module owner:
- Clarify they understand and accept what “module ownership” means by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to Proposed Module Owners

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Once module owner identified has confirmed they understand and accept their roles and responsibilities as an AVM module owner
- Make sure the issue is assigned to the confirmed module owner.
- Move the issue into the “In development” column on the AVM - Modules Triage GitHub Project board.
- Add a comment on the issue with the #RFRC tag to indicate that the repository should be created.
- Make sure the Status: Owners Identified 🤘 label is added to the issue.
  - If applied earlier, remove the Needs: Module Owner 📣 label from the issue.
- Remove the labels of Needs: Triage 🔍 and Status: In Triage 🔍 to indicate you’re done with triaging the issue.
Keep the approved name, description, and owners in the proposal issue, then record the supported fields through a metadata pull request. Metadata may be created before the module source exists; the module stays Proposed until it is published.
Use the following text to approve module development

➕ Final Confirmation for Proposed Module Owners - Bicep

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

Before starting development, please ensure ALL the following requirements are met.

Every module owner must request and obtain approval for the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20#bicep).

**Use the module name and path approved in the proposal, and the assigned telemetry identifier.** The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) remains a published lookup reference:

- For your module:
  - `ModuleName` - for naming your module
  - `TelemetryIdPrefix` - for your module's [telemetry](https://azure.github.io/Azure-Verified-Modules/spec/SFR3)
  - Folder path are defined in `RepoURL`.

Maintain module details and the assigned `telemetryIdPrefix` in `metadata.json` through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/). If an approved value is missing or conflicts with the index, contact the AVM core team.

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍

You can now start the development of this module! ✅ Happy coding! 🎉

**Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏**

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team
<!-- markdownlint-restore -->

➕ Final Confirmation for Proposed Module Owners - Terraform

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍

Module owners must request and obtain approval for the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20#terraform). Per-module GitHub teams are no longer required.

You can now start the development of this module! ✅ Happy coding! 🎉

**Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏**

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team
<!-- markdownlint-restore -->

Important

Although, it’s not directly part of the module proposal triage process, to begin development, module owners and contributors might need additional help from the AVM core team, such as:

Update any Azure RBAC permissions for test tenants/subscription, if needed.
In case of Bicep modules only:
- Confirm that every module owner has approved access through the AVM Module Contributors access package, as outlined in SNFR20. Per-module GitHub teams and parent-team assignments are no longer required. Root metadata.json determines reviewer notifications; BRM has no per-module CODEOWNERS entries.

Post-Development issue management

Once module is developed and v0.1.0 has been published to the relevant registry

Assign the Status: Module Available 🟢 label to the issue.
Move the issue into “Done” column in AVM - Modules Triage GitHub Project.
Confirm that the module metadata and registry publication are correct. The four-hourly catalog sync then publishes the module index. Submit any metadata corrections to the module repository. For Bicep, verify that module list sync adds the new top-level module to the issue-template dropdown after catalog publication.

When all development actions are complete and confirmed

In case of Bicep modules - Close the module proposal issue with the following message:

➕ Closing remarks for the Owner(s) of a Published Bicep Module

- [x] Module published.
- [x] Module Contributors access package approved for all module owners.
- [x] Issue template file updated.

The AVM core team coordinates the module index through the [catalog sync](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/#catalog-updates), which regenerates and publishes it automatically every four hours.

Thank you for your work @replace_with_author! I'm closing this issue now.

In case of Terraform modules - Close the issue.

Important

The Module Proposal issue MUST remain open until the module is fully developed, tested and published to the relevant registry.
Do NOT close the issue before the successful publication is confirmed!
Once the module is fully developed, tested and published to the relevant registry, and the Module Proposal issue was closed, it MUST remain closed.

Changing module owners

There can be several reasons why a module owner change is needed, e.g., the current owner is leaving the company, changing team, or is no longer able to maintain the module. In such cases, the module ownership needs to be transferred to a new owner. While in most cases the module needs to be marked as orphaned until it’s taken over by a new module owner, sometimes, the ownership can be transferred through a “hot swap”, where the current owner directly hands over ownership to another person without the module becoming orphaned first.

Note

The original Module Proposal issue related to the module in question MUST remain closed and intact.

Instead, a new Orphaned Module issue must be opened that MUST remain open until the ownership is fully confirmed!

Once the Orphaned Module issue was closed, it MUST remain closed. If the module will subsequently become orphaned again, a new Orphaned Module issue must be opened.

Adding or removing co-owners

Agree changes with the current owners and the AVM core team. Confirm each incoming owner’s eligibility, written acceptance of the role, and separate access approval. Submit the agreed handle changes to the owners array in the module’s root metadata.json, following the metadata review process. Use bare handles for individuals and qualified handles for approved existing teams. Keep every continuing individual or team owner; children inherit the root’s ownership.

Use the hot-swap process for a handover. If no owners remain, follow the orphaning process instead.

Orphaned modules

If a module meets the criteria described in the “Orphaned Modules” chapter, the module is considered to be orphaned and the below steps must be performed.

When a module becomes orphaned

Submit an “orphaned module” issue by using the “Orphaned AVM Module 🟡” issue template.
Make sure the Needs: Triage 🔍 , Needs: Module Owner 📣 , and the Status: Module Orphaned 🟡 labels are assigned to the issue and it is assigned to the “AVM - Module Triage” GitHub project.
Move the issue into the “Orphaned” column on the AVM - Modules Triage GitHub Project board.
Submit and merge the ownership change in a pull request to the module’s root metadata.json, linked to the orphaned module issue. Set "owners": [], removing all individual and team handles, following the metadata review process. Do not edit child ownership or set a status field. A published, non-deprecated module with no owners is shown as Orphaned; see how module status is calculated.```
Replace the label Needs: Triage 🔍 with the label Needs: In Triage🔍 & Add the appropriate label for the class of module i.e. Resoruce/Pattern/Utility
Try to find a new owner using the AVM communities or await a new module owner to comment and propose themselves on the issue.

For both Bicep and Terraform, the root metadata change is the only module-file change required. No ORPHANED.md file, manual README.md notice, or README regeneration is required. The scheduled catalog sync publishes the new status; do not edit generated indexes or create a module release.

When a new owner is identified

Tip

To look for Orphaned Modules:

Click on the following link to use this saved query ➡️ Status: Module Orphaned 🟡 ⬅️.
Check the Orphaned swim lane on the Module Triage board.

When a new potential owner is identified, confirm they are a Microsoft FTE and clarify the roles and responsibilities of the module owner:
- Clarify they understand and accept what “module ownership” means by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to New Owners of an Orphaned Module

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Once the new module owner candidate has confirmed they understand and accept their roles and responsibilities as an AVM module owner
- Assign the issue to the confirmed module owner.
- Remove the Status: Module Orphaned 🟡 and the Needs: Module Owner 📣 labels from the issue.
- Add the Status: Module Available 🟢 and Status: Owners Identified 🤘 labels to the issue.
Submit a pull request adding the approved incoming handles to the owners array in the module’s root metadata.json, linked to the orphaned module issue. Obtain approval from either metadata code-owner team and merge the change through the metadata review process.
Ensure every new owner has approved access through the AVM Module Contributors access package. See SNFR20 for the language-specific access requirements.
Use the following text to confirm the new ownership of an orphaned module:

➕ Final Confirmation for New Owners of an Orphaned Module

Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

We just want to ask you to double check a few important things.

**Before taking ownership, confirm the following**:

- Every incoming owner must have approved access through the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20).
- Confirm every approved incoming owner is recorded in the root `metadata.json` through a merged [metadata pull request](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/) linked to this issue. Metadata does not grant access or review permission.
- The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) is regenerated automatically every four hours. Check back to confirm your name appears once the metadata change is merged.

Once the required ownership and access steps are confirmed, you can start improving the module as its owner! ✅ Happy coding! 🎉

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team

Once the metadata change is reviewed and merged and all access requirements above are complete, close the orphaned module issue with the following message. Closing the issue moves it to “Done” on the AVM - Modules Triage board. The module index updates automatically at the next four-hourly catalog sync.

➕ Closing remarks for the New Owner(s) of an Orphaned Module

- [x] Module Contributors access package approved for all incoming module owners.
- [x] Root metadata ownership change approved by either metadata code-owner team, merged, and linked to this issue through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/).

The module index is regenerated automatically every four hours, so the ownership change should appear shortly.

Thank you for your work @replace_with_author! I'm closing this issue now.

Hot swapping module owners

When the module owner needs to be changed without the module becoming orphaned, the overall process described in the Orphaned modules chapter needs to be followed, with a few differences.

Submit an “orphaned module” issue by using the “Orphaned AVM Module 🟡” issue template while indicating the GitHub handle of the new owner.
Clarify the roles and responsibilities of the module owner by replying in a comment to the requestor/proposed owner:

➕ Standard AVM Core Team Reply to the New Owner(s) of an Orphaned Module

<!-- markdownlint-disable -->
Hi @avm_module_owner,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm **you agree to the below pages** that define what module ownership means:

- [Team Definitions & RACI](https://azure.github.io/Azure-Verified-Modules/specs/shared/team-definitions)
- [Module Specifications](https://azure.github.io/Azure-Verified-Modules/specs/module-specs)
- [Module Support](https://azure.github.io/Azure-Verified-Modules/help-support/module-support)

Any questions or clarifications needed, let us know!

If you agree, please just **reply to this issue with the exact sentence below** (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

#RR
<!-- markdownlint-restore -->

Assign the issue to the new module owner.
Remove these labels:
- Needs: Triage 🔍
- Needs: Module Owner 📣
- Status: Module Orphaned 🟡
Add these labels to the issue:
- Status: In Triage 🔍
- Status: Module Available 🟢
- Status: Owners Identified 🤘 labels to the issue.
- Module classification (resource/pattern/utility): Class: Resource Module 📦 , Class: Pattern Module 📦 or Class: Utility Module 📦
Make sure the issue is assigned to the “AVM - Module Triage” GitHub project, but don’t move the issue to the “Orphaned” column of this board as it will be automatically moved to the “Done” column, once the issue is closed.
Once each incoming owner’s eligibility and written consent are confirmed, replace the departing handles with the approved incoming handles in the root owners array in the same metadata change, retaining every continuing individual or team owner. Remove team handles only if they no longer apply. Obtain approval from either metadata code-owner team and merge through the metadata review process. Confirm every incoming owner has approved access as described in SNFR20 before finalizing the handover.
Use the following text to finalize the new ownership transfer:

➕ Final Confirmation for the New Owner(s) of an Orphaned Module

Hi @avm_module_owner,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

We just want to ask you to double check a few important things.

**Before taking ownership, confirm the following**:

- Every incoming owner must have approved access through the [Azure Verified Modules (AVM) Module Contributors access package](https://aka.ms/avm/id/access-package/module-contributor), as outlined in [SNFR20](https://azure.github.io/Azure-Verified-Modules/spec/SNFR20).
- Confirm every approved incoming owner is recorded in the root `metadata.json` through a merged [metadata pull request](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/) linked to this issue. Metadata does not grant access or review permission.
- The [module index](https://azure.github.io/Azure-Verified-Modules/indexes/) is regenerated automatically every four hours. Check back to confirm your name appears once the metadata change is merged.

Once the required ownership and access steps are confirmed, you can start improving the module as its owner! ✅ Happy coding! 🎉

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team

Once the metadata change is reviewed and merged and the handover and access requirements above are complete, close the orphaned module issue with the following message. The module index updates automatically at the next four-hourly catalog sync.

➕ Closing remarks for the New Owner(s) of an Orphaned Module

- [x] Module Contributors access package approved for all incoming module owners.
- [x] Root metadata ownership change approved by either metadata code-owner team, merged, and linked to this issue through the [metadata review process](https://azure.github.io/Azure-Verified-Modules/contributing/module-metadata/).

The module index is regenerated automatically every four hours, so the ownership change should appear shortly.

Thank you for your work @replace_with_author! I'm closing this issue now.

Deprecated modules

When a module becomes deprecated

If a module meets the criteria described in the “Deprecated Modules” chapter, the module is considered to be deprecated and the below steps must be performed.

Language agnostic steps

Submit a “deprecated module” issue by using the “Deprecate AVM Module 🔴” issue template.
Make sure the Needs: Triage 🔍 and the Status: Module Deprecated 🔴 labels are assigned to the issue and it is assigned to the “AVM - Module Triage” GitHub project.
Record the approved deprecation decision in the issue and complete the language-specific steps below. Do not clear owners to deprecate a module or add a lifecycle/status field to metadata.json.

Bicep specific steps

Update the module and connected files as per the below guidelines:
1. Place the information notice - with the text below - in an DEPRECATED.md file, in the module’s root.
2. Run the utilities/tools/Set-AVMModule.ps1 utility with the module path & -SkipBuild switch as an input. This re-generates the module’s README.md file, so that the README.md file will also contain the same notice in its header. For more instructions on how to use the script, please refer to the corresponding section in the Contribution Guide.
3. Make sure the content of the DEPRECATED.md file is displayed in the README.md in its header (right after the title).
4. Add the the notice NOTE: This is the last published version and the module has since been deprecated. to the top-most ### Changes section of the module’s CHANGELOG.md file
5. Remove the module workflow from the workflows folder.
6. Submit a Pull Request
7. For the AVM maintainers: Once the PR is merged, run the .Platform - Publish [moduleIndex.json] workflow with the regenIndexFromBRM flag set. This will de-list the module so that it won’t show up in the VS-Code Bicep extension going forward.

Deprecating a module does not require editing CODEOWNERS or deleting a GitHub team. BRM has no per-module code-owner entries; /avm/ intentionally has no owners, while metadata.json remains protected by its own code-owner rule.

Terraform specific steps

Place the information notice - with the text below - in the README.md file, in the module’s root.
Archive the module’s repository on GitHub.

Catalog publication

The catalog derives Deprecated from Bicep’s DEPRECATED.md or Terraform’s repository archived flag. Complete the retirement steps; the four-hourly catalog sync then publishes the change.

A Bicep marker applies to that module and all its descendants. A root marker therefore covers every child; a child marker leaves its parent and siblings unaffected. Terraform archival applies to all module entries in the repository.

A module deprecated before it was ever published to the registry is removed from the indexes rather than listed as Deprecated.

Catalog publication does not perform the required notices, Bicep workflow removal and registry-index update, or Terraform repository archival. After a top-level Bicep deprecation is published, verify that module list sync removes it from the issue-template dropdown instead of editing the list by hand.

Deprecation information notice (to be place in the module’s repository as described above)

➕ Deprecated module indicators

⚠️THIS MODULE IS DEPRECATED.⚠️

- It will no longer receive any updates.
- If the underlying Azure service is not deprecated/retired, this module may still be used as is (references to any existing versions will keep working), but it is not recommended for new deployments.
- It is recommended to migrate to a replacement/alternative version of the module, if available.

General feedback/question, documentation update and other standard issues

An issue is a “General Question/Feedback ❔” if it was opened through the “General Question/Feedback ❔” issue template, and has the labels of Type: Question/Feedback 🙋‍♀️ and Needs: Triage 🔍 applied to it.

An issue is a “AVM Documentation Update 📘” if it was opened through the “AVM Documentation Update 📘” issue template, and has the labels of Type: Documentation 📄 and Needs: Triage 🔍 applied to it.

An issue is considered to be a “standard issue” or “blank issue” if it was opened without using an issue template, and hence it does NOT have any labels assigned, OR only has the Needs: Triage 🔍 label assigned.

When triaging the issue, consider adding one of the following labels as fits:

Type: Documentation 📄
Type: Feature Request ➕
Type: Bug 🐛
Type: Security Bug 🔒

To see the full list of available labels, please refer to the GitHub Repo Labels section.

Note

If an intended module proposal was mistakenly opened as a “General Question/Feedback ❔” or other standard issue, and hence, it doesn’t have the Type: New Module Proposal 💡 label associated to it, a new issue MUST be created using the “New AVM Module Proposal 📝” issue template. The mistakenly created “General Question/Feedback ❔” or other standard issue MUST be closed.

Azure Verified Modules GitHub App

Overview

The Azure Verified Modules GitHub App is represented as a GitHub App. This app automates various repository management tasks across the Azure Verified Modules program’s repositories, including issue triage, pull request labeling, team validation, and documentation updates.

The AVM repository’s team linter and AzAdvertizer workflows use the GitHub App credentials (TEAM_LINTER_APP_ID and TEAM_LINTER_PRIVATE_KEY). Retain these credentials when retiring the team linter: the active AzAdvertizer issue automation also uses them. Bicep repository maintenance workflows run from the AVM tools repository using separately scoped GitHub App tokens.

Warning

The team linter below still validates legacy per-module GitHub teams and requires separate cleanup. Do not recreate those teams to satisfy the automation; module owners must follow SNFR20 instead. Legacy CSV team columns remain for compatibility with existing shared-repository consumers.

AVM Repository Scripts

The following scripts are leveraged by the Azure Verified Modules GitHub App in the AVM repository:

1. Invoke-AvmGitHubTeamLinter.ps1

Purpose: Validates GitHub team configurations against module ownership data from CSV indexes.

Description: This script compares the module indexes with existing GitHub Teams configuration to ensure proper team setup. It can validate Bicep parent team configurations, Terraform team permissions, and generate GitHub issues for any discrepancies found. The script supports filtering by module type (Resource/Pattern/Utility) and language (Bicep/Terraform), and can validate -owner- teams.

Key Functionality:

Compares module ownership data from CSV files with GitHub team configurations
Validates parent team configuration for Bicep module owner teams
Verifies correct repository permissions for Terraform teams
Creates GitHub issues for unmatched or misconfigured teams
Closes resolved GitHub issues when team configurations are corrected

Workflow: github-teams-check-existence.yml (currently disabled; when enabled, runs Monday-Friday at 15:00 UTC and on-demand). Update its legacy team checks before re-enabling it; unchanged, it would raise issues asking owners to recreate retired teams, not recreate the teams itself.

Source Code: Invoke-AvmGitHubTeamLinter.ps1

2. New-AzAdvertizerDiffIssue.ps1

Purpose: Monitors AzAdvertizer data changes and creates tracking issues.

Description: This script creates GitHub issues when data in AzAdvertizer (including PSRule, APRL, and Advisor) changes compared to the last workflow run. It downloads artifacts from previous workflow runs, compares the data to identify changes, and automatically creates issues with detailed diff information when new policy rules, advisories, or recommendations are detected.

Key Functionality:

Downloads CSV artifacts from the latest workflow run
Compares current AzAdvertizer data with previous data to detect changes
Formats detected changes into readable GitHub issue format
Creates GitHub issues for new PSRule, APRL, or Azure Advisor data
Exports current data as artifacts for future comparisons

Workflow: platform.new-AzAdvertizer-diff-issue.yml (runs weekly on Sundays at 3:00 AM and on-demand)

Source Code: New-AzAdvertizerDiffIssue.ps1

BRM Repository Automation

The AVM tools repository hosts the workflows for BRM. Owner routing uses the published module catalog and reads a module’s root metadata.json when the catalog has not yet caught up or the pull request changes that metadata. Child modules inherit root ownership. The CSV indexes show only the first two individual owners and are not the routing source; submit owner changes through the metadata review process.

Pull request reviewer routing requests the owners of affected modules (excluding the author), applies triage labels, and requests @Azure/azure-verified-modules-module-owners for ownerless modules. Review requests and labels do not impose a module-owner approval requirement for ordinary Bicep code changes.
Issue owner routing labels module issues by class, mentions their owners, and assigns individual owners while respecting manual assignment decisions. For orphaned modules it mentions the tooling contributors team instead of assigning a module owner.
Workflow failure issues tracks failed module and shared check/publish runs with issues, mentions the owners, assigns the first individual owner when available, and closes tracking issues when the latest completed run no longer reports failure. Orphaned-module and shared-workflow issues mention the tooling contributors team.
Module list sync compares the issue-template dropdown with top-level Available and Orphaned Bicep entries in the published catalog. When it changes, a verified bot-generated pull request updates the dropdown and is auto-merged rather than opening a drift-report issue.

These workflows support manual dispatch. Their schedules are enabled separately; the presence of a workflow alone does not mean periodic routing is running.

Summary

The AVM repository workflows and the tools-repository workflows support issue triage, reviewer notifications, and module maintenance. Review and merge requirements come from repository rules and the protected metadata CODEOWNERS rule, not from reviewer requests or triage labels.

BRM Issue Triage

Overview

This page provides guidance for Bicep module owners on how to triage AVM module issues and AVM question/feedback items filed in the BRM repository (Bicep Registry Modules repository - where all Bicep AVM modules are published), as well as how to manage these GitHub issues throughout their lifecycle.

As such, the following issues are to be filed in the BRM repository:

[AVM Module Issue]: Issues specifically related to an existing AVM module, such as feature requests, bug and security bug reports.
[AVM Question/Feedback]:Generic feedback and questions, related to existing AVM module, the overall framework, or its automation (CI environment).

Do NOT file the following types of issues in the BRM repository, as they MUST be tracked in the AVM repo:

[Module Proposal]: Proposals for new AVM modules.
[Orphaned Module]: Indicate that a module is orphaned (has no owner).
[Question/Feedback]: Generic questions/requests related to the AVM site or documentation.

Note

Every module needs a module proposal to be created in the AVM repository.

Module Owner Responsibilities

During the triage process, module owners are expected to check, complete and follow up on the items described in the sections below.

Module owners MUST follow the Module Support statement. Automation supports issue triage, but module owners MUST check for new issues regularly.

Important

The BRM repository includes other, non-AVM modules and related GitHub issues. As a module owner, make sure you’re only triaging, managing or otherwise working on issues that are related to AVM modules!

Tip

To look for items that need triaging, click on the following link to use this saved query ➡️ Needs: Triage 🔍 ⬅️.
To look for items that need attention, click on the following link to use this saved query ➡️ Needs: Attention 👋 ⬅️.
Open items that are not in a project.

Module Issue

An issue is considered to be an “AVM module issue” if

it was opened through the [AVM Module Issue] template in the BRM repository,
it has the labels of Needs: Triage 🔍 and Type: AVM 🅰️ ✌️ ⓜ️ applied to it, and
it is assigned to the “AVM - Module Issues” GitHub project.

Note

Module issues can only be opened for existing AVM modules. Module issues MUST NOT be used to file a module proposal.

If the issue was opened as a misplaced module proposal, mention the @Azure/azure-verified-modules-tooling-contributors team in the comment section and ask them to move the issue to the AVM repository.

Triaging a Module Issue

Check the Module issue:
- Make sure the issue has the Type: AVM 🅰️ ✌️ ⓜ️ applied to it.
- Use the AVM module indexes to locate the module and its root metadata.json for the full owner list. Make sure the owners are assigned/mentioned/informed. Submit corrections through the metadata review process.
- If the module is orphaned (has no owner), make sure there’s an orphaned module issue in the AVM repository.
- Make sure the module’s details are captured correctly in the description - i.e., name, classification (resource/pattern), language (Bicep/Terraform), etc.
- Make sure the issue is categorized using one of the following type labels:
  - Type: Feature Request ➕
  - Type: Bug 🐛
  - Type: Security Bug 🔒
Apply relevant labels for module classification (resource/pattern): Class: Resource Module 📦 or Class: Pattern Module 📦
Communicate next steps to the requestor (issue author).
Remove the Needs: Triage 🔍 label.
When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
Only close the issue, once the next version of the module was fully developed, tested and published.

Triaging a Module PR

Request knowledgeable review from module owners identified in the root metadata.json when available. An eligible BRM repository team member may approve and merge ordinary module code changes; a module owner’s approval is not mandatory. If the author is the sole owner, request another eligible reviewer rather than the author.
For metadata.json changes, obtain approval from an eligible member of either metadata code-owner team through the metadata review process.
Apply relevant labels
- Categorize the PR using applicable labels, such as:
  - Type: Feature Request ➕
  - Type: Bug 🐛
  - Type: Security Bug 🔒
- For module classification (resource/pattern): Class: Resource Module 📦 or Class: Pattern Module 📦
If the module is orphaned (has no owner), make sure the related Orphaned module issue (in the AVM repository) is associated to the PR in a comment, so the new owner can easily identify all related issues and PRs when taking ownership.
Remove the Needs: Triage 🔍 label.

Give your PR a meaningful title

Prefix: Start with one of the allowed keywords - fix: or feat: is the most common for module related changes.
Description: Add a few words, describing the nature of the change.
Module name: Add the module’s full name between backticks ( ` ) to make it pop.

Who needs to approve the PR?

For ordinary Bicep module code changes, any eligible repository team member may approve and merge under BRM rules. Reviewer routing requests module owners and applies triage labels, but does not impose a module-owner approval requirement. The metadata.json code-owner rule and other protected-path rules still apply.

General Question/Feedback and other standard issues

An issue is considered to be an “AVM Question/Feedback” if

it was opened through the [AVM Question/Feedback] template in the BRM repository,
it has the labels of Needs: Triage 🔍 , Type: Question/Feedback 🙋‍♀️ and Type: AVM 🅰️ ✌️ ⓜ️ applied to it, and
it is assigned to the “AVM - Issue Triage” GitHub project.

Triaging a General Question/Feedback and other standard issues

When triaging the issue, consider adding one of the following labels as fits:
- Type: Documentation 📄
- Type: Feature Request ➕
- Type: Bug 🐛
- Type: Security Bug 🔒

To see the full list of available labels, please refer to the GitHub Repo Labels section.

Add any (additional) labels that apply.
Communicate next steps to the requestor (issue author).
Remove the Needs: Triage 🔍 label.
When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
Once the question/feedback/topic is fully addressed, close the issue.

Note

If an intended module proposal was mistakenly opened as a “AVM Question/Feedback ❔” or other standard issue, a new issue MUST be created in the AVM repo using the “New AVM Module Proposal 📝” issue template. The mistakenly created “AVM Question/Feedback ❔” or other standard issue MUST be closed.

Issue Triage Automation

This page details the automation that is in place to help with the triage of issues and PRs raised against the AVM modules.

Note

Some of these automation rules are currently disabled or reduced. A number of the comment-based automations — the recurring “chase” scheduled searches, and the per-issue/PR triage comment previously posted by ITA06 — have been disabled, or had their commenting removed, to avoid notification fatigue for everyone involved. In their current form they are too noisy, are largely filtered out and ignored by most, and are not having the desired impact.

Schedule based automation

This section details all automation rules that are based on a schedule.

Note

When calculating the number of business days in the issue/triage automation, the built-in logic considers Monday-Friday as business days. The logic doesn’t consider any holidays.

ITA04

Warning

This rule is currently disabled in all AVM repositories.

If an issue/PR has been labeled with Needs: Author Feedback 👂 and hasn’t had a response in 4 days, label with Status: No Recent Activity 💤 and add a comment.

Schedule:

Triggered every 3 hours.

Trigger criteria:

Is an open issue/PR.
Had no activity in the last 4 days.
Has the Needs: Author Feedback 👂 label added.
Does not have the Status: No Recent Activity 💤 label added.

Action(s):

Add the Status: No Recent Activity 💤 label.
Add a reply.

Tip

To prevent further actions to take effect, one of the following conditions must be met:

The author must respond in a comment within 3 days of the automatic comment left on the issue.
The Status: No Recent Activity 💤 label must be removed.
If applicable, the Status: Long Term ⏳ or the Needs: Module Owner 📣 label must be added.

ITA05

Warning

This rule is currently disabled in the AVM Core and BRM repositories, and is not present in the Terraform repositories.

If an issue/PR has been labeled with Status: No Recent Activity 💤 and hasn’t had any update in 3 days from that point, automatically close it and comment, unless the issue/PR has a Status: Long Term ⏳ - in which case, do not close it.

Schedule:

Triggered every 3 hours.

Trigger criteria:

Is an open issue.
Had no activity in the last 3 days.
Has the Needs: Author Feedback 👂 and the Status: No Recent Activity 💤 labels added.
Does not have the Needs: Module Owner 📣 or Status: Long Term ⏳ labels added.

Action(s):

Add a reply.
Close the issue.

Tip

In case the issue needs to be reopened (e.g., the author responds after the issue was closed), the Status: No Recent Activity 💤 label must be removed.

ITA24

Warning

This rule is currently disabled in the AVM Core repository.

Remind module owner(s) to start or continue working on this module if there was no activity on the Module Proposal issue for more than 3 weeks. Add Needs: Attention 👋 label.

Schedule:

Triggered every 3 hours.

Trigger criteria:

Is an open issue.
Had no activity in the last 21 days.
Has the Type: New Module Proposal 💡 and the Status: Owners Identified 🤘 labels assigned.
Does not have the Status: Long Term ⏳ label assigned.
Does not have the Needs: Attention 👋 label assigned.

Action(s):

Add a reply.
Add the Needs: Attention 👋 label.

Tip

To silence this notification, provide an update every 3 weeks on the Module Proposal issue, or add the Status: Long Term ⏳ label.

Event based automation

This chapter details all automation rules that are based on an event.

ITA06

When a new issue or PR of any type is created add the Needs: Triage 🔍 label.

Warning

The comment (reply) previously posted by this rule has been removed to reduce notification fatigue; the rule now only applies the label. See the note at the top of this page.

Trigger criteria:

An issue or PR is opened.

Action(s):

Add the Needs: Triage 🔍 label.

ITA08BCP

If AVM or “Azure Verified Modules” is mentioned in an uncategorized issue (i.e., one not using any template), apply the label of Type: AVM 🅰️ ✌️ ⓜ️ on the issue.

Trigger criteria:

An issue, issue comment, PR, or PR comment is opened, created or edited and the body or comment contains the strings of “AVM” or “Azure Verified Modules”.

Action(s):

Add the Type: AVM 🅰️ ✌️ ⓜ️ label.

ITA09

When #RR is used in an issue, add the label of Needs: Author Feedback 👂 .

Trigger criteria:

An issue comment or PR comment contains the string of “#RR”.

Action(s):

Add the Needs: Author Feedback 👂 label.

ITA10

When #wontfix is used in an issue, mark it by using the label of Status: Won’t Fix 💔 and close the issue.

Trigger criteria:

An issue comment or PR comment contains the string of “#RR”.

Action(s):

Add the Status: Won’t Fix 💔 label.
Close the issue.

ITA11

When the author replies, remove the Needs: Author Feedback 👂 label and label with Needs: Attention 👋 .

Trigger criteria:

Any action on an issue comment or PR comment except closing.
Has the Needs: Author Feedback 👂 label assigned.
The activity was initiated by the issue/PR author.

Action(s):

Remove the Needs: Author Feedback 👂 label.
Remove the Status: No Recent Activity 💤 label.
Add the Needs: Attention 👋 label.

ITA12

Clean up e-mail replies to GitHub Issues for readability.

Trigger criteria:

Any action on an issue comment.

Action(s):

Clean email reply. This is useful when someone directly responds to an email notification from GitHub, and the email signature is included in the comment.

ITA13

If the language is set to Bicep in the Module proposal, add the Language: Bicep 💪 label on the issue.

Trigger criteria:

An issue is opened with its body matching the below pattern.

### Bicep or Terraform?

Bicep

Action(s):

Add the Language: Bicep 💪 label.

ITA14

If the language is set to Terraform in the Module proposal, add the Language: Terraform 🌐 label on the issue.

Trigger criteria:

An issue is opened with its body matching the below pattern.

### Bicep or Terraform?

Terraform

Action(s):

Add the Language: Terraform 🌐 label.

ITA15

Remove the Needs: Triage 🔍 label from a PR, if it already has a “Type: XYZ label added and is assigned to someone at the time of creating it.

Trigger criteria:

A PR is opened with any of the following labels added and is assigned to someone:
- Type: Bug 🐛
- Type: Documentation 📄
- Type: Duplicate 🤲
- Type: Feature Request ➕
- Type: Hygiene 🧹
- Type: New Module Proposal 💡
- Type: Question/Feedback 🙋‍♀️
- Type: Security Bug 🔒

Action(s):

Remove the Needs: Triage 🔍 label.

ITA16

Add the Status: Owners Identified 🤘 label when someone is assigned to a Module Proposal.

Trigger criteria:

Any action on an issue except closing.
Has the Type: New Module Proposal 💡 added.
The issue is assigned to someone.

Action(s):

Add the Status: Owners Identified 🤘 label.

ITA17

If the issue author says they want to be the module owner, assign the issue to the author and respond to them.

Trigger criteria:

An issue is opened with its body matching the below pattern.
```
### Do you want to be the owner of this module?

Yes
```

Action(s):

Assign the issue to the author.

Add the below reply and explain the action(s).

@${issueAuthor}, thanks for volunteering to be a module owner!

**Please don't start the development just yet!**

The AVM core team will review this module proposal and respond to you first. Thank you!

ITA18

Send automatic response to the issue author if they don’t want to be module owner and don’t have any candidate in mind. Add the Needs: Module Owner 📣 label.

Trigger criteria:

An issue is opened with its body matching the below pattern.

  ### Do you want to be the owner of this module?

  No

  ### Module Owner's GitHub Username (handle)

  _No response_

Action(s):

Add the Needs: Module Owner 📣 label.

Add the below reply and explain the action(s).

@${issueAuthor}, thanks for submitting this module proposal!
The AVM core team will review it and will try to find a module owner.

ITA19

Send automatic response to the issue author if they don’t want to be module owner but have a candidate in mind. Add the Status: Owners Identified 🤘 label.

Trigger criteria:

An issue is opened with its body matching the below pattern…
```
  ### Do you want to be the owner of this module?

  No
```

…AND NOT matching the below pattern.

### Module Owner's GitHub Username (handle)

_No response_

Action(s):

Add the Status: Owners Identified 🤘 label.

Add the below reply and explain the action(s).

@${issueAuthor}, thanks for submitting this module proposal with a module owner in mind!

**Please don't start the development just yet!**

The AVM core team will review this module proposal and respond to you and/or the module owner first. Thank you!

ITA20

If the issue type is feature request, add the Type: Feature Request ➕ label on the issue.

Trigger criteria:

An issue is opened with its body matching the below pattern.
```
### Issue Type?

Feature Request
```

Action(s):

Add the Type: Feature Request ➕ label.

ITA21

If the issue type is bug, add the Type: Bug 🐛 label on the issue.

Trigger criteria:

An issue is opened with its body matching the below pattern.
```
### Issue Type?

Bug
```

Action(s):

Add the Type: Bug 🐛 label.

ITA22

If the issue type is security bug, add the Type: Security Bug 🔒 label on the issue.

Trigger criteria:

An issue is opened with its body matching the below pattern.
```
### Issue Type?

Security Bug
```

Action(s):

Add the Type: Security Bug 🔒 label.

ITA23

Remove the Status: In PR 👉 label from an issue when it’s closed.

Trigger criteria:

An issue is opened.

Action(s):

Remove the Status: In PR 👉 label.

ITA25

This legacy Bicep rule prompts a sole module owner to apply the Needs: Core Team 🧞 label for triage visibility. The label does not require core-team approval: ordinary Bicep code changes may be approved by any eligible BRM repository team member other than the author. Changes to metadata.json still require metadata code-owner review.

Trigger criteria:

A PR is opened.

Action(s):

Prompt sole module owners to apply the Needs: Core Team 🧞 label for triage visibility.

ITA26

Add a label for the AVM Core Team to query called Status: Ready For Repository Creation 📝 when a module owner adds a comment to the issue to tell them.

Trigger criteria:

A comment is added to an issue that contains the #RFRC tag.

Action(s):

Adds the Status: Ready For Repository Creation 📝 label to the Issue.

Where to apply these rules?

The below table details which repositories the above rules are applied to.

Rules applied for Schedule based automation

ID	AVM Core repository	BRM repository	TF repositories
ITA04	[✔️]	[✔️]	[✔️]
ITA05	[✔️]	[✔️]
ITA24	[✔️]

Warning

A check mark in brackets (e.g., [✔️]) indicates that the rule exists in that repository but is currently disabled. The following schedule-based rules are currently disabled: ITA04 (in all the repositories it applies to), ITA05 (in the AVM Core and BRM repositories), and ITA24 (in the AVM Core repository).

Rules applied for Event based automation

ID	AVM Core repository	BRM repository	TF repositories
ITA06	✔️	✔️	✔️
ITA08BCP		✔️
ITA09	✔️	✔️	✔️
ITA10	✔️	✔️	✔️
ITA11	✔️	✔️	✔️
ITA12	✔️	✔️	✔️
ITA13	✔️
ITA14	✔️
ITA15	✔️	✔️	✔️
ITA16	✔️
ITA17	✔️
ITA18	✔️
ITA19	✔️
ITA20		✔️	✔️
ITA21		✔️	✔️
ITA22		✔️	✔️
ITA23	✔️		✔️
ITA25		✔️
ITA26	✔️

Terraform Issue Triage

Overview

This page provides guidance for Terraform Module owners on how to triage AVM module issues and AVM question/feedback items filed in their Terraform Module Repo(s), as well as how to manage these GitHub issues throughout their lifecycle.

The following issues can be filed in a Terraform repository:

AVM Module Issue: Issues specifically related to an existing AVM module, such as feature requests, bug and security bug reports.
AVM Question/Feedback: Generic feedback and questions, related to existing AVM module, the overall framework, or its automation (CI environment).

Do NOT file the following types of issues in a Terraform repository, as they MUST be tracked in the AVM repo:

[Module Proposal]: Proposals for new AVM modules.
[Orphaned Module]: Indicate that a module is orphaned (has no owner).
[Question/Feedback]: Generic questions/requests related to the AVM site or documentation.

Note

Every module needs a module proposal to be created in the AVM repository.

Module Owner Responsibilities

During the triage process, module owners are expected to check, complete and follow up on the items described in the sections below.

Module owners MUST follow the Module Support statement. Automation supports issue triage, but module owners MUST check for new issues regularly.

Tip

To look for items that need triaging, look for issue labled with ➡️ Needs: Triage 🔍 ⬅️.
To look for items that need attention, look for issue labled with ➡️ Needs: Attention 👋 ⬅️.

Module Issue

An issue is considered to be an “AVM module issue” if

it was opened through the AVM Module Issue template in the Terraform repository,
it has the label of Needs: Triage 🔍 applied to it, and
it is assigned to the “AVM - Module Issues” GitHub project.

Note

Module issues can only be opened for existing AVM modules. Module issues MUST NOT be used to file a module proposal.

If the issue was opened as a misplaced module proposal, mention the @Azure/azure-verified-modules-engineering-owners team in the comment section and ask them to move the issue to the AVM repository.

Triaging a Module Issue

Check the Module issue:
- Use the AVM module indexes to locate the module and its root metadata.json for the full owner list. Make sure the owners are assigned/mentioned/informed. Submit corrections through the metadata review process.
- If the module is orphaned (has no owner), make sure there’s an orphaned module issue in the AVM repository.
- Make sure the module’s details are captured correctly in the description - i.e., name, classification (resource/pattern), language (Bicep/Terraform), etc.
- Make sure the issue is categorized using one of the following type labels:
  - Type: Feature Request ➕
  - Type: Bug 🐛
  - Type: Security Bug 🔒
Apply relevant labels for module classification (resource/pattern): Class: Resource Module 📦 or Class: Pattern Module 📦
Communicate next steps to the requestor (issue author).
Remove the Needs: Triage 🔍 label.
When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
Only close the issue, once the next version of the module was fully developed, tested and published.

Triaging a Module PR

PR approvals are enforced on all AVM Terraform module repositories. The following rules apply to who must approve:

Changes to metadata.json require approval from an eligible member of either @Azure/azure-verified-modules-engineering-owners or @Azure/azure-verified-modules-module-owners, as described in the metadata review process. Approval from both teams is not required, and being named in owners alone does not qualify a reviewer. The code-review requirements below apply to other changes in the same pull request.

If the PR is submitted by the module owner and the module is owned by a single person, another Terraform module owner must review and approve the PR (the module owner cannot approve their own PR).
- First port of call: find a friendly module owner from the azure-verified-modules-module-contributors Entra group and request a review.
- If no owner is available, assign the @Azure/azure-verified-modules-engineering-owners GitHub team as a reviewer and apply the Needs: Core Team 🧞 label so the AVM core team picks it up during triage.
If the PR is submitted by a contributor (other than the module owner), or the module is owned by at least 2 people, one of the module owners should review and approve the PR.
Apply relevant labels
- Categorize the PR using applicable labels, such as:
  - Type: Feature Request ➕
  - Type: Bug 🐛
  - Type: Security Bug 🔒
- For module classification (resource/pattern): Class: Resource Module 📦 or Class: Pattern Module 📦
If the module is orphaned (has no owner), make sure the related Orphaned module issue (in the AVM repository) is associated to the PR in a comment, so the new owner can easily identify all related issues and PRs when taking ownership.
Remove the Needs: Triage 🔍 label.

Give your PR a meaningful title

Prefix: Start with one of the allowed keywords - fix: or feat: is the most common for module related changes.
Description: Add a few words, describing the nature of the change.

General Question/Feedback and other standard issues

An issue is considered to be an “AVM Question/Feedback” if

it was opened through the AVM Question/Feedback template in your Terraform repository,
it has the labels of Needs: Triage 🔍 and Type: Question/Feedback 🙋‍♀️ applied to it, and
it is assigned to the “AVM - Issue Triage” GitHub project.

Triaging a General Question/Feedback and other standard issues

When triaging the issue, consider adding one of the following labels as fits:
- Type: Documentation 📄
- Type: Feature Request ➕
- Type: Bug 🐛
- Type: Security Bug 🔒

To see the full list of available labels, please refer to the GitHub Repo Labels section.

Add any (additional) labels that apply.
Communicate next steps to the requestor (issue author).
Remove the Needs: Triage 🔍 label.
When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
Once the question/feedback/topic is fully addressed, close the issue.

Note

Known Issues

Unfortunately, there will be times where issues are out of the AVM core team and module owners/contributor’s control and the issue may be something that has to be lived with for a longer than ideal duration - for example, in case of changes that are due to the way the Azure platform, or a resource behaves, or because of an IaC language issue.

This page will detail any of the known issues that consumers may come across when using AVM modules and provide links to learn more about them and where to get involved in discussions on these known issues with the rest of the community.

Important

Issues related to an AVM module must be raised on the repo they are hosted on, not the AVM Central (Azure/Azure-Verified-Modules) repo!

Although, if you think a known issue is missing from this page please create an issue on the AVM Central Azure/Azure-Verified-Modules repo.

If you accidentally raise an issue in the wrong place, we will transfer it to its correct home. 👍

Bicep

Bicep what-if compatibility with modules

Bicep/ARM What-If has a known issue today where it short-circuits whenever a runtime function is used in a nested template. And due to the way Bicep modules work, all module declarations in a Bicep file end up as a resulting nested template deployment in the underlying generated ARM template, thereby invoking this known issue.

GitHub Issue for Further Information & Discussion

Azure/arm-template-whatif #157 - Resources in nested template not shown if reference is used in the parameter values

The ARM/Bicep Product Group has recently announced on the issue that they are making progress in this space and are aiming provide a closer ETA in the near future; see the comment here.

While this isn’t an AVM issue, we understand that consumers of AVM Bicep modules may want to use what-if and are running into this known issue. Please keep adding your support to the issue mentioned above (Azure/arm-template-whatif #157), as the Product Group are actively engaging in the discussion there. 👍

Other Related GitHub Issues

Azure/Azure-Verified-Modules #797 - [AVM Question/Feedback]: Output of what-if (if any) can’t be trusted

4MB limitation

A well-known limitation of ARM, and in extension Bicep, is its compiled ARM template size constraint of 4MB. While there is not anything one can do to change this limit there are actions you can take to reduce your template’s size and make it less likely to run into this issue.

In the following we provide you with a list of options you should be aware of:

➕ Use loops for multi-instance deployments

If you deploy multiple instances of the same module (e.g., DNS entries, role assignments, etc.) you should invoke the module using a loop, as opposed to separate references to the same module. The reason comes down the way that ARM interprets these references: Each reference of a module is restored to its full ARM size. That means, if you invoke the same module 3 separate time, you will find that this module’s full template is added as a nested deployment 3 separate times. Using a loop instead, the reference is only added once and invoked as many times as your loop has entries.

For example, you should refactor the code

targetScope = 'subscription'

@description('The principal to assign the roles to.')
param principalId string

module testDeployment1 'br/public:avm/res/authorization/role-assignment/sub-scope:0.1.0' = {
  params: {
    principalId: principalId
    roleDefinitionIdOrName: 'Contributor'
  }
}
module testDeployment2 'br/public:avm/res/authorization/role-assignment/sub-scope:0.1.0' = {
  params: {
    principalId: principalId
    roleDefinitionIdOrName: 'Role Based Access Control Administrator'
  }
}

targetScope = 'subscription'

@description('The principal to assign the roles to.')
param principalId string

var rolesToAssign = [
  'Contributor'
  'Role Based Access Control Administrator'
]

module testDeployment 'br/public:avm/res/authorization/role-assignment/sub-scope:0.1.0' = [
  for role in rolesToAssign: {
    params: {
      principalId: principalId
      roleDefinitionIdOrName: role
    }
  }
]

For this example, the compiled JSON of first version has a size of 18kb, the second 10kb.

➕ Only use AVM if you benefit from its features

Using AVM modules can come with a lot of advantages compared to a native resource deployment. This can be as simple as being a ‘module’ deployment, enabling you to deploy to multiple scopes in the same template at once, all the way to encapsulating entire solution into a single invocation and hence drastically reducing the complexity of your own solution template.

However, they also come with certain limitations. For one, that you’re dependent on the module providing you all the features you need, but moreover, that the very same features are always part of the module, whether you use them or not, hence contributing to your solution template’s size.

With this in mind, our recommendation is to only use AVM modules if you use any of its features, hence justifying the added size.

Recommendations

Only use the br/public:avm/res/resources/resource-group resource if you deploy resource groups with role assignments
Only use the br/public/avm/res|ptn/authorization/(...) modules if you benefit from their scope flexibility
When facing challenges with the template size, start replacing individual module references with their native counter-part under consideration of the size-reduction (considering large modules like API-Management, Storage Account, etc.) and the complexity of re-implementing the required features yourself. The good news: For the latter you can cherry-pick the parts of the AVM template you need.

➕ Split the solution template

Probably the most uncomfortable option. If you cannot deploy your solution in one go, it may make sense to split it into logical chunks that you can deploy separately and optionally in sequence (e.g., in your workflow).

This approach comes with a few drawbacks such as the potentially longer deployment time and less intuitive resolution of interdependencies. In other words, if many of your module deployments use each other’s outputs and you split them into multiple templates, you’d need to create ’existing’ references in the later deployments to get the same outputs.

For example, splitting the following two resources

module acr 'br/public:avm/res/container-registry/registry:0.9.3' = {
  params: {
    name: 'myContainerRegistry'
  }
}

module key 'br/public:avm/res/key-vault/vault/key:0.1.0'= {
  params: {
    name: 'myKey'
    keyVaultName: 'keyVaultName'
    roleAssignments: [
      {
        principalId: acr.outputs.systemAssignedMIPrincipalId!
        roleDefinitionIdOrName: 'Key Vault Crypto Service Encryption User'
      }
    ]
  }
}

in two templates requires you to either add an output for the first resource’s identity to the first template and pass it to the second, or create an existing reference in the second template akin to

resource acr 'Microsoft.ContainerRegistry/registries@2025-04-01' existing = {
  name: 'myContainerRegistry'
}

module key 'br/public:avm/res/key-vault/vault/key:0.1.0'= {
  params: {
    name: 'myKey'
    keyVaultName: 'keyVaultName'
    roleAssignments: [
      {
        principalId: acr.identity.principalId
        roleDefinitionIdOrName: 'Key Vault Crypto Service Encryption User'
      }
    ]
  }
}

Terraform

Currently there are no known issues for AVM Terraform modules. 🥳

Module Support

AVM is now owned by Azure engineering

On 13 October 2026, AVM moved into the Azure Deployments team within Microsoft’s Azure engineering organization.

This move adds dedicated engineering resources to AVM. It also replaces the previous day-based response targets with the support model described below.

For more information, read Azure Verified Modules (AVM) is now owned by Azure engineering.

AVM is an open-source Microsoft project with dedicated engineers and distributed module ownership. The AVM Core Team maintains modules directly and improves the shared specifications, tooling, automation, and framework. For who owns which modules, see Module Ownership Tiers.

Support Statement

AVM follows the support model used by Azure CLI, Azure PowerShell, Bicep, AzAPI, and the AzureRM Terraform provider.

Report module bugs and feature requests in the module’s GitHub repository.
AVM does not provide fixed response or resolution targets for GitHub issues.

Dedicated engineers maintain modules and improve the framework used by all module owners. This commitment replaces the previous day-based targets, which AVM could not meet consistently.

Security vulnerabilities

Do not report security vulnerabilities through public GitHub issues. Report them privately to the Microsoft Security Response Center, as described in the repository security policy.

AVM is Open-Source

AVM is open-source, therefore, contributions are welcome via Pull Requests or comments in Issues from anyone in the world at any time on any Pull Request or Issues to assist AVM module owners 🌐

Review the contribution guidance to get involved!

Tip

Issues that are likely related to an AVM module should be directly submitted on the module’s GitHub repository as an “AVM - Module Issue”. To identify the correct code repository, see the AVM module indexes.

If an issue is likely related to the Azure platform, its APIs or configuration, script or programming languages, etc., you need to raise a ticket with Microsoft CSS (Microsoft Customer Services & Support) where your ticket will be triaged for any platform issues. If deemed a platform issue, the ticket will be addressed accordingly. In case it’s deemed not a platform but a module issue, you will be redirected to submit a module issue on GitHub.

Orphaned Modules

A module becomes orphaned when it has no active module owner. See Module Lifecycle for more information.

Info

If a module is orphaned, the AVM Core Team will provide essential maintenance and try to find a new owner by:

Listing orphaned modules in a saved GitHub issue query on the AVM module index pages for potential new owners to pick up.
In more urgent or high priority cases, selectively identifying a new module owner from the pool of existing AVM module owners/contributors to take over the module.

To raise attention to an orphaned module and allow the AVM team to better prioritize actions, customers can leave a comment on the “orphaned module” issue, explaining their use case and why they would like to see the module supported. This will help the AVM team to prioritize the module for a new owner.

Telemetry

Microsoft uses the approach detailed in this section to identify the deployments of the AVM Modules. Microsoft collects this information to provide the best experiences with their products and to operate their business. Telemetry data is captured through the built-in mechanisms of the Azure platform; therefore, it never leaves the platform, providing only Microsoft with access. Deployments are identified by an AVM-specific prefix in their names. The data is collected and governed by Microsoft’s privacy policies, located at the Trust Center.

Telemetry collected as described here does not provide Microsoft with insights into the resources deployed, their configuration or any customer data stored in or processed by Azure resources deployed by using code from AVM. Microsoft does not track the usage/consumption of individual resources using telemetry described here.

Note

Telemetry gathered as described here is only accessible by Microsoft. Bicep customers can view the deployment in the Azure portal under Deployments at its corresponding scope (resource group, subscription, etc.). Terraform customers can view the generated deployment at the active subscription scope and inspect the exact values sent in main.telemetry.tf.

See View deployment history with Azure Resource Manager for further information on how.

Technical Details

As detailed in SFR3, an instrumented Bicep module creates an avmTelemetry deployment named <telemetryIdPrefix>.<version>.<uniqueness>, using its current metadata prefix. An instrumented Terraform module creates an empty, subscription-scoped deployment through the generated azapi_resource.telemetry. Its name contains the fixed 46d3xtrf metadata prefix, the full installed version (or 0-0-0), a one-letter source type (t, o, g, or x), and a stable four-character instance suffix. The name, not resource tags, carries the reporting data. A changing empty-template output causes a deployment write on each normal apply without changing the name; no raw source path or tier is sent.

Terraform module roots require a location input, except utility modules that deploy no Azure resources. Local child modules that deploy Azure resources require it as well. Pass a region available in your cloud, including sovereign clouds: telemetry creates a subscription-scoped deployment there even when the module’s other resources are global or scope-based. Child and example calls forward the parent’s location when no per-resource location is already supplied. Pattern modules may offer optional per-resource locations; each child uses its specific value when supplied, or the shared location otherwise. With telemetry enabled, the identity needs Microsoft.Resources/deployments/read, Microsoft.Resources/deployments/write, and Microsoft.Resources/deployments/delete at the subscription scope.

Opting Out

Albeit telemetry described in this section is optional, the implementation follows an opt-out logic, as most commercial software solutions, this project also requires continuously demonstrating evidence of usage, hence the AVM core team recommends leaving the telemetry setting on its default, enabled configuration.

This resource enables the AVM core team to query the number of deployments of a given module from Azure - and as such, get insights into its adoption.

To opt out you can set the parameters/variables listed below to false in the AVM module:

Bicep: enableTelemetry
Terraform: enable_telemetry

Telemetry vs Customer Usage Attribution

Though similar in principles, this approach is not to be confused and does not conflict with the usage of CUA IDs that are used to track Azure customer usage attribution of Azure marketplace solutions (partner solutions). AVM deployment telemetry can coexist with CUA IDs. If you have any partner or customer scenarios that require the addition of CUA IDs, you can customize the AVM modules by adding the required CUA ID deployment while keeping the built-in telemetry solution.

Tip

If you’re a partner and want to build a solution that tracks customer usage attribution (using a CUA ID), we recommend implementing it on the consuming template’s level (i.e., the multi-module solution, such as workload/application) and apply the required naming format 'pid-' (without the suffix).

Help & Support

Summary

Subsections of Help & Support

GitHub Links

Issue Triage

Subsections of Issue Triage

AVM Issue Triage

“AVM Core Team Triage” Explained

Module Proposal triage

Triaging pattern modules

Scenario 1: Requestor doesn’t want to / can’t be module owner

Scenario 2: Requestor wants to and can become module owner

Post-Development issue management

Changing module owners

Adding or removing co-owners

Orphaned modules

When a module becomes orphaned

When a new owner is identified

Hot swapping module owners

Deprecated modules

When a module becomes deprecated

General feedback/question, documentation update and other standard issues

Azure Verified Modules GitHub App

Overview

AVM Repository Scripts

1. Invoke-AvmGitHubTeamLinter.ps1

2. New-AzAdvertizerDiffIssue.ps1

BRM Repository Automation

Summary

BRM Issue Triage

Overview

Module Owner Responsibilities

Module Issue

Triaging a Module Issue

Triaging a Module PR

General Question/Feedback and other standard issues

Triaging a General Question/Feedback and other standard issues

Issue Triage Automation

Schedule based automation

ITA04

ITA05

ITA24

Event based automation

ITA06

ITA08BCP

ITA09

ITA10

ITA11

ITA12

ITA13

ITA14

ITA15

ITA16

ITA17

ITA18

ITA19

ITA20

ITA21

ITA22

ITA23

ITA25

ITA26

Where to apply these rules?

Rules applied for Schedule based automation

Rules applied for Event based automation

Terraform Issue Triage

Overview

Module Owner Responsibilities

Module Issue

Triaging a Module Issue

Triaging a Module PR

General Question/Feedback and other standard issues

Triaging a General Question/Feedback and other standard issues

Known Issues

Bicep

Bicep what-if compatibility with modules

4MB limitation

Terraform

Module Support

Support Statement