TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Upgrade your AI knowledge with The CODE! Dive into a newsletter trusted by 300,000+ readers for its comprehensive, 5-minute snapshot of everything happening in AI. We navigate through hundreds of sources to bring you the latest AI trends, tools, and resources—so you can stay ahead, absolutely free.
IN TODAY'S EDITION
🧠 Use Case
How to Enforce Policy as Code in Your CI/CD Pipeline
👀 Remote Jobs
Supabase is hiring a Site Reliability Engineer
Remote Location: Worldwide
Canonical is hiring a Cloud Solutions Architect
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
Rusternetes - a complete ground-up reimplementation of Kubernetes in Rust that's currently passing 94% of official Kubernetes conformance tests (415 out of 441).
🧠 USE CASE
How to Enforce Policy as Code in Your CI/CD Pipeline
Most engineering teams enforce standards through documentation and code review.
A wiki page says containers should not run as root.
A pull request checklist asks reviewers to confirm resource limits are set.
and so on.,
This works as long as every reviewer remembers every rule on every review, which in practice is not how it goes. Standards drift, exceptions accumulate, and the rules that exist on paper stop matching what is actually running.
What is Policy As Code ?
Policy as Code is the practice of expressing those rules as code rather than as documentation, and having a tool evaluate every change against them automatically. Rules, a policy engine checks on every single pull request and rejects automatically if violated, the same way a unit test fails automatically if the logic it checks is broken. The policies live in version control alongside the infrastructure they govern, so they can be reviewed, versioned, and rolled back exactly like any other code change.
The Workflow
The point of catching policy violations in CI rather than at deploy time or in a later audit is that the cost of fixing a violation grows the longer it goes undetected. A violation caught while a developer is still looking at their own pull request costs a few minutes. The same violation caught after the change has reached production costs an incident, a rollback, and an investigation.
This loop puts the feedback exactly where the developer is already working. There is no separate compliance dashboard to check, no ticket to file. The PR either passes or it does not, and if it does not, the reason is visible right there in the same interface the developer is already using to make the change.
Popular Tools for Policy as Code:
Kyverno: Kubernetes native policy engine to validate, mutate, and generate configurations.
OPA (Open Policy Agent): A general purpose policy engine that works across various environments like Kubernetes, Terraform, and CI/CD pipelines.
Who is Responsible?
Security/Compliance Teams: Define the policies, making sure they align with organizational and regulatory standards.
DevOps Engineers: Implement and integrate these policies into CI/CD pipelines, enabling seamless enforcement during development.
How It Works?
Policy Engine: Tools like Kyverno or OPA serve as the policy engine, comparing builds against defined rules.
Ruleset Definition: Policies are defined in code (YAML, Rego for OPA), specifying what is allowed or disallowed.
Automated Enforcement: Integrated into CI/CD pipelines, ensuring that every change is validated against the policies before merging or deployment.
Rolling this out Without Breaking Existing Pipelines
Turning on enforcement against a pipeline that has never had policy checks before will surface every existing violation at once, and rejecting all of them on day one stalls every team mid deploy. The safer sequence is to run the policy engine in a non blocking, audit-only mode first, logging violations without failing the build. This gives teams visibility into what needs fixing and time to fix it before the check becomes a hard gate.
Once the audit output is clean, or the remaining violations have been explicitly reviewed and accepted as exceptions, switch the check to blocking. The same staged approach applies to adding new policies later: every new rule goes in as audit-only first, then graduates to enforced once the existing codebase has had a chance to catch up. This keeps the pipeline a tool teams trust rather than one they route around.
THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 300k+ devs, engineers at Meta, Google, OpenAI, and more.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
