A production database was created manually through the AWS console years ago — how would you bring it under Terraform management without recreating it?
Short Answer
Use terraform import (or the newer, declarative import block) to associate the existing, manually-created resource with a resource address in your Terraform configuration — this adds the resource to Terraform's state without creating anything new, but you still need to write a matching resource configuration block whose arguments accurately reflect the real resource's actual current settings, or the very next terraform plan will show a diff trying to "correct" the live resource to match a configuration that doesn't actually describe it.
Detailed Explanation
Import associates existing infrastructure with Terraform state, without touching the actual resource: terraform import aws_db_instance.main <actual-resource-id> (or the declarative import { to = aws_db_instance.main, id = "<actual-resource-id>" } block, generally preferred in modern Terraform) tells Terraform "this resource address now corresponds to this already-existing real resource" — the resource itself isn't created, modified, or touched in any way by the import operation itself.
The imported state alone isn't enough — you need a matching configuration block too: import only populates Terraform's state with the resource's current attributes; it doesn't generate the corresponding .tf configuration for you automatically in older Terraform versions (though newer versions' import block combined with terraform plan -generate-config-out can generate a starting configuration) — without a configuration block whose arguments match the real resource's actual settings, the next plan will show Terraform wanting to change the resource to match whatever the (likely incomplete or default-valued) configuration says, which could mean an unintended, disruptive change to a resource that was actually fine as-is.
terraform plan -generate-config-out significantly reduces the manual work of writing a matching configuration: this modern Terraform capability inspects the real resource's current state and generates a starting .tf configuration block reflecting it — this generated configuration still needs human review (it's a starting point, not guaranteed perfect), but it removes most of the tedious, error-prone manual work of transcribing every actual setting by hand.
After import, terraform plan should show no changes if the configuration accurately matches reality: this is the actual verification step — a clean, no-diff plan confirms the written (or generated) configuration genuinely describes the resource's current real state; any diff shown at this point needs to be resolved (correcting the configuration to match reality, generally, not applying a change to the live resource) before considering the import complete.
This same process extends to bringing an entire manually-created environment under Terraform management, one resource at a time: for a larger manual environment (not just one database), the same import-then-verify-no-diff process is repeated resource by resource — this is real, often substantial effort for a large environment, but it's the only way to bring existing infrastructure under management without the unacceptable alternative of destroying and recreating it.
Interview Follow-Up Questions
- How would you prioritize which resources to import first, for a large environment with many manually-created resources?
- What would you do if `terraform plan -generate-config-out`'s generated configuration is subtly wrong or incomplete for a specific resource type?
- How would you handle importing a resource that has dependencies on other resources not yet under Terraform management?
Key Takeaways
terraform import(or the declarativeimportblock) associates an existing real resource with Terraform state, without creating, modifying, or touching the actual resource in any way.- Import alone doesn't write the matching configuration — you (or
-generate-config-out) still need aresourceblock whose arguments accurately reflect the real resource's current settings. - A clean, no-diff
terraform planafter import is the actual verification that the configuration genuinely matches reality — any diff needs to be resolved before considering the import complete. - Bringing a larger manually-created environment under management means repeating this process resource by resource, which is real, substantial effort but the only safe path.
References
Last updated August 22, 2026 · Last reviewed August 22, 2026