Task 6.4: Manage resource drift and Terraform state

• Aterraform plan -compact-warnings

  Incorrect

  That only shortens warnings; the normal plan would still propose reverting the changes.

• Bterraform output -json

  Incorrect

  output prints root output values, not differences in resources.

• Cterraform plan -refresh-only

  Correct

  A refresh-only plan shows what changed in the remote objects outside Terraform and proposes no infrastructure changes.

• Dterraform validate

  Incorrect

  validate never contacts the infrastructure.

Refresh-only mode is for looking at drift on its own, separately from configuration changes.

• AAdd a moved block from aws_instance.web to aws_instance.app

  Correct

  A moved block tells Terraform that the existing object now belongs to the new address, so it updates state instead of replacing the object.

• BAdd an import block that imports the instance's ID to aws_instance.app

  Incorrect

  Import blocks bring in objects that Terraform does not manage yet. This instance is still recorded under aws_instance.web, which has no block any more, so the plan still destroys that address.

• CAdd lifecycle { ignore_changes = all } to the renamed block

  Incorrect

  ignore_changes stops Terraform from updating arguments that changed; it does not connect a new address to an existing object.

• DRun terraform apply -refresh-only before planning the rename again

  Incorrect

  A refresh-only apply updates state from the real objects; the instance stays recorded under the old address, so the rename still plans a replacement.

Addresses identify objects in state; a moved block changes an address without touching the object.

• AReal objects changed outside Terraform and no longer match state

  Correct

  Drift is when real objects change outside of Terraform's workflow and differ from what Terraform recorded and configured.

• BProvider versions have changed since the last terraform init was run

  Incorrect

  That is a dependency change, not drift.

• CThe configuration was edited but not yet applied

  Incorrect

  Pending configuration changes are normal plan input, not drift.

• DState has moved to a new backend

  Incorrect

  That is a state migration.

Drift happens outside Terraform; plans are how you notice it.

• Astate mv destroys the object and creates it again at the new address

  Incorrect

  state mv changes only addresses in state; it never touches the remote object.

• BA teammate who plans and applies between the merge and the state mv can replace the object

  Correct

  Until state mv runs, the new configuration and the old state disagree, so a plan made in that gap destroys the object at the old address and creates a new one at the new address.

• Cstate mv works with local state files, so the shared remote state keeps the old address

  Incorrect

  The state subcommands work with remote state too; the risk is about timing, not storage.

• Dstate mv holds the state lock until the next apply completes

  Incorrect

  Like other state subcommands, it holds the lock only while it runs.

A CLI refactor changes the configuration and the state in two separate steps. The documentation asks the engineer to coordinate with coworkers so that nobody plans or applies in between.

• AThe upgrade requires importing every resource again into a fresh state

  Incorrect

  Importing binds objects that Terraform does not track yet; an upgrade keeps the existing bindings.

• BNew Terraform versions are generally backward compatible with snapshots written by earlier ones

  Correct

  The state documentation says new Terraform versions are generally backward compatible with state snapshots produced by earlier versions.

• CThe snapshots must first be converted by pushing them with terraform state push

  Incorrect

  state push uploads a local state file to the configured backend; it does not convert anything.

• DThe dependency lock file must be regenerated before 1.12 can read the state

  Incorrect

  The lock file records provider selections; it plays no part in reading state.

Upgrading the CLI does not mean rebuilding state. Plan with the new version as usual; the existing snapshots stay the source of truth.

• AOnly when someone runs terraform validate

  Incorrect

  validate never reads infrastructure.

• BWhen the provider sends Terraform a notification each time an object changes

  Incorrect

  Providers do not push notifications; Terraform asks during refresh.

• COnly after an apply has finished

  Incorrect

  The plan already shows the changes found during refresh.

• DDuring the refresh at the start of the plan

  Correct

  By default Terraform refreshes state from the real infrastructure before planning, which reveals changes made outside Terraform.

Every normal plan starts with a refresh; that is where drift shows up.