What is the difference between aligning Terraform code and reconciling production state?

Why This Matters for Security Teams

Terraform drift is not just an infrastructure hygiene issue. It is an authorisation question: which version of reality is trusted when code and production disagree? In IaC-driven environments, the wrong answer can overwrite emergency fixes, preserve insecure changes, or mask an outage until the next deployment. That is why teams should distinguish source alignment from live-state reconciliation before they touch either environment.

The distinction matters because Terraform can be used both to document intent and to enforce it. When production is correct, aligning code protects the approved running state. When the code is the approved standard, reconciling production restores compliance. NHI Management Group has shown how often organisations lose visibility and control over non-human assets, including the Ultimate Guide to NHIs — What are Non-Human Identities, which makes drift harder to spot and harder to interpret.

Security teams often get this wrong by treating every difference as something to “fix” with a deploy, even when the live state was changed deliberately during an incident, migration, or vendor intervention. In practice, many teams discover the real cost of that assumption only after an approved production change has already been overwritten by the next automated apply.

How It Works in Practice

Aligning Terraform code means editing HCL, modules, variables, or data sources so the declared configuration matches the actual resource settings already running in production. This is a source-of-truth correction. Reconciliation means applying the Terraform plan so live infrastructure is brought back into line with the declared configuration. This is an environment-of-truth correction. The two actions may look similar in a change window, but they solve opposite problems.

A practical workflow starts with a drift review. Compare the current state, the remote state file, and the real resource configuration. If production was changed intentionally and is now the approved baseline, update code and state-management controls so the change is preserved. If production diverged accidentally or unsafely, use apply to restore the desired state. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, change management, and continuous monitoring as linked disciplines rather than separate tasks.

• Use code alignment when the deployed resource is the accepted source of truth and the repo is stale.
• Use reconciliation when the repository reflects the approved standard and production has drifted.
• Require change records for manual production edits so later drift is explainable, not ambiguous.
• Protect terraform state, because state corruption or stale locks can make both alignment and reconciliation unsafe.

For identity-heavy systems, the risk is amplified by secrets, service accounts, and API keys that can be created or rotated outside Terraform. The broader NHI problem is not theoretical; NHI Management Group notes that organisations frequently store long-term credentials in code and struggle with visibility across service accounts in the Ultimate Guide to NHIs — The NHI Market. These controls tend to break down when multiple teams edit the same infrastructure through separate pipelines because the authoritative state becomes unclear.

Common Variations and Edge Cases

Tighter reconciliation often increases operational friction, requiring organisations to balance drift prevention against the need for emergency fixes and fast recovery. That tradeoff is especially visible in regulated environments, where a temporary production change may be acceptable during incident response but must still be captured in code afterward.

There is no universal standard for this yet, but current guidance suggests treating the source-of-truth decision as a governance step before any automation runs. A few edge cases matter most:

• Hotfixes made directly in production may be correct short term, but they should trigger a follow-up code alignment task.
• Imported or legacy resources often need an initial reconciliation phase before the repository can be trusted as the baseline.
• Ephemeral test environments may tolerate more drift than production, but state handling still needs discipline.
• Shared modules can hide drift across many stacks, so a single plan may not reveal the full blast radius.

Best practice is evolving toward policy-backed drift detection, approval workflows for state changes, and explicit ownership of the authoritative source. That aligns with the wider NHI governance lesson that visibility and revocation discipline matter as much as configuration accuracy. In real operations, the hardest failures occur when teams assume Terraform will tell them which side is right, rather than deciding that before the first apply.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between Terraform code and Terraform state for governance?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?