Azure Verified Modules
Glossary GitHub GitHub Issues Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Last updated: 18 Apr 2024

Team Definitions & RACI


In AVM there will be multiple different teams involved throughout the initiatives lifecycle and ongoing long-term support. These teams will be listed below alongside their definitions.

Individuals can be members of multiple teams, at once, that are defined below.

AVM Core Team

GitHub Team: @Azure/avm-core-team

The AVM core team are responsible for:

  • Specifications
    • Shared
    • Language Specific
  • Contribution Guidance
  • Test Frameworks & Tooling
  • Initiative Governance
    • Module Lifecycle
    • Test Enforcement
    • Module Support SLAs
  • Anything else not defined below for another team or in the RACI 👍

The team is made up of both technical and non-technical team members that are all Microsoft FTEs.

Module Owners

Today, module owners MUST be Microsoft FTEs. This is to ensure that within AVM the long-term support for each module can be upheld and honoured.

Module owners are responsible for:

  • Module Creation
  • Module Maintenance (proactive & reactive)
  • Module Issue/Pull Request Triage & Resolution
  • Module Feature Request Triage & Additions
  • Managing Module Contributors

Ideally there SHOULD be at least 2 module owners per module and MUST be in a GitHub Team in the Azure organization.

Module Contributors

Module Contributors can be anyone in any organization. However, they must be an active contributor and supporting the Module Owners.

Module Contributors are responsible for:

  • Assisting the Module Owners with their responsibilities

Module Contributors MUST be in a separate GitHub Team in the Azure organization, that the Module Owners manage and are maintainers of.

Product Groups

GitHub Teams:

The Azure Bicep & Terraform Product Groups are responsible for:

  • Backup/Additional support for orphaned modules to the AVM Core Team
  • Providing inputs and feedback on AVM
  • Taking on feedback and feature requests on their products, Bicep & Terraform, from AVM usage
We are investigating working with all Azure Product Groups as a future investment area that they take on ownership, or contribute to, the AVM modules for their service/product.


R = Responsible – Those who do the work to complete the task/responsibility.

A = Accountable – The one answerable for the correct and thorough completion of the task. There must be only one accountable person per task/responsibility. Typically has ‘sign-off’.

C = Consulted – Those whose opinions are sought.

I = Informed – Those who are kept up to date on progress.

The below table defines a RACI that is proposed to be adopted by AVM and all parties referenced in the table. This will give consumers faith and trust in these modules so that they can consume and contribute to the initiative at scale.

Action/Task/ResponsibilityModule OwnersModule ContributorsAVM Core TeamProduct GroupsNotes
Build/Construct an AVM ModuleR, AR, CC, II
Publish a Bicep AVM Module to the Bicep Public RegistryR, AC, IC, II
Publish a Terraform AVM Module to the Terraform RegistryR, AC, IC, II
Manage and maintain tooling/testing frameworks pertaining to module qualityC, IC, IR, AC, I
Manage/run the AVM central backlog (module proposals, orphaned modules, test enhancements, etc.)C, IC, IR, AC, I
Provide day-to-day (BAU) module supportR, AR, CII
Provide security fixes for orphaned modulesN/AN/AR, AR, C, I