Terraform是否具备Azure ARM的「complete」模式？资源组重置场景下的技术咨询

Great question—this is a super common pain point when moving from manual Azure Portal deployments to proper IaC, and I’ve helped teams work through exactly this scenario. Let’s break down your two core questions and actionable solutions:

1. Does Terraform have an equivalent to ARM’s Complete Mode? #

Short answer: Not natively out of the box, but you can replicate the behavior with a few intentional steps. Unlike ARM’s Complete mode (which deletes any resource in the resource group that isn’t defined in the template), Terraform operates strictly based on its state file—it only manages resources that exist in both your code and state.

To mimic ARM’s Complete mode for your "reset" workflow:

• First, define only your critical, keepers infrastructure in Terraform code.
• Use terraform import to pull those existing critical resources into your Terraform state file (you’ll need to look up the import syntax for each resource type, e.g., terraform import azurerm_virtual_network.my_vnet /subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>).
• Add a lifecycle { prevent_destroy = true } block to each critical resource in your code—this safeguards them from accidental deletion during the reset process.
• Now, here’s the key: To delete all unmanaged resources (those deployed via Portal not in your Terraform state), you’ll need an extra step (more on this below), but once those are gone, Terraform will maintain your clean state going forward.

2. How to Delete Portal-Deployed Resources Not in Terraform State? #

Since Terraform ignores resources not in its state, terraform destroy won’t touch them. Here are three practical approaches:

Approach 1: Bulk Delete via Azure CLI/PowerShell (Quick & Dirty) #

If you have a clear list of resources to keep, you can script the deletion of everything else. For example, with Azure CLI:

# List all resource IDs except your keepers, then delete them
az resource list --resource-group YOUR-RG-NAME --query "[?name!='my-vnet' && name!='my-storage-account'].id" -o tsv | xargs az resource delete

This is fast if your list of keepers is short. Just double-check the query to avoid accidental deletions!

Approach 2: Import All Resources, Then Prune the Code #

If you want to fully transition to Terraform, you can import all resources in the resource group into your state, then:

• Delete the code definitions for all non-critical resources you want to remove.
• Run terraform apply—Terraform will detect that those resources exist in state but not in code, and will destroy them.
• Once done, you’ll be left with only your critical resources in both code and state, ready for proper IaC management.

To make importing easier, you can script the generation of terraform import commands. For example, use Azure CLI to list resources and output the import commands:

az resource list --resource-group YOUR-RG-NAME --query "[].{type:type, name:name, id:id}" -o json | jq -r '.[] | "terraform import azurerm_\(.type | split("/")[-1] | gsub("-"; "_"))_\(.name | gsub("-"; "_")) \(.id)"'

Note: You’ll need to adjust the resource type mapping (since Azure’s resource types don’t always match Terraform’s exact resource names) but this saves you from writing import commands manually.

Approach 3: Combine ARM Complete Mode with Terraform #

Since you already considered using ARM templates for the reset, you can leverage that first:

• Run your ARM template in Complete mode to wipe out all non-critical resources.
• Then, import the remaining critical resources into Terraform state and define them in your code.
• This gives you the clean slate you need, then hands off management to Terraform for future changes.

Pro Tips for Going Forward #

• Lock down Azure Portal access: Use Azure Policy or RBAC to restrict manual deployments to the resource group, so you don’t end up with unmanaged resources again.
• Automate state imports: For any unavoidable manual deployments, add a step to import the resource into Terraform state immediately after creation.
• Use terraform plan liberally: Always run terraform plan before applying changes to verify exactly what will be created/destroyed.

内容的提问来源于stack exchange，提问作者EG92