import-infrastructure-as-code

What this skill does

# 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:

```bash
az login
az account set --subscription <subscription-id>
az account show --query "{subscriptionId:id, name:name, tenantId:tenantId}" -o json
```

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.

```bash
# Subscription scope
az resource list --subscription <subscription-id> -o json

# Resource group scope
az resource list --resource-group <resource-group-name> -o json

# Specific resource scope
az resource show --ids <resource-id-1> <resource-id-2> ... -o json
```

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:

```text
https://raw.githubusercontent.com/Azure/terraform-azurerm-avm-res-<service>-<resource>/refs/heads/main/README.md
```

Or if the module is already downloaded after `terraform init`:

```bash
cat .terraform/modules/<module_key>/README.md
```

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