Broken Apply

Expanded Definition

A broken apply describes a deployment attempt that cannot complete cleanly because the infrastructure tool and the target platform disagree about desired state, ownership, or resource identity. In practice, the term is used most often in infrastructure as code workflows, where the apply phase is expected to reconcile code into real resources but instead fails, partially succeeds, or produces an inconsistent result.

The boundary matters. A simple syntax error stops execution before any meaningful reconciliation starts, while a broken apply happens when the plan may look plausible but the apply step collides with duplicate declarations, drift, conflicting modules, or other state mismatches. In Terraform, the problem is especially visible when the same resource is defined in more than one place, because the platform cannot safely determine which declaration owns the object.

Guidance-vs-consensus note: some teams use the phrase narrowly for hard apply failures, while others include partial or unreliable applies that leave infrastructure in an ambiguous state. NHIMG uses the broader operational sense when the result is an untrusted deployment outcome.

Examples and Use Cases

Broken apply usually appears during real delivery work rather than in abstract design discussions. Common examples include:

• Two Terraform modules attempt to manage the same cloud resource, so the apply process cannot resolve ownership cleanly.
• A resource was manually changed outside code, and the state file no longer matches the platform, creating a reconciliation mismatch during apply.
• Conditional logic in configuration produces duplicate or contradictory definitions for one target object, causing the platform to fail at execution time.
• A dependency is created in the wrong order, so one resource is applied before the object it depends on exists.
• A partially successful apply updates some components but leaves others behind, which can be more dangerous than a clean failure because operators may assume the change is complete.

The trade-off is that declarative tooling reduces manual drift, but only if ownership and state remain unambiguous. When teams layer modules, imports, and overrides too aggressively, the system may become harder to reason about than the environment it was meant to simplify.

Security Implications

Broken apply is not only a delivery reliability problem. In security-sensitive environments, it can delay patching, leave exposed services in place, or create a false sense that a control has been enforced when the deployment actually failed. The result is often a gap between the intended posture and the real one.

Partial apply outcomes are especially risky because they can create inconsistent access paths, broken network rules, or half-updated secrets and certificates. Those inconsistencies are difficult to notice if teams check only for job completion rather than for post-apply verification. In an identity-heavy environment, that can translate into stale privileges or unmanaged resources persisting longer than expected.

A common practitioner observation is that ownership conflicts are often treated as an engineering nuisance, but they become a governance issue when no one can confidently say which code path is authoritative for a resource. Once that ambiguity exists, auditability, rollback confidence, and change accountability all weaken together.

Domain and Governance Relevance

Broken apply matters most in infrastructure governance because it tests whether declarative control really matches operational control. If the platform cannot determine which definition owns a resource, then change management, drift management, and incident recovery all become less reliable.

For NHI-adjacent environments, the term becomes especially important when infrastructure provisions service accounts, workload identities, tokens, or certificates. A failed or partial apply can leave a machine identity created without the expected policy, rotation, or revocation settings, which changes the trust posture even if the deployment appeared mostly successful.

That is why broken apply should be read as a lifecycle integrity problem, not just a CI/CD failure. The security question is whether the environment can still prove that the code of record, the state of record, and the actual deployed object all agree. When they do not, the organisation inherits uncertainty about who or what is actually governed.

Related resources from NHI Mgmt Group

• Who is accountable when duplicate infrastructure definitions cause a broken apply or production drift?
• What is the principle of least privilege and how does it apply to NHIs?
• What is Zero Standing Privilege (ZSP) and how does it apply to NHIs?
• How does NIST AI RMF apply to Agentic AI and NHI governance?