Private corporate batches, live online cohorts and 1-on-1 mentoring in policy-as-code as an operating model — admission control, constraint libraries, rollout governance and audit evidence — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Open Policy Agent as a governance system rather than a plugin: how admission control actually intercepts a request, what failure policy costs in an outage, how a constraint library is versioned and distributed across clusters, and how a rollout moves from audit to warn to enforce without stopping delivery. Sessions cover Gatekeeper constraint templates and constraints, the same policy shifted left into CI, exemption and break-glass design, and turning audit results and decision logs into evidence that maps onto CIS, PCI and internal control sets.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Open Policy Agent that means a trainer who has run it in production — policy-as-code as an operating model — admission control, constraint libraries, rollout governance and audit evidence — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Open Policy Agent batchOpen Policy Agent is the CNCF policy engine that organisations use to turn written standards into controls that execute. The engine itself takes a JSON input, evaluates declarative Rego policy against it, and returns a decision. What makes Open Policy Agent an organisational tool rather than a library is everything built around that: admission controllers that apply the decision to every object entering a Kubernetes cluster, bundle servers that distribute one signed policy set to hundreds of agents, and decision logs that record every answer given, so a control can be demonstrated rather than asserted.
Run as a governance programme, it changes what a standard is. 'Containers must not run as root' stops being a paragraph in a wiki that a reviewer may or may not check, and becomes a constraint that rejects the deployment, or — during rollout — records a violation without blocking it while teams remediate. The same policy definition can run in a developer's pre-commit hook, in the pull request pipeline, and at admission, so a team finds out at the earliest point rather than at deploy time, and nobody can route around the control by taking a different path to the cluster.
The organisational work is in the parts that are not the engine. Someone has to own the constraint library and version it. Rollout has to move from audit to warn to enforce without breaking existing workloads. Exemptions have to exist, be time-bounded, and be visible. Failure policy has to be chosen deliberately, because a webhook that fails closed can stop a cluster and one that fails open silently disables the control. And the audit and decision-log output has to be shaped into evidence that maps onto whatever framework the organisation is measured against.
Kubernetes made a manual review model impossible. When a platform team supports fifty namespaces across several clusters and every team deploys many times a day, no human is reading manifests, and the guardrails either execute automatically or they do not exist. Pod Security Policy was removed, which forced the question on every cluster operator who was still relying on it, and admission-time policy engines became the standard answer.
Regulatory and customer expectations moved at the same time. Security questionnaires and audits now ask for evidence that a control applies to every workload, not a sample — and a policy engine with audit results and decision logs answers that directly, with a timestamped record of each object evaluated and each decision returned.
What organisations get wrong is the programme rather than the technology. Installing Gatekeeper takes an afternoon; the failures come later. Constraints are rolled out in enforce mode and break a release, so the whole thing is disabled. Exemptions are granted as permanent namespace exclusions and nobody tracks them. The webhook fails closed during an upgrade and the cluster stops accepting workloads. The policy library is copied between clusters and diverges. Running policy-as-code so that it survives its first outage and its first angry delivery team is the skill this course is built around.
The programme before the tooling. What a control is, where it can be enforced, and the trade-offs of each enforcement point. Who owns policy in a platform organisation, how a standard becomes a rule with a testable assertion, and the failure patterns that kill policy programmes in their first quarter.
Topics: From written standard to executable control · Enforcement points compared: developer machine, CI, admission, runtime · Open Policy Agent's role and what it deliberately leaves to the caller · Ownership: platform, security and delivery team responsibilities · Guardrails versus gates, and choosing which controls block · Why policy programmes get switched off, and how to prevent it · Defining a policy catalogue with severity and enforcement intent
How a request actually reaches a policy decision. The API server request path, authentication and authorisation before admission, mutating and validating webhook phases, ordering and re-invocation, timeouts, and the failure policy decision that determines whether a webhook outage blocks the cluster or silently disables the control.
Topics: The API server request path and where admission sits · Mutating versus validating admission webhooks and their ordering · AdmissionReview request and response objects · Failure policy, timeouts and cluster availability risk · Scoping with namespaceSelector, objectSelector and rules · Pod Security Admission and where it complements policy engines · Migrating from Pod Security Policy · Gatekeeper compared with vanilla Open Policy Agent plus kube-mgmt
The Kubernetes-native packaging of the engine. Constraint templates and the constraints that instantiate them, enforcement actions, the audit controller that evaluates objects already in the cluster, and replicated data for policies that need to see beyond the object under review.
Topics: Installing and configuring Gatekeeper · Constraint templates: schema, parameters and the embedded Rego · Constraints, match criteria and enforcement actions · The audit controller and violation status on constraints · Config resources and replicating cluster data for context-aware policy · External data providers and their failure modes · Mutation with Gatekeeper: assign, assign metadata and ordering · Reading and reporting violation status at scale
The artefact a platform team actually maintains. Repository layout, testing constraint templates before they reach a cluster, semantic versioning, distribution to many clusters, adopting and adapting community libraries, and deprecating a policy without breaking every consumer.
Topics: Repository structure for templates, constraints and tests · Testing constraint templates in CI against fixture objects · Versioning policy and communicating breaking changes · Distribution: GitOps, bundles and Helm packaging compared · Adopting the Gatekeeper community library without inheriting its assumptions · Per-environment parameterisation without forking policy · Deprecating and retiring a constraint safely
Admission is the last line, not the first. Running the identical policy against manifests, Helm output and Terraform plans in CI and pre-commit, so a violation is a failed check on a pull request rather than a rejected deployment — and the developer experience work that decides whether teams accept it.
Topics: Conftest and evaluating structured configuration in CI · Rendering Helm and Kustomize output before evaluation · Evaluating Terraform plan JSON against the same policy set · Pre-commit hooks and local feedback loops · Keeping CI and admission policy identical rather than merely similar · Failure messages engineers can act on without asking the platform team · Handling the gap between what CI can see and what admission can see
The part that determines whether the programme survives. Introducing a control in audit mode, measuring the existing violation population, burning it down with the owning teams, then moving to warn and enforce. Then the exemption process, break-glass, and the incident procedure for when policy itself is the outage.
Topics: Dry-run, warn and deny as rollout stages · Measuring the existing violation population before enforcing anything · Burn-down planning with delivery teams · Exemption design: scoped, time-bounded, owned and reviewed · Break-glass and emergency bypass with an audit trail · Detecting and preventing permanent exclusions · Change management for policy: review, staging clusters and rollback · Incident response when the admission layer is the outage
Turning enforcement into something an auditor accepts, and running it beyond one cluster. Audit results and decision logs as evidence, mapping controls onto recognised benchmarks, reporting to non-engineering stakeholders, and the federation and management-plane options once the cluster count grows.
Topics: Audit results, decision logs and what each proves · Masking sensitive fields in decision logs · Shipping decisions to a SIEM and querying them · Mapping constraints to CIS Benchmarks, PCI DSS and internal control sets · Coverage reporting: which controls apply to which workloads · Multi-cluster distribution and configuration drift detection · Management planes and commercial control planes such as Styra DAS · Policy engine alternatives and honest comparison
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy an admission webhook, simulate an outage under both failure policies, and measure exactly what stops working in each case before choosing one.
Write parameterised constraint templates, instantiate them per environment, and use the audit controller to find every existing violation in a populated cluster.
Build a versioned constraint library with CI tests, distribute it to two clusters through GitOps, and prove they cannot drift apart.
Render Helm output and a Terraform plan, evaluate both against the identical policy set in a pull request, and confirm the cluster agrees.
Take a real control from audit through warn to enforce across a populated cluster, burning down violations with owners and hitting zero unplanned rejections.
Produce a compliance evidence pack from live audit results and decision logs, mapped to a benchmark, with the uncovered controls stated honestly.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.