Azure Verified Modules Guru

A specialist in Azure Verified Modules (AVM) for Bicep, helping you leverage pre-built, Microsoft-maintained infrastructure modules that enforce Azure best practices and reduce template development time.

When to Use This Agent

Choose Azure Verified Modules Guru when:

• Building Azure infrastructure with Bicep using AVM modules
• Finding and configuring AVM modules for specific resource types
• Customizing AVM module parameters for your deployment requirements
• Understanding AVM module structure, inputs, and outputs
• Contributing to or extending existing AVM modules

Consider alternatives when:

• Writing custom Bicep from scratch without AVM (use Expert Bicep Implement)
• Exporting existing Azure resources to IaC (use Azure IaC Exporter)
• Designing high-level Azure architecture (use Azure Principal Mentor)

Quick Start

Copy
# .claude/agents/azure-verified-modules-guru.yml
name: Azure Verified Modules Guru
description: Use Azure Verified Modules for Bicep
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - WebSearch

Example invocation:

claude "Deploy a web application using AVM modules for App Service, Azure SQL, and Key Vault with proper networking and monitoring"

Core Concepts

AVM Module Categories

Category	Examples	Registry Path
Resource	Key Vault, App Service, SQL	avm/res/{provider}/{resource}
Pattern	Hub-spoke network, Landing Zone	avm/ptn/{pattern-name}
Utility	Naming, Tags, RBAC	avm/utl/{utility-name}

Using AVM Modules

Copy
// main.bicep — Using AVM modules from Bicep Registry
targetScope = 'resourceGroup'

param environment string
param location string = resourceGroup().location

// AVM: Key Vault
module keyVault 'br/public:avm/res/key-vault/vault:0.6.0' = {
  name: 'keyVault-${environment}'
  params: {
    name: 'kv-myapp-${environment}'
    location: location
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
    diagnosticSettings: [{
      workspaceResourceId: logAnalytics.outputs.resourceId
    }]
  }
}

// AVM: App Service
module appService 'br/public:avm/res/web/site:0.5.0' = {
  name: 'appService-${environment}'
  params: {
    name: 'app-myapp-${environment}'
    location: location
    kind: 'app,linux'
    serverFarmResourceId: appServicePlan.outputs.resourceId
    siteConfig: {
      linuxFxVersion: 'NODE|20-lts'
      alwaysOn: true
      ftpsState: 'Disabled'
      minTlsVersion: '1.2'
    }
    managedIdentities: {
      systemAssigned: true
    }
    appSettingsKeyValuePairs: {
      WEBSITE_NODE_DEFAULT_VERSION: '~20'
      KEY_VAULT_URI: keyVault.outputs.uri
    }
  }
}

Module Discovery

Copy
# Search AVM module index
# Browse: https://azure.github.io/Azure-Verified-Modules/indexes/bicep/

# List available module versions
az bicep restore --force 'br/public:avm/res/key-vault/vault:0.6.0'

# View module parameters
az bicep build --file main.bicep --stdout | jq '.parameters'

Configuration

Parameter	Description	Default
registry	Bicep registry source (public, private)	br/public
version_strategy	Module version pinning (exact, minor, latest)	exact
diagnostics	Enable diagnostic settings on all modules	true
rbac	Use RBAC authorization where supported	true
naming_convention	Resource naming pattern	Azure CAF
tags	Standard tags to apply to all resources	Environment + owner

Best Practices

1. Pin AVM module versions exactly rather than using latest. Module updates may introduce breaking changes to parameters or behavior. Use exact versions (0.6.0) and update deliberately after reviewing changelogs. Test version upgrades in non-production environments before applying to production. Create a quarterly cadence for reviewing and updating module versions.

2. Use AVM pattern modules for common architectural patterns. Instead of composing 10 resource modules manually for a hub-spoke network, use the AVM pattern module that encapsulates the entire architecture with validated defaults. Pattern modules represent Microsoft-tested architectures that follow the Well-Architected Framework, saving weeks of design and testing effort.

3. Enable diagnostic settings on every AVM module that supports them. Most AVM resource modules accept a diagnosticSettings parameter that configures logging and metrics. Pass your Log Analytics workspace resource ID to centralize monitoring across all resources. Consistent diagnostic settings are easy to configure at deployment time but tedious to add retroactively.

4. Leverage AVM module outputs for inter-module dependencies. AVM modules expose standard outputs (resourceId, name, principalId for managed identities). Use these outputs to connect modules: pass the Key Vault's resourceId to the App Service module for access configuration, or pass the VNet's subnetId to the App Service for VNet integration. This creates explicit dependency chains that Bicep resolves automatically.

5. Contribute improvements back to AVM modules. If you find a bug, missing parameter, or useful feature in an AVM module, submit a pull request to the public repository. AVM modules are community-maintained with Microsoft oversight. Contributing improvements benefits everyone using the module and ensures your customizations are maintained upstream rather than as local forks.

Common Issues

AVM module version update changes parameter names or types. AVM follows semantic versioning, but even minor version bumps may change parameter structures. Before updating, read the module's CHANGELOG and test in a dev environment. Use az deployment group what-if to preview changes before applying. Keep a list of module versions per environment and update them through the normal CI/CD pipeline.

Module does not expose a required resource property as a parameter. AVM modules abstract common configurations but may not expose every possible Azure resource property. Check if the property is available in a newer module version. If not, deploy the resource via the AVM module and then modify the specific property with an additional Bicep resource block that references the deployed resource by name.

Private registry modules are not accessible from CI/CD pipelines. AVM modules from the public registry work everywhere, but private registry modules require authentication. Configure Azure Container Registry credentials in CI/CD: use workload identity federation for GitHub Actions, managed identity for Azure DevOps, and az bicep restore to pre-download modules before deployment.