Infrastructure as code coverage defines control, recovery and scale

At a glance

What this is: This is ControlMonkey’s checklist for IaC platforms, with the central finding that infrastructure outside code creates traceability, governance and recoverability gaps.

Why it matters: It matters because identity and access controls increasingly depend on infrastructure being codified, reviewable and drift-detectable across human, NHI and autonomous-adjacent operational programmes.

👉 Read ControlMonkey's checklist for evaluating infrastructure as code platforms

Context

Infrastructure as code is the practice of defining cloud resources in version-controlled files so they can be reviewed, tested and reproduced. The article argues that if a resource is not in code, it is harder to back up, harder to recover and harder to govern at scale, which turns configuration sprawl into a resilience problem.

For IAM teams, the connection is direct: unmanaged infrastructure often means unmanaged identity exposure as well, especially across cloud accounts, regions and services. The real issue is not just IaC coverage, but whether identity-related resources, approvals and drift checks are part of the same operational control surface.

Key questions

Q: How should security teams govern identity-related cloud resources in infrastructure as code workflows?

A: Security teams should require identity-related resources, such as permissions, policies and access paths, to move through the same version-controlled workflow as the rest of the stack. That means code review, state management, policy checks and drift detection all need to be enforced before deployment, not cleaned up afterwards.

Q: Why does unmanaged infrastructure create security and audit risk?

A: Unmanaged infrastructure creates security and audit risk because it breaks the chain of evidence between approved change and actual change. When resources exist outside code, teams lose traceability, repeatability and reliable rollback. That makes it much harder to prove control effectiveness or recover cleanly after an incident.

Q: How do teams know if drift detection is actually working?

A: Drift detection is working when it reliably flags differences between declared infrastructure and deployed reality, and those findings lead to timely ownership and remediation. If manual changes remain invisible, or alerts do not map to accountable teams, the control exists in name only.

Q: What is the difference between Terraform code and Terraform state for governance?

A: Terraform code describes the intended configuration, while Terraform state records the managed relationship between that code and real resources. Governance depends on both. Code without state cannot reliably support import, drift detection or recovery, and state without discipline can quickly become stale or misleading.

Technical breakdown

Why unmanaged infrastructure becomes a governance problem

When infrastructure is created or changed outside code, it escapes the review and traceability patterns that modern cloud governance depends on. That means changes are harder to approve, harder to reproduce, and harder to roll back when something breaks. In practice, the absence of a codified record also makes it difficult to prove who changed what, when, and under which policy constraints. For identity teams, this matters because IAM-related cloud resources such as roles, policies and access paths often follow the same unmanaged pattern as the rest of the stack.

Practical implication: require every identity-relevant cloud resource to be represented in a reviewable code path before it reaches production.

Terraform state, drift detection and recovery at scale

Terraform code alone does not guarantee operational fidelity. State is the mechanism that links declared infrastructure to what actually exists, and drift detection is what reveals when reality has diverged from the approved model. Without state, imports become manual and fragile; without drift detection, surprise changes can persist unnoticed until they affect availability or access. The article’s emphasis on auto-generating state reflects a basic control truth: recovery depends on trusted inventory, not just declarative intent.

Practical implication: validate that state files and drift controls are part of the same workflow as code generation, not an afterthought.

Policy enforcement and CI/CD for cloud change control

A mature IaC platform does more than produce files. It embeds policy checks into pull requests, automates plan execution, and ensures changes are evaluated before merge. This shifts control from post-change cleanup to pre-change prevention. For security and IAM practitioners, that is the difference between governing cloud change as a workflow and merely observing it after the fact. The article’s concern with bulk import and PR creation at scale is really about making governance scalable without adding custom scripting overhead.

Practical implication: treat policy checks, pull requests and automated drift detection as mandatory controls for cloud and identity change.

NHI Mgmt Group analysis

Infrastructure as code coverage is now an identity governance issue, not just a DevOps preference. Once cloud resources are created outside code, identity-adjacent controls lose traceability, approval context and repeatability. That weakens governance for permissions, access paths and audit evidence across the environment. Practitioners should treat unmanaged infrastructure as part of the identity surface, not a separate engineering nuisance.

Codified state is the control boundary between declared access and actual access. Terraform state does more than support tooling. It anchors what the organisation believes exists against what is really deployed, which is essential when security reviews depend on trusted inventory. Without that boundary, drift becomes an access and resilience problem at the same time.

Drift detection exposes a deeper operating assumption: that approved change and real change stay aligned. In cloud environments that assumption fails quickly when manual edits, ad hoc fixes or emergency changes bypass the code path. The implication is that governance programmes need to measure conformance continuously, not only during release cycles.

Full Terraform coverage is a named control gap we should start calling infrastructure visibility debt. The article describes the cost of unmanaged resources in terms of lost governance, lost security enforcement and slower recovery. That is not a tooling inconvenience. It is an accumulated control liability that grows every time a resource sits outside the managed estate.

For IAM leaders, infrastructure governance and identity governance are converging control problems. Cloud resources, policy objects and access dependencies increasingly move together, so a weak IaC posture becomes a weak IAM posture in practice. The practitioner conclusion is straightforward: if you cannot govern the infrastructure lifecycle, you cannot reliably govern the identity lifecycle that sits on top of it.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• More than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• For lifecycle controls and inventory discipline, see NHI Lifecycle Management Guide for the operational patterns that keep identity and infrastructure changes aligned.

What this signals

Infrastructure visibility debt: the longer cloud resources remain outside code, the more identity, security and recovery controls depend on tribal knowledge instead of verifiable state. That creates a programme-level blind spot that no amount of downstream review can fully compensate for.

Teams should expect IaC governance to converge with identity governance, especially where cloud policies, permissions and environment-specific resources are created together. The practical signal is simple: if your change process cannot show state, drift and approval in one flow, your control model is incomplete.

For teams aligning cloud governance with broader identity control objectives, the NIST Cybersecurity Framework 2.0 remains a useful reference point for identifying, protecting and detecting configuration drift before it becomes operational exposure.

For practitioners

• Inventory unmanaged identity-relevant resources Map resources that sit outside Terraform across accounts, regions and services, with special attention to IAM, storage, networking and container configurations that affect access paths.
• Make Terraform state part of the control plane Require every imported stack to produce accurate state before it is treated as governed, and block promotion when state is missing or incomplete.
• Enforce policy checks before merge Run plan and policy evaluation in pull requests so exceptions are visible before deployment rather than discovered during incident response.
• Wire drift detection to remediation workflows Alert on configuration drift automatically and route it to the team that owns the resource, so manual changes do not become accepted baseline.

Key takeaways

• Infrastructure that sits outside code weakens traceability, rollback and governance at the same time.
• Terraform state and drift detection are not tooling extras, they are the mechanisms that make cloud inventory trustworthy.
• Identity leaders should treat unmanaged infrastructure as a governance debt that directly affects access control and auditability.

Key terms

• Infrastructure as Code: Infrastructure as code is the practice of defining cloud resources in version-controlled files so they can be reviewed, tested and reproduced. It turns infrastructure change into a governed workflow, which is especially important when access, policy and recovery depend on consistency.
• Terraform State: Terraform state is the record that links declared configuration to the real resources under management. It is the reference point for imports, drift detection and recovery, and without it teams can no longer trust that code accurately reflects deployed reality.
• Configuration Drift: Configuration drift is the gap between what a system is supposed to look like and what is actually deployed. In cloud environments it often appears after manual fixes or untracked changes, creating hidden risk for governance, security and incident recovery.
• Unmanaged Resource: An unmanaged resource is a cloud object that exists outside the code and state process used to govern it. These resources are hard to review, hard to audit and easy to forget, which makes them a recurring source of control gaps in mature environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by ControlMonkey: a checklist for what to look for in an IaC platform. Read the original.