Why do local Terraform dry runs create governance risk when teams rely on shared infrastructure policies?

Why This Matters for Security Teams

Local Terraform dry runs are useful, but they are not governance controls. When teams rely on shared infrastructure policies, the real decision point is not whether a plan looks clean on a laptop. It is whether that plan is evaluated against the same state, variables, secrets, and policy engine that will approve or reject the change in production. That distinction matters because drift creates false confidence.

Security teams should be especially cautious when local runs bypass central checks for identity, secrets handling, or policy-as-code enforcement. NHI governance failures often start as “temporary” workflow shortcuts, then persist until a privileged change lands outside review. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both underscore how hidden identity sprawl and inconsistent control enforcement undermine governance. In practice, many security teams discover the gap only after a local-approved change has already reached shared infrastructure with broader blast radius.

That risk is amplified when the organisation treats Terraform as a developer convenience rather than a governed change system. A dry run can omit remote state locks, environment-specific variables, production secrets, and mandatory policy checks, so the output is only as trustworthy as the local context behind it. The NIST Cybersecurity Framework 2.0 emphasises repeatable governance and control consistency, not optional validation paths.

How It Works in Practice

Shared infrastructure policies work best when the same enforcement path is used every time a change is proposed, whether it comes from a laptop, a pull request, or an automated pipeline. A local Terraform dry run becomes a governance risk when it cannot faithfully reproduce the production control plane. That usually happens because the local environment lacks the authoritative state file, reads a different variable set, cannot access short-lived secrets, or skips the policy checks that the central pipeline enforces.

For Terraform workflows, the practical control model should look more like this:

• Local plans are permitted for developer feedback, but never treated as approval.
• Remote state and state locking remain the source of truth for current infrastructure.
• Policy-as-code is evaluated in the central path, not reimplemented ad hoc on endpoints.
• Secrets and cloud credentials are issued through governed, short-lived mechanisms rather than copied into local shells.
• Exceptions are recorded centrally so the same change is not judged by two different standards.

This is where identity and policy governance intersect. The same discipline described in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs applies to infrastructure automation: access must be tied to the workload or pipeline that is actually authorised to act, not to whoever happens to run a dry run locally. Current guidance suggests using central policy engines and explicit approvals for production-impacting changes, with Terraform plans treated as evidence, not a control.

That approach aligns with NIST CSF 2.0 governance expectations and with common policy-as-code practices such as OPA-based checks embedded in CI. When the local and central paths diverge, teams lose comparability, and comparability is what makes control enforcement auditable.

These controls tend to break down when teams allow local execution to read cached credentials or stale state because the dry run then stops being a preview and starts becoming an unaudited alternate deployment path.

Common Variations and Edge Cases

Tighter policy enforcement often increases friction for developers, so organisations have to balance speed against assurance. That tradeoff is real, especially in fast-moving platform teams that want immediate feedback before they open a pull request. Best practice is evolving, but there is no universal standard for allowing local dry runs to substitute for central governance.

Some teams handle this by limiting local runs to syntax validation and non-authoritative diffing, while reserving policy decisions for the shared pipeline. Others provide a mirrored sandbox with production-like state, variables, and access boundaries, though even that should be treated as representative, not authoritative. If a team uses environment-specific secrets, ephemeral credentials, or approval gates, the dry run must not bypass those controls just because it is convenient.

One important edge case is multi-team shared infrastructure where different repositories target the same state or cloud account. In those environments, a local dry run can appear safe while still conflicting with another team’s queued change, causing failed applies or policy collisions. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because auditors usually care less about whether a plan existed locally and more about whether the organisation can prove a consistent, central approval trail. The operational answer is to keep the system of record in the pipeline and let local runs remain advisory only.

Related resources from NHI Mgmt Group

• Why does standing access create governance problems for cloud and infrastructure teams?
• Why do standing privileges in cloud infrastructure create outsized risk for engineering teams?
• Why do Terraform module dependencies create operational risk when teams do not track version constraints and usage?
• Why do manually created infrastructure stacks create governance risk in cloud delivery pipelines?