What is the difference between managing Terraform code in Git and controlling who can deploy it to cloud infrastructure?

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 This Matters for Security Teams

Terraform in Git controls the source of truth for infrastructure changes, but it does not control who is allowed to turn those changes into live cloud actions. The real security boundary is the deployment path: build systems, runners, service accounts, cloud roles, and approval gates. That distinction is where many organisations fail, because code review and branch protection can look strong while the pipeline identity still has broad production access.

NHI Management Group research on the 2024 Non-Human Identity Security Report shows that 88.5% of organisations say their non-human IAM practices lag behind or only match their human IAM maturity, which helps explain why infrastructure-as-code governance and deployment governance are often conflated. The issue is especially visible in CI/CD abuse scenarios, including the CI/CD pipeline exploitation case study, where the code was legitimate but the deployment trust chain was not. Current guidance in NIST Cybersecurity Framework 2.0 supports separating governance of assets from governance of access.

In practice, many security teams discover this only after a pipeline credential is reused, a runner is over-scoped, or a merge approval becomes an implicit production override.

How It Works in Practice

Managing Terraform code in Git is primarily a software engineering control. It covers versioning, peer review, traceability, and change approval before code is merged. Controlling who can deploy it is an identity and runtime-authorisation control. That layer decides whether a particular automation identity can assume a cloud role, write to a target subscription or account, create resources, or modify production state. These are related, but they are not the same control plane.

A practical model separates the two with distinct identities and checks. Git access should govern who can change code. Deployment access should govern which workload identity can execute that code, where it can execute, and under what conditions. That often means:

• protected branches and mandatory reviews for Terraform source changes
• short-lived pipeline credentials rather than shared static secrets
• environment-specific service accounts with tightly scoped permissions
• separate approval workflows for non-production and production applies
• runtime policy checks that validate target account, resource type, and change context

This is where NHI governance becomes operational. The identity that runs Terraform is a workload identity, not a person, and it should be managed as such. Guidance in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that non-human identities need issuance, rotation, revocation, and ownership discipline across the full lifecycle. In standards terms, the access review and least-privilege expectations in NIST SP 800-207 Zero Trust Architecture fit well with this separation.

These controls tend to break down when a single shared deployment role is reused across environments because one compromise then becomes a cross-account or cross-subscription deployment path.

Common Variations and Edge Cases

Tighter deployment control often increases operational overhead, so organisations have to balance change velocity against blast-radius reduction. The tradeoff is worth it, but it is not free. Teams that deploy frequently often want a single pipeline identity for simplicity, yet that pattern makes it harder to prove who changed what, who approved the release, and which environment was actually authorised to receive it.

There is no universal standard for this yet, but current guidance suggests treating Terraform plan and Terraform apply as different trust events. A plan may be reviewed in Git, while apply should be gated by an ephemeral identity bound to the destination environment and the specific task. This becomes even more important in multi-cloud or hybrid estates, where inconsistent access patterns create drift and increase the chance of privilege sprawl. NHIMG research on the Azure Key Vault privilege escalation exposure and the 230M AWS environment compromise shows how quickly secrets and workload identities can become a deployment path rather than a guardrail.

For teams adopting agentic automation, the problem compounds because an autonomous system may generate changes, chain tools, and request deployment without behaving like a static human operator. That is why emerging practice increasingly combines policy-as-code, just-in-time credentials, and workload identity proofs such as OIDC rather than long-lived secrets. The practical goal is simple: Git should control the change request, while the deployment identity controls whether that request is allowed to touch production.

Related resources from NHI Mgmt Group

• What is the difference between managing MongoDB Atlas manually and managing it with infrastructure-as-code workflows?
• What is the difference between controlling privileged access and simply managing logins?
• What is the difference between unified governance across a cloud organisation and managing each project separately?
• What is the difference between stack-level visibility and code-level review for Terraform governance?