State drift in Terraform

WHAT THIS TESTS This checks whether you understand that IaC tools track resources through a state file, what happens when reality and that record diverge, and how to remediate it with discipline.

A GOOD ANSWER COVERS Terraform records the resources it manages in a state file representing its view of the world. State drift occurs when the real infrastructure no longer matches that recorded state. The classic cause is an out-of-band change: an engineer fixes something quickly in the cloud console, an autoscaling action alters an attribute, or another tool modifies a resource. Now the live resource differs from what state and code say. To detect drift, run a plan, which refreshes against live resources and reports differences, or use refresh-only and drift-detection features; in teams this runs on a schedule in CI so drift surfaces early. To remediate, decide intent: if the manual change was a mistake, run apply to converge the infrastructure back to the code's desired state. If the change should be preserved, update the configuration to reflect it, or import an unmanaged resource into state. Prevent recurrence by restricting console write access, enforcing change through IaC, and using remote state with locking.

COMMON WRONG ANSWERS Hand-editing the state file, which is dangerous and easily corrupts state. Confusing drift with an ordinary code change. Ignoring drift until an apply unexpectedly destroys a manual fix. Not protecting console access, so drift recurs. Believing refresh alone fixes infrastructure rather than just updating state's record.

LIKELY FOLLOW-UPS How does refresh differ from apply? Why use remote state with locking? When do you import versus re-apply? How would you detect drift continuously across many stacks?

ONE CONCRETE EXAMPLE An engineer manually opens a security group port in the console during an incident. The next plan shows the open port as a diff against code. The team decides the change was unintended, runs apply to close it, and adds scheduled drift detection in CI so future manual edits surface within hours instead of being discovered during the next unrelated deploy.