Import Infrastructure As Code
Reverse-engineer live Azure resources into import-ready, AVM-based Terraform instead of handwritten azurerm blocks.
Overview
Import Infrastructure as Code is an agent skill most often used in Operate (also Build) that imports existing Azure resources into Terraform using CLI discovery and Azure Verified Modules with import-ready addresses.
Install
npx skills add https://github.com/github/awesome-copilot --skill import-infrastructure-as-codeWhat is this skill?
- Discovers resources via Azure CLI from subscription or resource group scope
- Generates Terraform using Azure Verified Modules (AVM) with documented non-AVM fallbacks
- Derives exact terraform import addresses from downloaded module source
- Maps dependencies between discovered resources to reduce configuration drift
- Produces files ready for terraform validate and plan across supported Azure resource types
Adoption & trust: 6.6k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Azure subscription works but has no trustworthy IaC, and manual azurerm copies will drift from what is actually deployed.
Who is it for?
Indie devops leads or solo founders taking over brownfield Azure subscriptions who want module-standard Terraform imports.
Skip if: Greenfield Azure from scratch with no existing resources, or teams standardized on Bicep/Pulumi-only workflows refusing Terraform.
When should I use this skill?
User asks to import Azure resources into Terraform, generate IaC from live environments, map dependencies, or use AVM instead of handwritten azurerm resources.
What do I get? / Deliverables
You get AVM-based Terraform and precise import mappings from discovered IDs, ready for validate and plan before controlled applies.
- AVM-oriented Terraform configuration files
- Import address mapping derived from module source
- Dependency notes between discovered Azure resources
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Operate is the canonical shelf because the skill targets brownfield subscriptions and resource groups already running in production. Infra subphase matches discovery, dependency mapping, import addresses, and Terraform plan validation—not app feature code.
Where it fits
Import a production resource group into Terraform before enabling CI plans on every PR.
Document dependencies between App Service, Key Vault, and storage discovered in a inherited MVP subscription.
Produce import-ready modules so staging matches prod before a major release cutover.
How it compares
Discovery-to-import Terraform generator with AVM opinion—not a point-and-click portal export or generic ARM-to-TF converter without import addresses.
Common Questions / FAQ
Who is import-infrastructure-as-code for?
Builders with Azure CLI access who need to turn live subscriptions or resource groups into maintainable Terraform centered on Azure Verified Modules.
When should I use import-infrastructure-as-code?
During Operate when codifying production Azure; during Build when onboarding a acquired environment; before Ship when you need IaC parity for staging mirrors.
Is import-infrastructure-as-code safe to install?
Review the Security Audits panel on this Prism page; the workflow needs cloud credentials and shell access—treat plans and imports as production-sensitive operations.
SKILL.md
READMESKILL.md - Import Infrastructure As Code
# 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