Free — no signup required

The Import Path: Adopting Legitimate Changes

2 min read

When Reality Is Right and Code Is Wrong

Not all drift is bad. Sometimes an engineer makes a manual change that is correct, necessary, and should be preserved. The wrong response is to blindly revert it. The right response is to adopt it into the codebase so it becomes part of the declared state.

There are two mechanisms for this in Terraform:

Option 1: terraform import (Classic)

terraform import pulls an existing real-world resource into Terraform's state file, associating it with a resource block you write in your .tf files. You must write the resource configuration manually first, then import the state, then run plan and keep adjusting the hand-written config until the plan shows no differences. The risk with classic import: if your written resource block doesn't exactly match the real resource's configuration, terraform plan will show changes — and a subsequent apply will modify the resource to match your (possibly incorrect) code.

Option 2: terraform plan -generate-config-out (Terraform 1.5+)

Terraform 1.5 introduced the ability to generate the resource configuration automatically from the real resource, eliminating the manual writing step — an import block naming the target address and ID, followed by a plan command that writes out a complete, accurate HCL block reflecting the resource's actual live configuration, ready for review and cleanup before it's folded into the main config. This is the preferred modern approach. It eliminates the guesswork of writing resource configurations from scratch for complex resources with dozens of attributes.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free