Notifications
Clear all
Topic starter
11/06/2026 11:27 pm
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.
NHIMG editorial — based on content published by ControlMonkey: SRE vs DevOps in IaC environments
Questions worth separating out
Q: How should security teams govern identities used in IaC pipelines?
A: Security teams should treat IaC pipeline identities as privileged execution accounts, not generic automation.
Q: Why do IaC environments increase governance pressure on IAM teams?
A: IaC environments compress provisioning, deployment, and remediation into code-driven workflows, which moves access decisions into the delivery chain.
Q: What breaks when drift detection is not tied to identity governance?
A: Drift detection becomes a noisy configuration tool instead of a governance control.
Practitioner guidance
- Map pipeline identities to privileged actions Inventory every CI/CD and GitOps identity that can create, modify, or destroy infrastructure, then classify each one by environment, scope, and approval path.
- Separate deploy and repair authority Give release automation only the access required to deploy, and reserve incident remediation permissions for a distinct role with explicit change logging.
- Use drift as an access-control signal Treat unexpected infrastructure drift as evidence of an over-broad identity or bypassed control, and force investigation before the next release proceeds.
What's in the full article
ControlMonkey's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific tool references for Terraform, CloudFormation, Ansible, GitHub Actions, and GitLab CI in delivery workflows
- The article's role-by-role comparison of SRE and DevOps responsibilities across SLIs, SLOs, MTTR, and deployment frequency
- ControlMonkey's own description of drift detection, audit visibility, and GitOps-based automation in Terraform pipelines
- Career-path and role-definition content that is useful context but not the governance analysis this post focuses on
👉 Read ControlMonkey's analysis of SRE vs DevOps in IaC environments →
SRE vs DevOps in IaC environments: what IAM teams miss?
Explore further
12/06/2026 8:07 am
IaC governance is really identity governance with code attached. The article correctly shows that SRE and DevOps collaboration depends on automation, but the deeper issue is who gets to change production through that automation. Once infrastructure is codified, the critical control shifts from manual admin approval to pipeline identity, repository permissions, and policy gates. The practitioner takeaway is that IaC must be governed as a privileged access system, not just a deployment method.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: What is the difference between DevOps delivery authority and SRE operational authority?
A: DevOps delivery authority is about approving and running changes into environments, while SRE operational authority is about stabilising and restoring services under production conditions. They should not be identical by default. Separating them reduces the chance that one identity can both ship risky changes and repair the consequences without independent oversight.
👉 Read our full editorial: SRE vs DevOps in IaC environments: where governance diverges
