Aligning code means updating the Terraform source so it matches the actual running resource configuration. Reconciling production means applying the code so the live environment matches the declared state. The right choice depends on which state is authoritative. Teams should use code alignment when production is correct and reconciliation when the code is the approved standard.
Why Terraform Drift and State Reconciliation Are Not the Same Decision
The difference matters because Terraform is both a record of intent and a mechanism for changing live infrastructure. If teams confuse “make code match production” with “make production match code,” they can lock in drift, overwrite a deliberate emergency change, or normalise an unauthorized modification. The distinction is especially important in regulated environments and in environments where the infrastructure supports secrets, access paths, or other high-trust services. For a useful identity-adjacent perspective on how operational trust can be abused, see OWASP Non-Human Identity Top 10. In practice, many teams discover the cost of choosing the wrong side of the diff only after a production change has already become the new normal.
How Terraform Code Alignment and Production Reconciliation Work in Practice
Code alignment starts from the live environment. An operator inspects the deployed resource, confirms that the production configuration is the trustworthy one, and then updates Terraform source so the declared configuration reflects reality. This is a documentation and control-authority decision: the team is saying the running state is the truth that should be codified. That approach is common after an approved hotfix, a vendor-side change, or a manual intervention that was intended to persist.
Reconciliation starts from the repository or module source. The team treats Terraform as the desired state and applies it so the live environment is brought back under declaration. This is the standard choice when code is the approved baseline and production has drifted because of manual changes, inconsistent pipelines, or out-of-band edits. The value is governance consistency: what is reviewed, tested, and approved in code becomes what is running.
- Use code alignment when the live configuration was changed intentionally and should remain as-is.
- Use reconciliation when the drift is accidental, risky, or outside approved change control.
- Verify who authorised the production state before treating it as canonical.
- Confirm whether the drift affects security-sensitive settings such as network exposure, IAM bindings, or secret handling.
The practical problem is that both actions can be technically correct while serving opposite governance outcomes. A team can faithfully align code to a dangerous production state, or faithfully reconcile production to an outdated or incomplete codebase. The guidance breaks down when the source of truth is unclear, when multiple teams edit the same environment, or when the infrastructure is too dynamic for a single static declaration to represent operational reality.
When the Right Answer Depends on Authority, Drift, and Change Intent
Tighter infrastructure control often increases process overhead, requiring organisations to balance deployment speed against confidence in what is actually running. A pure “always reconcile” stance can erase legitimate emergency fixes, while a pure “always align code” stance can entrench configuration debt and make review meaningless. The right answer depends on whether the observed live state is an approved exception or an unapproved divergence.
Where the disagreement is only about timing, the issue is usually operational. Where the disagreement changes permissions, exposure, encryption, or network reachability, it becomes a governance and security question. That is why teams should distinguish between a temporary production variance that will be reverted and a durable production change that must be captured in code. This is also where consensus is weakest: some organisations allow carefully controlled drift windows, while others prohibit any production state that is not already represented in version control.
For teams managing infrastructure that supports machine credentials or automated access, the boundary matters even more because unmanaged drift can create hidden trust paths. Code alignment is appropriate when the authorised live configuration is already the accepted control state; reconciliation is appropriate when the repository is the approved standard and the live environment has diverged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Terraform drift is a secure-configuration issue on managed infrastructure. |
| Recommendation — Standardise approved configurations and detect drift before it changes production. | ||
| NIST CSF 2.0 | PR.IP-1 — Baseline Configuration and Change Control | The question is about choosing the authoritative baseline between code and runtime. |
| GV.PO-1 — Policy for Cybersecurity | Deciding which state is authoritative depends on policy and ownership. | |
| Recommendation — Define the authoritative baseline and reconcile deviations through change control. Set policy for when production may override code and when code must prevail. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Infrastructure drift can hide machine-access paths and unmanaged non-human assets. |
| Recommendation — Inventory infrastructure-linked identities and update ownership when runtime changes persist. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Unreviewed Terraform drift can preserve or expand access through altered accounts. |
| Recommendation — Hunt for unintended access changes when production state diverges from source. | ||
Practitioner Guidance
Decision rule: Treat production as authoritative only when the change was intentionally approved, still desired, and can be safely documented; otherwise treat the repository as authoritative and reconcile the environment back to it.
What to verify: Check whether the drift is security-relevant, who made it, why it exists, and whether reversing it would cause service instability or remove a legitimate exception.
Common mistake: Teams often use “align the code” as a quiet way to legitimise whatever happened in production, which can hide unauthorised changes and weaken change control.
Practitioner takeaway: The important judgement is not which direction is easier to apply, but which state the organisation is willing to defend as the approved baseline when auditors, incident responders, or service owners ask why the two ever diverged.
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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
