Private corporate batches, live online cohorts and 1-on-1 mentoring in the OPA policy engine end to end — Rego, the decision API, bundles, decision logs and integration points — 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 OPA around the evaluation model rather than around snippets: how a Rego document is built, why a rule returns undefined instead of false, how partial and complete rules differ, and what the engine is actually doing when a policy is slow. Sessions cover the language in depth, then the runtime — decision API, bundles, decision logs, deployment modes — and finish on real integrations with Kubernetes admission, Envoy external authorisation, Terraform plan evaluation and CI, with every policy written test-first using the built-in test runner and profiler.
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 OPA that means a trainer who has run it in production — the OPA policy engine end to end — Rego, the decision API, bundles, decision logs and integration points — 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 OPA batchOPA — the Open Policy Agent — is a general-purpose policy engine that answers authorisation and configuration questions for other software. It is a single Go binary or library that accepts a JSON input document, evaluates policies written in a declarative language called Rego against that input plus any data it holds, and returns a JSON decision. It does not enforce anything itself: the calling service asks, OPA answers, and the service acts on the answer.
That separation is the whole point. Instead of authorisation logic being scattered through application code, admission webhooks and pipeline scripts in five different languages, the decision is expressed once in Rego and served through a stable interface. OPA can run as a sidecar, as a host-level daemon, as a library linked into a Go program, or compiled to WebAssembly and evaluated inside another runtime — the policy is identical in every case, which is why the same rule set can gate a Kubernetes admission request, an Envoy service call, a Terraform plan and a CI check.
The engine has more to it than the language. Bundles distribute signed policy and data from a central server on a polling interval. Decision logs stream every decision, its input and its result, to a remote endpoint — which is what makes an OPA deployment auditable rather than merely functional. Partial evaluation can compile a policy against known inputs to produce a residual policy or even a database filter. And the built-in test runner, coverage reporter and profiler mean Rego is treated as code that is tested and measured, not configuration that is hoped to be correct.
Authorisation was the last piece of infrastructure to be pulled out of application code. Networking, secrets, configuration and observability all became platform concerns years ago; permission checks stayed hard-coded, duplicated per service, and impossible to audit centrally. OPA is the project that made externalised policy practical, and it is now a graduated CNCF project embedded in Kubernetes admission control, service meshes, API gateways, CI systems and cloud provisioning pipelines.
The pressure is coming from two directions at once. Platform teams need to enforce guardrails on hundreds of workloads without reviewing every manifest by hand, and auditors want to see that a control is applied uniformly and that every decision was recorded. A policy engine with a decision log answers both questions in a way that a wiki page of standards never can.
The hard part is Rego. It is a declarative language with unusual semantics — everything is a document, rules are partial by default, variables are bound rather than assigned, and negation has safety rules that surprise people who arrive from Python or Go. Engineers who can write a working rule are common; engineers who can structure a policy library, test it properly, reason about its evaluation cost and debug a rule that silently returns undefined are not.
Why authorisation logic ends up duplicated in five languages, and what changes when the decision is externalised. OPA's request/response model, the strict separation between decision and enforcement, and an honest look at where a policy engine is the wrong answer.
Topics: Policy decoupling and the decision-versus-enforcement split · OPA's input, data and result documents · Where OPA fits: admission control, service authorisation, CI, provisioning · Deployment modes: sidecar, daemon, library, WebAssembly · OPA compared with hand-written checks and with commercial policy products · What OPA deliberately does not do · Installing OPA and running the first decision from the CLI
The mental model that makes the rest of the language obvious. Everything is a document; rules define values in that document; variables are bound rather than assigned. Scalars, objects, sets and arrays, references, iteration, and why a rule returns undefined rather than false.
Topics: Packages, imports and the data document hierarchy · Scalars, objects, arrays and sets · Rules, rule bodies and expression conjunction · Complete rules versus partial rules and partial objects · Variables, unification and safety · References, iteration and the anonymous variable · Undefined as a first-class result, and default rules
The constructs that separate a working rule from a maintainable policy library. Comprehensions, user-defined functions, aggregation, the built-in function catalogue, negation and its safety constraints, and structuring output so a policy returns reasons rather than a bare boolean.
Topics: Array, set and object comprehensions · User-defined functions and their argument semantics · Aggregates: count, sum, max, min and the every keyword · Negation, not, and the safety rules that constrain it · The built-in catalogue: strings, regex, JSON, time, crypto, networking · Returning structured decisions — reasons, violations and messages · Composing policy packages and importing across them
Rego is code, so it gets a test suite. The built-in test runner and naming conventions, table-driven cases, mocking data and inputs, coverage measurement, and the tools for the moment a rule silently returns nothing — trace output, evaluation explanations and the profiler.
Topics: opa test: conventions, fixtures and table-driven cases · Mocking input and data in tests, and with-clauses · Coverage reporting and what an uncovered rule means · Tracing and explanation modes for a failing evaluation · Diagnosing undefined results and safety errors · opa fmt, linting and policy style · Running policy tests in CI as a merge gate
OPA as a running service. Starting the server, the data and policy REST endpoints, structuring a stable decision interface for callers, and the operational surface: health, status, metrics and configuration. Also how OPA behaves under load and what a decision actually costs.
Topics: opa run in server mode and its configuration file · The Data API and the Policy API · Designing a decision interface callers can depend on · Versioning a policy interface without breaking clients · Health, status and readiness endpoints · Prometheus metrics and instrumentation · Authentication and authorisation of the OPA API itself
Where policy input that is not in the request comes from, and how policy reaches the engine in the first place. Pushing data versus pulling it, http.send and its caching, bundle distribution with signing and delta updates, and the decision log stream that makes a deployment auditable.
Topics: Base data versus virtual documents · Pushing data through the API versus bundle-delivered data · http.send, caching and the risks of external calls at decision time · Bundles: layout, building, serving and polling · Bundle signing and verification · Delta bundles and large data sets · Decision logs: format, masking sensitive fields, and shipping to a remote endpoint
The same engine in four very different places. Kubernetes admission control, Envoy external authorisation for service-to-service calls, structured configuration checks over Terraform plans and manifests in CI, and embedding OPA directly in a Go application or compiling policy to WebAssembly.
Topics: Kubernetes admission control and the AdmissionReview input · Envoy ext_authz and request-level authorisation with OPA · API gateway and application authorisation patterns · Evaluating Terraform plan JSON before apply · Conftest and structured configuration checks in CI · Embedding OPA as a Go library with the rego package · Compiling policy to WebAssembly for other runtimes
What breaks at scale. Reading the profiler, understanding rule indexing, shaping data so lookups are cheap, and using partial evaluation to precompute policy against known inputs — including compiling a policy down to a database filter. Then upgrades, rollout safety and observability.
Topics: Profiling evaluation and reading the output · Rule indexing and why data shape determines cost · Partial evaluation and residual policies · Compiling policy to data filters for query-time authorisation · Memory footprint and large base documents · Safe rollout: dry-run decisions, staged bundles and rollback · Upgrades, Rego version migration and deprecations · Observability: metrics, decision log analysis and drift
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a policy library that returns violation objects with reasons rather than a bare allow flag, using comprehensions, functions and partial rules.
Write a table-driven test suite to full coverage, then debug three deliberately broken rules using only trace and explanation output.
Run OPA in server mode, expose a versioned decision endpoint, secure the API, and call it from a real application under load.
Build a signed bundle, serve it, roll a policy change to a running agent, and ship masked decision logs to a sink that can answer an audit question.
Enforce the same rule against a Terraform plan in CI, a Kubernetes admission request, an Envoy authorisation call and an embedded Go evaluation.
Profile a policy that misses its latency budget, restructure the data and rules for indexing, apply partial evaluation, and prove the improvement.
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.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
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.
| 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.