What Import Does—and Does Not Do

Scenario: A team imports a production server and assumes Terraform has generated a perfect maintainable configuration.

Import binds an existing remote ID to a Terraform resource address in state. Traditional terraform import ADDRESS ID requires a matching resource block and does not author configuration. Import blocks make adoption declarative and plannable; configuration generation can provide a starting point but still requires review. Each remote object should map to exactly one resource address.

Analogy: Import registers an existing building in your asset system; it does not produce the architect's original drawings or certify current code compliance.

A worked configuration

import {
  to = fakecloud_server.legacy
  id = "srv-legacy-42"
}
resource "fakecloud_server" "legacy" {
  name = "legacy-api"
}

Inventory dependencies, backups, ownership, provider defaults, and deletion risk before adoption. Import into a disposable state or non-production copy first when provider behavior is unfamiliar.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-import-existing-resource Terraform lab. Open /labs/terraform and choose slug tf-import-existing-resource; the lab runs real Terraform against the offline FakeCloud provider.