Storing Terraform code in Git governs versioning and collaboration, while deployment control governs whether that code can affect live systems. Mature teams keep these functions separate by using protected branches, approval workflows, and tightly scoped pipeline identities. That distinction matters because access to code does not automatically justify access to production.
Why Git-Based Terraform Collaboration Is Not the Same as Deployment Authority
Terraform in Git is about change control, reviewability, and keeping infrastructure definitions understandable over time. Deployment authority is about who can trigger changes against cloud resources, which is a separate trust decision with direct production impact. Teams often blur the two and assume that because a person can read, edit, or merge code, they should also be able to apply it. That shortcut weakens separation of duties and makes approval controls easier to bypass. For a broad governance view of that split between code control and operational control, NIST Cybersecurity Framework 2.0 is a useful reference point. In practice, many security teams discover the distinction only after a pipeline identity has been over-permissioned rather than after a code review process has been designed.
How Terraform Code Control and Cloud Deployment Control Work Together
Git answers questions such as who proposed the change, what changed, when it changed, and whether reviewers accepted it. That makes it the right place for source history, collaboration, and traceability. It does not, by itself, decide whether a change is safe to apply to a live subscription, account, or cluster. Deployment control sits one layer lower in the operational chain: the pipeline, runner, service principal, federated workload identity, or cloud role that can actually perform the apply action.
In a well-structured setup, these controls are intentionally separated:
- Developers can propose Terraform changes without being able to deploy them directly.
- Protected branches or merge checks enforce review before code becomes eligible for release.
- A separate deployment identity is used to apply infrastructure changes.
- That identity is scoped to the minimum resources and actions required.
- Approval and logging are attached to the deployment path, not just the repository.
This separation matters because Git controls intent, while deployment authority controls effect. A reviewed pull request may still be dangerous if the pipeline identity can create, delete, or reconfigure high-value resources without additional checks. The reverse is also true: a tightly controlled deployment path can still be undermined if unreviewed code is merged into the main branch and automatically applied. The strongest pattern is to treat Git as the system of record for desired state and the deployment mechanism as a gated execution path with its own permissions, evidence, and accountability. That is why mature teams often pair code review with change approval, but they do not let the review system substitute for cloud privilege management. Where this guidance breaks down is in emergency response paths, where temporary elevation may be needed and the exception process itself becomes the control.
Where the Separation Gets Tested in Real Environments
Tighter deployment control often increases release friction, so organisations must balance speed against the ability to prevent accidental or unauthorised infrastructure changes. The edge cases are usually organisational rather than technical. Shared service accounts, manually run apply commands, and overly broad CI/CD roles all collapse the separation the question is trying to preserve. Likewise, Git controls lose value if the repository is effectively a staging area for changes that can be deployed without meaningful review.
Common variations include:
- Plan-only pipelines: useful for visibility, but insufficient if no distinct approval step exists before apply.
- Manual deployment from a developer workstation: convenient, but it merges authoring and production authority in one person.
- Single pipeline identity for all environments: simple to operate, but it creates unnecessary blast radius.
- Emergency overrides: sometimes necessary, but they should be time-bound, logged, and reviewed afterward.
The main trade-off is that stronger control separation usually adds coordination overhead. That overhead is justified when infrastructure changes can affect production, identity systems, data stores, or network boundaries. If a team cannot clearly answer who may change the code versus who may execute it, then Git is being used as a collaboration tool while deployment is still governed informally, and that is where the control model becomes unreliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Management | Separates who can change code from who can execute production access. |
| GV.RM-3 — Risk Management Strategy | Supports governance decisions on separation of duties for infrastructure change. | |
| Recommendation — Apply PR.AC-4 to scope deployment identities separately from repository access. Define risk acceptance for deployment paths that bypass review or approval. | ||
| CIS Controls v8 | 6 — Access Control Management | Controls who may deploy infrastructure versus who may edit Terraform sources. |
| 8 — Audit Log Management | Deployment authority needs evidence beyond version history in Git. | |
| Recommendation — Use CIS Control 6 to restrict deployment permissions to approved identities. Log apply actions and review deployment audit trails independently from Git history. | ||
| NIST Zero Trust (SP 800-207) | A2 — Policy Engine and Enforcement Point Separation | Git approval and execution authority should be enforced by distinct control points. |
| Recommendation — Enforce separate policy decisions for code merge and infrastructure apply actions. | ||
Practitioner Guidance
What to prioritise: Treat repository permissions and deployment permissions as separate control planes. The first should determine who can shape desired state; the second should determine who can make the cloud accept it.
What to verify: Check that the identity used by the pipeline cannot be reused interactively, cannot approve its own changes, and cannot reach environments outside its assigned scope. If the same principal can both merge and apply, the separation is only cosmetic.
Decision rule: If a change can materially affect production, require at least one control outside the repository itself before execution. A code review without a deployment gate is collaboration, not release governance.
Practitioner takeaway: The important distinction is not where Terraform lives, but where execution authority is granted; once those are conflated, the organisation loses the ability to say who actually changed the infrastructure.
Related resources from NHI Mgmt Group
- What is the difference between managing human accounts and non-human identities?
- What is the difference between managing MongoDB Atlas manually and managing it with infrastructure-as-code workflows?
- What is the difference between generating Terraform modules automatically and managing cloud resources manually?
- What is the difference between managing AWS CodeBuild manually and managing it with infrastructure as code?
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
