TL;DR: Infrastructure-as-Code changes how SRE and DevOps teams share responsibility for reliability, delivery speed, and governance, while ControlMonkey frames drift detection and policy enforcement as part of that operating model. The real issue is not tooling preference but how codified infrastructure changes accountability, auditability, and operational control across cloud environments.
At a glance
What this is: This is a ControlMonkey analysis of how SRE and DevOps diverge in Infrastructure-as-Code environments, with the central finding that governance becomes a shared operating concern rather than an afterthought.
Why it matters: It matters because IaC collapses the gap between delivery and control, so IAM, IGA and cloud governance teams need clear ownership for change traceability, drift handling and audit evidence.
Context
Infrastructure-as-Code replaces manual infrastructure setup with code-driven provisioning and ongoing deployment. That shift changes more than speed: it changes how teams assign responsibility for reliability, change control and evidence in cloud environments.
The article uses SRE and DevOps as the two operating models that meet inside IaC. SRE is framed around reliability, incident response and error budgets, while DevOps is framed around delivery flow, automation and pipeline efficiency. In practice, the governance gap appears when the same automated change path must satisfy both release velocity and operational control.
Key questions
Q: What breaks when IaC changes are treated as delivery work only?
A: Governance breaks first, because the team optimises speed without proving that the deployed state still matches the approved state. That creates drift, weak audit evidence and inconsistent recovery assumptions. In IaC environments, delivery and control are inseparable, so a release process that ignores governance eventually undermines reliability as well as compliance.
Q: Why do SRE and DevOps measure different things in IaC environments?
A: They are optimising different control outcomes. DevOps metrics show how efficiently changes move, while SRE metrics show whether those changes preserve reliability under production load. In IaC, both are necessary because fast delivery without reliability creates operational fragility, and reliability without delivery discipline creates ungoverned change.
Q: What are the signs that IaC governance is failing in practice?
A: The clearest signals are drift between declared and live state, repeated exceptions in the pipeline, and changes that reach production without clear evidence of policy validation. If teams cannot explain why the runtime state changed, governance is already behind the automation layer.
Q: How should teams balance reliability and delivery speed in IaC programmes?
A: They should treat reliability controls as part of the release design, not as post-deployment cleanup. That means policy checks, drift detection and incident feedback all belong in the same operating model as CI/CD. Speed remains important, but it has to be bounded by verifiable control.
Technical breakdown
How IaC changes the control surface for SRE and DevOps
Infrastructure-as-Code turns infrastructure into versioned code, which means every environment change can be expressed, reviewed and deployed through the same pipeline mechanics as application code. That creates reproducibility, but it also shifts control from human ticketing and manual configuration toward repository, pipeline and policy enforcement points. In this model, reliability and delivery are no longer separate operating concerns. The same commit that accelerates release can also introduce drift, misconfiguration or a change that violates an availability objective. Practical implication: governance has to move closer to the code path, not the operations afterthought.
Practical implication: place policy and drift controls where the IaC change is authored, reviewed and promoted.
Why drift detection and policy enforcement matter in IaC governance
Drift occurs when the live cloud state diverges from the declared infrastructure state. In IaC environments, that matters because the declared state is supposed to be the source of truth for reproducibility, auditability and recovery. Policy enforcement adds a second layer by checking whether a planned change aligns with security or operational rules before deployment. Together, these controls help prevent hidden configuration changes, unauthorised exceptions and operational surprises that would otherwise bypass the code review path. Practical implication: treat drift and policy failures as governance signals, not just operational noise.
Practical implication: use drift and policy violations as triggers for review, not only as engineering alerts.
SLOs, MTTR and pipeline metrics measure different kinds of control
SRE and DevOps often use different measurements because they optimise different outcomes. DevOps metrics such as deployment frequency and lead time describe delivery throughput, while SRE metrics such as SLO attainment, error budgets and MTTR describe service reliability under production conditions. In IaC environments, the distinction matters because a fast pipeline can still be a weak control plane if it cannot prove that changes remain within reliability and compliance boundaries. Practical implication: measure delivery and reliability separately, then reconcile them in a single governance model.
Practical implication: separate delivery metrics from reliability metrics and require both before calling a rollout controlled.
Threat narrative
Attacker objective: The objective is to exploit the speed and authority of codified infrastructure changes to create operational disruption or governance blind spots.
- Entry occurs through the IaC change path, where code commits and pipeline-triggered deployments become the operational entry point for infrastructure change.
- Privilege escalation is expressed as broader infrastructure impact when a misconfigured or unreviewed IaC change expands access, availability risk or configuration drift across environments.
- Impact appears as degraded reliability, failed deployments or audit gaps when the live environment no longer matches the intended state.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
IaC governance is where SRE and DevOps stop being separate disciplines and become one control problem. Once infrastructure is codified, the question is no longer who owns the ticket. It is who can prove that the deployed state matches the approved state, and who can stop unsafe drift before it becomes operational reality. That shifts governance from process ownership to change-path control, which is the real dividing line practitioners should care about.
Drift detection is not a monitoring feature, it is a governance primitive. In IaC environments, drift is evidence that the declared control model and the live environment have diverged. That creates audit, resilience and accountability issues at the same time. Teams that treat drift as an SRE-only problem miss that it also marks a failure in configuration governance and change traceability.
Declared-state integrity: IaC only delivers governance value when the repository, pipeline and runtime state remain aligned. When that alignment breaks, automation no longer guarantees control, it accelerates variance. Practitioners should treat declared-state integrity as the named operating concept that joins reliability and compliance in the same workflow.
The SRE and DevOps split in IaC is really a split between outcome ownership and change-path ownership. SRE focuses on whether systems survive production conditions, while DevOps focuses on how changes move from commit to deployment. Mature programmes need both, but they need them under one governance frame so that speed does not outrun recoverability or accountability. The practical conclusion is that cloud governance belongs in the delivery pipeline, not beside it.
ControlMonkey's framing reflects a broader market direction: governance is moving into the automation layer. That is the right direction for IaC, because manual reviews cannot keep pace with codified deployment. The discipline now is to make policy, drift visibility and audit evidence part of the same workflow that ships infrastructure. Practitioners should expect the next wave of IaC governance to be judged by control fidelity, not tooling volume.
What this signals
Declared-state integrity: IaC governance succeeds when the repository, pipeline and runtime environment stay aligned. Once that alignment breaks, automation stops being a control accelerator and becomes a drift amplifier.
For practitioners, the takeaway is that SRE and DevOps are not competing functions in IaC. They are different lenses on the same control plane, so ownership, change traceability and policy enforcement must be designed together.
For practitioners
- Define shared ownership for the IaC control path Assign explicit responsibility for repository review, pipeline approval, policy enforcement and drift follow-up so SRE and DevOps do not split control and accountability.
- Instrument drift as a governance event Route configuration drift into review workflows because it shows the deployed environment has diverged from the declared source of truth.
- Separate reliability metrics from delivery metrics Track SLO attainment, MTTR and error budgets alongside deployment frequency and lead time so governance can see both control quality and shipping velocity.
- Require policy checks before IaC promotion Enforce policy validation at the point of merge or pipeline promotion so non-compliant infrastructure changes never reach runtime unnoticed.
Key takeaways
- IaC shifts governance into the delivery path, which makes change traceability and runtime alignment core control issues rather than administrative detail.
- SRE and DevOps optimise different outcomes, but both depend on the same declared-state model working cleanly across repository, pipeline and cloud runtime.
- Teams that want IaC to remain auditable and reliable need to treat drift detection, policy enforcement and reliability metrics as one operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | IaC governance depends on controlling who can change and promote infrastructure state. |
| GV.PO-01 — Policy | The article centres on codified governance decisions and policy enforcement in delivery workflows. | |
| Recommendation — Apply PR.AA-05 to restrict who can approve, promote and alter IaC-managed environments. Define and enforce IaC policy rules that govern change review, drift handling and runtime exceptions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | IaC drift and configuration control map directly to secure configuration discipline. |
| Recommendation — Use CIS-4 to verify that deployed cloud state matches approved IaC baselines. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | IaC relies on approved baselines that can be compared against runtime drift. |
| Recommendation — Maintain approved baselines for IaC-managed infrastructure and review deviations promptly. | ||
| MITRE ATT&CK | TA0004;TA0040 — Privilege Escalation; Impact | Mismanaged IaC changes can expand access and cause operational impact across cloud environments. |
| Recommendation — Map unsafe IaC change paths to privilege escalation and impact so detection focuses on change abuse. | ||
Key terms
- Infrastructure-as-Code Validation: Infrastructure-as-code validation checks whether deployment files are complete, consistent, and ready to apply before a push reaches production. In security terms, it reduces broken automation, prevents silent misconfiguration, and creates a control point where missing dependencies can be rejected early.
- Drift Monitoring: Drift monitoring tracks whether inputs, embeddings, or outputs are changing over time in ways that can degrade model performance. It is an early-warning control that helps teams spot behaviour shifts before they become visible business or security failures.
- Security service level objective: A security service level objective is a measurable target for remediation or control performance, such as fixing a class of issues within a defined window. It turns security work into an agreed operational expectation that can be tracked, escalated, and reviewed like any other delivery commitment.
- Shared-State Integrity: Shared-state integrity is the degree to which a common record, memory store, or case object accurately reflects what actually happened in a run. It is broken by overwrites, stale values, missing updates, or duplicated actions, and it is essential for diagnosing coordination failures in agentic workflows.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org