Import existing Azure resources into Terraform using Azure CLI discovery and Azure Verified Modules (AVM). Use when asked to reverse-engineer live Azure infrastructure, generate Infrastructure as Code from existing subscriptions/resource groups/resource IDs, map dependencies, derive exact import add

Import Infrastructure as Code (Azure Terraform with AVM) Convert existing Azure infrastructure into maintainable Terraform code using discovery data and Azure Verified Modules. When to Use This Skill Use this skill when the user asks to: Import existing Azure resources into Terraform Generate IaC from live Azure environments Handle any Azure resource type supported by AVM (and document justified non AVM fallbacks) Recreate infrastructure from a subscription or resource group Map dependencies between discovered Azure resources Use AVM modules instead of handwritten azurerm resources Prerequisites Azure CLI installed and authenticated ( az login ) Access to the target subscription or resource group Terraform CLI installed Network access to Terraform Registry and AVM index sources Inputs Parameter Required Default Description subscription id No Active CLI context Azure subscription used for subscription scope discovery and context setting resource group name No None Azure resource group used for resource group scope discovery resource id No None One or more Azure ARM resource IDs used for specific resource scope discovery At least one of subscription id , resource group name , or resource id is required. Step by Step Workflows 1) Collect Required Scope (Mandatory) Request one of these scopes before running discovery commands: Subscription scope: <subscription id Resource group scope: <resource group name Specific resources scope: one or more <resource id values Scope handling rules: Treat Azure ARM resource IDs (for example /subscriptions/.../providers/... ) as cloud resource identifiers, not local file system paths. Use resource IDs only with Azure CLI ids arguments (for example az resource show ids <resource id ). Never pass resource IDs to file reading commands ( cat , ls , read file , glob searches) unless the user explicitly says they are local file paths. If the user already provided one valid scope, do not ask for additional scope inputs unless required by a failing command. Do not ask follow up questions that can be answered from already provided scope values. If scope is missing, ask for it explicitly and stop. 2) Authenticate and Set Context Run only the commands required for the selected scope. For subscription scope: Expected output: JSON object with subscriptionId , name , and tenantId . For resource group or specific resource scope, az login is still required but az account set is optional if the active context is already correct. When using specific resource scope, prefer direct ids based commands first and avoid extra discovery prompts for subscription or resource group unless needed for a concrete command. 3) Run Discovery Commands Discover resources using the selected scopes. Ensure to fetch all necessary information for accurate Terraform generation. Expected output: JSON object or array containing Azure resource metadata ( id , type , name , location , tags , properties ). 4) Resolve Dependencies Before Code Generation Parse exported JSON and map: Parent child relationships (for example: NIC Subnet VNet) Cross resource references in properties Ordering for Terraform creation IMPORTANT: Generate the following documentation and save it to a docs folder in the root of the project. exported resources.json with all discovered resources and their metadata, including dependencies and references. EXPORTED ARCHITECTURE.MD file with a human readable architecture overview based on the discovered resources and their relationships. 5) Select Azure Verified Modules (Required) Use the latest AVM version for each resource type. Terraform Registry Search for "avm" + resource name Filter by "Partner" tag to find official AVM modules Example: Search "avm storage account" → filter by Partner Official AVM Index Note: The following links always point to the latest version of the CSV files on the main branch. As intended, this means the files may change over time. If you require a point in time version, consider using a specific release tag in the URL. Terraform Resource Modules : https://raw.githubusercontent.com/Azure/Azure Verified Modules/refs/heads/main/docs/static/module indexes/TerraformResourceModules.csv Terraform Pattern Modules : https://raw.githubusercontent.com/Azure/Azure Verified Modules/refs/heads/main/docs/static/module indexes/TerraformPatternModules.csv Terraform Utility Modules : https://raw.githubusercontent.com/Azure/Azure Verified Modules/refs/heads/main/docs/static/module indexes/TerraformUtilityModules.csv Individual Module information Use the web tool or another suitable MCP method to get module information if not available locally in the .terraform folder. Use AVM sources: Registry: https://registry.terraform.io/modules/Azure/<module /azurerm/latest GitHub: https://github.com/Azure/terraform azurerm avm res <service <resource Prefer AVM modules over handwritten azurerm resources when an AVM module exists. When fetching module information from GitHub repositories, the README.md file in the root of the repository typically contains all detailed information about the module, for example: https://raw.githubusercontent.com/Azure/terraform azurerm avm res <service <resource /refs/heads/main/README.md 5a) Read the Module README Before Writing Any Code (Mandatory) This step is not optional. Before writing a single line of HCL for a module, fetch and read the full README for that module. Do not rely on knowledge of the raw azurerm provider or prior experience with other AVM modules. For each selected AVM module, fetch its README: Or if the module is already downloaded after terraform init : From the README, extract and record before writing code : 1. Required Inputs — every input the module requires. Any child resource listed here (NICs, extensions, subnets, public IPs) is managed inside the module. Do not create standalone module blocks for those resources. 2. Optional Inputs — the exact Terraform variable names and their declared type . Do not assume they match the raw azurerm provider argument names or block shapes. 3. Usage examples — check what resource group identifier is used ( parent id vs resource group name ), how child resources are expressed (inline map vs separate module), and what syntax each input expects. Apply module rules as patterns, not assumptions Use the lessons below as examples of the type of mismatch that often causes imports to fail. Do not assume these exact names apply to every AVM module. Always verify each selected module's README and variables.tf . avm res compute virtualmachine (any version) network interfaces is a Required Input . NICs are owned by the VM module. Never create standalone avm res network networkinterface modules alongside a VM module — define every NIC inline under network interfaces . TrustedLaunch is expressed through the top level booleans secure boot enabled = true and vtpm enabled = true . The security type argument exists only under os disk for Confidential VM disk encryption and must not be used for TrustedLaunch. boot diagnostics is a bool , not an object. Use boot diagnostics = true ; use the separate boot diagnostics storage account uri variable if a storage URI is needed. Extensions are managed inside the module via the extensions map. Do not create standalone extension resources. avm res network virtualnetwork (any version) This module is backed by the AzAPI provider, not azurerm . Use parent id (the full resource group resource ID string) to specify the resource group, not resource group name . Every example in the README shows parent id ; none show resource group name . Generalized takeaway for all AVM modules: Determine child resource ownership from Required Inputs before creating sibling modules. Determine accepted variable names and types from Optional Inputs and variables.tf . Determine identifier style and input shape from README usage examples. Do not infer argument names from raw azurerm resources. 6) Generate Terraform Files Before Writing Import Blocks — Inspect Module Source (Mandatory) After terraform init downloads the modules, inspect each module's source files to determine the exact Terraform resource addresses before writing any import {} blocks. Never write import addresses from memory. Step A — Identify the provider and resource label This reveals whether the module uses azurerm or azapi resource labels. For example, avm res network virtualnetwork exposes azapi resource "vnet" , not azurerm virtual network "this" . Step B — Identify child modules and nested paths If child resources are managed in a sub module (subnets, extensions, etc.), the import address must include every intermediate module label: Step C — Check for count vs for each Any resource using count requires an index in the import address. When count = 1 (e.g., conditional Linux vs Windows selection), the address must end with [0] . Resources using for each use string keys, not numeric indexes. Known import address patterns (examples from lessons learned) These are examples only. Use them as templates for reasoning, then derive the exact addresses from the downloaded source code for the modules in your current import. Resource Correct import to address pattern AzAPI backed VNet module.<vnet key .azapi resource.vnet Subnet (nested, count based) module.<vnet key .module.subnet["<subnet name "].azapi resource.subnet[0] Linux VM (count based) module.<vm key .azurerm linux virtual machine.this[0] VM NIC module.<vm key .azurerm network interface.virtualmachine network interfaces["<nic key "] VM extension (default deploy sequence=5) module.<vm key .module.extension["<ext name "].azurerm virtual machine extension.this VM extension (deploy sequence=1–4) module.<vm key .module.extension <n ["<ext name "].azurerm virtual machine extension.this NSG NIC association module.<vm key .azurerm network interface security group association.this["<nic key <nsg key "] Produce: providers.tf with azurerm provider and required version constraints main.tf with AVM module blocks and explicit dependencies variables.tf for environment specific values outputs.tf for key IDs and endpoints terraform.tfvars.example with placeholder values Diff Live Properties Against Module Defaults (Mandatory) After writing the initial configuration, compare every non zero property of each discovered live resource against the default value declared in the corresponding AVM module's variables.tf . Any property where the live value differs from the module default must be set explicitly in the Terraform configuration. Pay particular attention to the following property categories, which are common sources of silent configuration drift: Timeout values (e.g., Public IP idle timeout in minutes defaults to 4 ; live deployments often use 30 ) Network policy flags (e.g., subnet private endpoint network policies defaults to "Enabled" ; existing subnets often have "Disabled" ) SKU and allocation (e.g., Public IP sku , allocation method ) Availability zones (e.g., VM zone, Public IP zone) Redundancy and replication settings on storage and database resources Retrieve full live properties with explicit az commands, for example: Do not rely solely on az resource list output, which may omit nested or computed properties. Pin module versions explicitly: 7) Validate Generated Code Run: Expected output: no syntax errors, no validation errors, and a plan that matches discovered infrastructure intent. Troubles

import-infrastructure-as-code