When Terraform reports drift, the immediate temptation is to make the diff disappear. Change the code, import the object, or apply the desired state. Any of those may be correct, but the difference itself deserves investigation first.
Drift is not one problem. It is a symptom produced by several different operating conditions.
Classify before correcting
A useful first pass separates drift into a few categories:
- Emergency intervention: someone changed production to restore service.
- Manual convenience: the supported path was slower or incomplete.
- Shared ownership: another controller legitimately manages the same field.
- Provider behavior: defaults, ordering, or computed values create a noisy plan.
- Configuration decay: the code no longer represents what the platform needs.
Each category points to a different repair. Automatically overwriting the environment can reverse an emergency fix. Automatically accepting reality can preserve an unsafe shortcut.
The diff is technical evidence. The cause is usually a process, ownership, or platform-design question.
Close the operational loop
Emergency changes are sometimes necessary. Make them visible, time-bound, and followed by reconciliation. Record who made the change and why, then either encode the new state or restore the declared state through the normal pipeline.
If the same type of manual change keeps returning, inspect the paved road. The module may be missing a needed option, the pipeline may be too slow for the operational requirement, or ownership may be split without a clear interface.
Design for single ownership
Terraform, autoscalers, operators, and cloud services can all write to the same resource. Decide which system owns each field. Ignore externally managed attributes deliberately and document that contract. Otherwise, two correct controllers can spend their time undoing each other.
Detect drift continuously
A scheduled plan gives drift a predictable discovery window. Route meaningful differences to an owner, suppress understood provider noise, and treat security-sensitive changes—public exposure, identity policy, encryption, logging—as higher-priority signals.
The long-term goal is not a permanently empty plan. It is an environment where unexpected change has an explanation, an owner, and a reliable path back to declared intent.