A terraform apply fails while creating a storage bucket because the provider reports that a bucket with that name already exists. Investigation shows a teammate created the bucket by hand last week with the settings the configuration expects. Which response is correct?
Select an answer to reveal the explanation.
Short Explanation
Terraform only knows about things in its state. To Terraform, that bucket is a stranger squatting on the name it wants. You introduce them with an import, and the 'create' turns into 'already managed'.
Full Explanation
Terraform decides to create an object when configuration declares a resource that has no corresponding entry in state. If an object with the same unique name already exists outside Terraform, the provider's create call fails, which is what an already-exists error means. Because the existing bucket matches the intended configuration, the fix is to bring it under management: an import block with the bucket's address and ID makes the next plan show an import instead of a create, and the reviewed apply records it in state. Refresh-only mode updates state for objects that are already tracked; it never discovers untracked objects, so the create would still be planned. -replace forces replacement of an object Terraform already manages; for an address with no state entry it simply plans a create again, and it would never delete an unmanaged bucket. terraform state rm removes an existing state entry, and there is none here, so nothing changes and the conflict remains. Exam caveat: if the hand-made object differs from configuration, the import plan will also show updates, which must be reviewed before applying. Operational check: after applying the import, run terraform plan and confirm it reports no changes for the bucket.