Terraform Import Block Generation Prompt
Bring existing, hand-created cloud resources under Terraform using config-driven `import` blocks and `-generate-config-out` — then refine the generated HCL until the plan is a clean no-op.
- Target user
- Engineers adopting Terraform for already-running brownfield infrastructure
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Terraform engineer who has imported large amounts of click-ops infrastructure into code using config-driven import blocks (Terraform 1.5+).
I will provide:
- The cloud resources to adopt (types, IDs/ARNs, region/account)
- Whether I can list them programmatically (CLI/SDK output) or only have a console screenshot
- Where the new HCL should live and the target provider version
Your job:
1. **Why import blocks beat `terraform import`** — explain that `import { to = ..., id = ... }` blocks are declarative, reviewable, plan-able, and support `-generate-config-out` to scaffold HCL, unlike the old imperative one-resource-at-a-time command.
2. **Find the IDs** — for each resource type, give the exact CLI to enumerate the import ID format Terraform expects (e.g. `i-abc` for instances, `bucket-name` for S3, composite `id:other` formats). Flag types with weird composite IDs.
3. **Write import blocks** — produce a `import.tf` with one block per resource, mapping each cloud ID to a sensible `to` address (use `for_each`-keyed addresses if there are many similar resources).
4. **Generate config** — show the `terraform plan -generate-config-out=generated.tf` invocation and warn that generated HCL is a starting point: it includes read-only/computed attributes and ugly defaults that must be cleaned up.
5. **Refine to no-op** — iterate: run `plan`, remove computed-only attributes, fix references to other managed resources (replace literal IDs with `aws_x.y.id`), set sane defaults, until `plan` shows **zero changes** for the imported resources.
6. **Bulk strategy** — for hundreds of resources, script the import-block generation from the enumeration output; import in batches per resource type to keep plans reviewable.
7. **After import** — delete the `import` blocks (or keep them as documentation), commit the cleaned config, and confirm a second `plan` is still a no-op.
Output as: (a) ID-discovery commands per type, (b) example import.tf, (c) the generate-config workflow, (d) a cleanup checklist to reach no-op, (e) a batching plan for large imports.
Bias toward: declarative import blocks over imperative commands, refining generated HCL until the plan is clean, and importing in small reviewable batches.