A storage bucket was created by hand last year and now has to come under Terraform management. Team policy says every change to state must appear in a plan that is reviewed in a pull request and is then applied only by the pipeline. Which approach satisfies that policy?
Select an answer to reveal the explanation.
Short Explanation
Here's the difference that matters: the import command changes state the moment you hit Enter, while an import block waits politely in the plan for someone to review it. If your rule is 'nothing touches state without a reviewed plan', you want the block. And don't expect Terraform to adopt the bucket just because the names match; it'll try to create a new one.
Full Explanation
An import block declares, in configuration, that an existing object with a given ID should be bound to a resource address. Terraform evaluates it during plan, so the plan output shows the object being imported alongside any updates needed to match the resource block, and nothing reaches state until that plan is applied. That fits a workflow where every state change is reviewed in a pull request and executed by the pipeline. The terraform import command, by contrast, writes to state immediately from wherever it runs, outside the plan and review cycle, and it runs with the operator's own credentials. Writing only the resource block makes Terraform plan a create; it does not search for matching objects, and the provider will usually fail with an already-exists error. A data source reads attributes of an existing object but never manages it, and there is no conversion from a data source entry into a managed resource. Exam caveat: once the import has been applied, the import block can be left in place or removed; it is idempotent. Operational check: the reviewed plan should list the bucket as an import with no unexpected changes before the pipeline applies it.