iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Importing a database into Terraform does not, by itself, mean Terraform has reconciled its settings with your configuration. Import associates an existing object with a Terraform resource address in state. A later plan may propose changing the database if the configuration—possibly through provider defaults—does not match its current settings. The available details do not establish what caused this particular database change; the plan, resource type, and provider are needed to identify it.
What Terraform import does—and does not do
Terraform import connects an existing remote object to a resource address in Terraform state. With the CLI, the import command maps an object ID to that address; it is separate from reconciling the object with the settings in your configuration. Import does not prove that the configuration matches the live database.
For ongoing management, Terraform needs a resource block describing the object. The configuration expresses the desired settings. If an argument is omitted, the provider may assign a default. When that default differs from a non-default value on the existing database, Terraform can propose an update on a later apply. HashiCorp explains this behavior in its single-resource import documentation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Find out whether a plan or apply changed the database
Check the Terraform plan and apply history around the time the settings changed. A plan shows proposed actions and attribute differences; an apply performs the planned changes. The exact cause cannot be determined from the title alone, so do not assume the import command itself reset the database.
#1 Best Overall
- Identify the setup. Record the Terraform version, provider and provider version, database resource type, and import identifier. Importability and identifier formats vary by resource; see HashiCorp’s CLI import guide.
- Compare the settings. For every database attribute shown in the plan, compare the live value with the configured value. Check the documentation for that exact resource to see whether omitted arguments receive provider defaults.
- Read the action and diff. Run
terraform plan. Determine whether it shows an import, an in-place update, a replacement, or a destroy-and-create sequence. Read the attribute-level differences to see which settings Terraform proposes to change. - Check state address uniqueness. Confirm the same remote object is not bound to multiple Terraform resource addresses. Terraform expects one remote object to map to one address; duplicate bindings can lead to unwanted behavior. See HashiCorp’s import guidance.
- Correct configuration before applying. If a proposed change is unexpected, adjust the resource configuration to reflect the intended settings, then run and review another plan. Apply only after the proposed actions match what you intend.
Why configuration can propose a reset
The key comparison is among the live database value, the value in the resource configuration, and any provider default used when an argument is omitted. If the live database has a non-default setting but Terraform’s configuration or provider resolves that argument to a different value, the plan may propose changing the database to match the desired configuration.
That is a possible explanation, not a confirmed diagnosis for this database. A provider-specific import implementation, duplicate state binding, or another configuration or workflow issue may also be involved. The resource type and plan output are needed to distinguish these cases.
If the change has already been applied
Inspect the database’s current settings and Terraform state, then correct the configuration to reflect the settings you intend to keep. Run and review a fresh plan before making another change. Terraform uses state to record the mapping between managed resources and remote objects; normal planning and applying use that state to manage resources. HashiCorp describes this in its state documentation.
Do not apply a corrective plan until you understand its proposed actions—especially if it shows replacement or destroy-and-create rather than an in-place update.
Rank #3
Configuration-driven import workflow
For imports managed through configuration, HashiCorp’s documented workflow is to define the destination resource, add an import block, run and review terraform plan, and apply the configuration to import the object and update state. If the plan includes unexpected changes, edit the configuration and review another plan before applying. The single-resource import guide documents this sequence.
To pinpoint this database’s cause, the necessary evidence is the Terraform and provider versions, exact resource type, configuration before and after import, import command or block, and relevant plan and apply output.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
