Specialist Azure IaC Exporter

A specialized Infrastructure as Code export agent that converts existing Azure resources into IaC templates by analyzing Azure resources through REST APIs and generating comprehensive Bicep or Terraform configurations.

When to Use This Agent

Choose Specialist Azure IaC Exporter when:

• Converting manually created Azure resources into Bicep or Terraform templates
• Documenting existing Azure infrastructure as code for version control
• Creating reusable IaC modules from production environments
• Migrating between IaC tools (ARM templates to Bicep, or to Terraform)
• Generating baseline infrastructure templates from existing deployments

Consider alternatives when:

• Creating new Azure infrastructure from scratch (use an Azure architect agent)
• Troubleshooting Azure resource issues (use an Azure operations agent)
• Managing Azure costs and optimization (use a FinOps agent)

Quick Start

Copy
# .claude/agents/specialist-azure-iac-exporter.yml
name: Specialist Azure IaC Exporter
description: Export Azure resources to IaC templates
model: claude-sonnet
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep

Example invocation:

claude "Export all resources in the 'production-rg' resource group to Bicep templates with proper parameterization and module structure"

Core Concepts

Export Workflow

Phase	Action	Output
1. Discovery	List all resources in scope	Resource inventory
2. Analysis	Read resource properties via REST API	Full resource state
3. Dependency Mapping	Identify resource dependencies	Dependency graph
4. Template Generation	Generate IaC code	Bicep/Terraform files
5. Parameterization	Extract environment-specific values	Parameter files
6. Validation	Verify templates produce equivalent infra	Validation report

Azure Resource Export via CLI

Copy
# List all resources in a resource group
az resource list --resource-group production-rg -o table

# Export resource group as ARM template
az group export --name production-rg --include-parameter-default-value

# Get specific resource details
az webapp show --name myapp --resource-group production-rg -o json

# Export as Bicep (decompile ARM to Bicep)
az bicep decompile --file exported-template.json

Bicep Module Structure

Copy
// main.bicep — Orchestration module
targetScope = 'resourceGroup'

@description('Environment name')
@allowed(['dev', 'staging', 'prod'])
param environment string

@description('Azure region')
param location string = resourceGroup().location

// Networking module
module networking 'modules/networking.bicep' = {
  name: 'networking-${environment}'
  params: {
    environment: environment
    location: location
    vnetAddressPrefix: '10.0.0.0/16'
  }
}

// App Service module
module appService 'modules/appService.bicep' = {
  name: 'appservice-${environment}'
  params: {
    environment: environment
    location: location
    subnetId: networking.outputs.appSubnetId
    appInsightsKey: monitoring.outputs.instrumentationKey
  }
}

// modules/appService.bicep
@description('Environment name for naming')
param environment string
param location string
param subnetId string
param appInsightsKey string

var appName = 'myapp-${environment}'

resource appServicePlan 'Microsoft.Web/serverfarms@2023-01-01' = {
  name: '${appName}-plan'
  location: location
  sku: {
    name: environment == 'prod' ? 'P1v3' : 'B1'
    tier: environment == 'prod' ? 'PremiumV3' : 'Basic'
  }
  properties: {
    reserved: true // Linux
  }
}

resource webApp 'Microsoft.Web/sites@2023-01-01' = {
  name: appName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: subnetId
    siteConfig: {
      linuxFxVersion: 'NODE|20-lts'
      appSettings: [
        { name: 'APPINSIGHTS_INSTRUMENTATIONKEY', value: appInsightsKey }
      ]
    }
  }
}

Configuration

Parameter	Description	Default
output_format	IaC language (bicep, terraform, arm-json)	bicep
scope	Export scope (resource-group, subscription)	resource-group
module_strategy	Module organization (flat, by-type, by-tier)	by-type
parameterize	Extract parameters for environment variance	true
include_rbac	Export role assignments	true
include_diagnostics	Export diagnostic settings	true

Best Practices

1. Export resources by type into separate modules, not one monolithic template. A single template with 50 resources is unreadable and unmaintainable. Group resources by function: networking (VNet, subnets, NSGs), compute (App Service, Functions), data (SQL, Storage), and monitoring (Log Analytics, App Insights). Each module should be independently deployable and reusable across environments.

2. Parameterize all environment-specific values. Resource names, SKUs, IP ranges, and connection strings differ between dev, staging, and production. Extract these as parameters with clear descriptions and validation rules. Use environment-specific parameter files (parameters.dev.json, parameters.prod.json) rather than hardcoding values or using complex conditional expressions.

3. Map dependencies explicitly in the template rather than relying on implicit ordering. In Bicep, use dependsOn only when the dependency is not expressed through property references. When module A references an output from module B (networking.outputs.subnetId), Bicep infers the dependency automatically. Explicit dependsOn is needed only for resources with no property-level connection but a logical deployment order.

4. Validate exported templates against the actual environment before using them. Run az deployment group what-if to compare the template against the existing resources. The diff should show zero changes — if the template would modify existing resources, the export missed a property or used a different default. Iterate until the what-if shows no differences.

5. Exclude runtime state and secrets from exported templates. Connection strings, API keys, and managed identity credentials should reference Key Vault secrets, not be hardcoded in templates. Remove deployment-specific properties (resource IDs, provisioning state, timestamps) that are computed at deploy time. The template should define desired state, not capture current state.

Common Issues

Exported templates include read-only properties that cause deployment failures. Azure REST API returns properties like provisioningState, createdDate, and computed resource IDs that cannot be set during deployment. The decompiled Bicep file includes these properties, causing validation errors. Remove all read-only properties by comparing against the resource type's Bicep documentation. The Azure documentation lists which properties are read-only for each resource type.

Resource dependencies are missing, causing deployment ordering failures. When resources are exported individually, cross-resource dependencies (subnet → NSG, app → App Service Plan, function → storage account) are not captured. Build a dependency graph by analyzing resource property references: if a web app's serverFarmId references an App Service Plan, the plan must deploy first. Express these dependencies through property references in Bicep.

Exported templates do not match the Azure portal configuration. Some Azure resources have properties that are set via data plane operations (Function App code, Storage blob settings, SQL firewall rules) that are not included in the ARM resource definition. These require additional Bicep resources or post-deployment scripts. Common examples: SQL firewall rules (Microsoft.Sql/servers/firewallRules), App Service deployment slots, and Key Vault access policies.