Private corporate batches, live online cohorts and 1-on-1 mentoring in one pipeline that proves quality and security together — test strategy, scanning, risk-based gates and release 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 DevSecTestOps as pipeline design under a time budget: deciding what runs on every commit, what runs nightly and what runs before release, tuning both test suites and security scanners until their signal is worth their minutes, and writing gate policy as code so blocking decisions are explicit and reviewable. Sessions cover the parts teams find hardest — flaky test quarantine, exploitability and reachability triage, waivers that expire, and routing defects and vulnerabilities into one owned queue — and end with a release evidence pack containing test results, SBOM, provenance and attestations produced by the pipeline itself.
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 DevSecTestOps that means a trainer who has run it in production — one pipeline that proves quality and security together — test strategy, scanning, risk-based gates and release 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 DevSecTestOps batchDevSecTestOps is an ugly name for a real and specific problem. Two shift-left movements arrived in delivery pipelines separately: security added composition analysis, static analysis, secret detection and container scanning, while quality added unit, integration, contract, functional and performance testing. In most organisations those two grew under different owners, with different tools, different dashboards, different severity vocabularies and different gates — and the result is a pipeline that takes an hour to run, blocks releases on findings nobody triages, and still ships defects.
The subject of DevSecTestOps is the design of a single delivery pipeline in which testing and security are one gate system rather than two competing ones. That means deciding what evidence a change must produce before it is allowed to move forward, at which stage each check runs, what each check costs in pipeline minutes, whether a finding blocks or reports, who owns the queue it lands in, how a waiver is granted and when it expires, and what the release artefact carries with it as proof — test results, coverage, an SBOM, provenance and signed attestations.
Done properly this is engineering, not policy. It requires a test strategy that fits the time budget, security tooling tuned so its false-positive rate is survivable, environments and test data that both testing and dynamic scanning can use, findings routed into one backlog with service levels by severity, and measurement across the whole thing — escaped defects, escaped vulnerabilities, mean time to remediate, pipeline duration and flake rate. The label may not survive; the pipeline design it describes is what teams actually have to build.
Regulation and customers now ask for evidence rather than assurances. Secure development frameworks, supply chain requirements, software bills of materials and customer security questionnaires all expect a release to be accompanied by proof of what was tested and scanned, produced automatically rather than assembled by hand before an audit. A pipeline that generates that evidence as a by-product is worth a great deal more than one that requires a person to collect it.
At the same time pipelines have become a bottleneck of their own. Adding scanners and test suites one initiative at a time produces the familiar outcome: a build that takes ninety minutes, developers who push to a branch and go do something else, quarantined flaky tests nobody owns, and thousands of unread security findings that are technically blocking but practically bypassed. Fixing that requires someone who understands both halves and can make trade-offs across them.
That combined role is genuinely scarce. Test automation engineers are rarely fluent in exploitability triage; application security engineers rarely own flake rate or test selection; platform engineers own the pipeline but not the findings. The demand is for engineers who can design the gate, negotiate the time budget, tune both toolchains, route findings to real owners and prove the whole thing improved something measurable.
Why quality and security automation collide, and what a combined gate has to assert. The current-state audit — every check, where it runs, what it costs in minutes, whether it blocks, who owns its output — followed by the design principles that make a single pipeline coherent instead of a stack of independently added tools.
Topics: How testing and security automation grew separately and what it cost · What a gate actually asserts, and the difference between blocking and informing · Pipeline time budget as a first-class design constraint · Ownership: who is accountable for a failing check at 6pm on a Friday · Feedback latency and developer behaviour · Auditing an existing pipeline honestly: minutes, signal, noise, bypasses · Designing stages: commit, merge, nightly, release
Choosing tests by the risk they retire per second of pipeline time. Unit, integration, contract and end-to-end proportions and the arguments for each shape, test selection and parallelisation, coverage read correctly, and the mutation and negative testing that reveals whether a suite is worth its runtime.
Topics: Test pyramid, testing trophy and choosing a shape deliberately · Unit and integration testing with real dependencies via containers · Contract testing between services and the consumer-driven approach · End-to-end tests: how few you can get away with, and which ones · Test selection, sharding and parallel execution · Coverage as a diagnostic, not a target; mutation testing as a check on the suite · Performance and load tests in the pipeline versus outside it · Accessibility and other non-functional checks that belong in the same gate
The problem that quietly destroys both halves. A pipeline nobody trusts gets bypassed, and flaky tests are the most common cause. Detecting flakiness, quarantine with real ownership and expiry, root causes in timing, shared state and test data, and measuring flake rate as a tracked engineering metric.
Topics: Detecting flakiness: reruns, historical analysis, flake rate per test · Quarantine policy: who owns a quarantined test and when it is deleted · Root causes: timing, ordering, shared state, external dependencies, test data · Deterministic environments and hermetic test execution · Retry policy and why blanket retries hide real failures · Pipeline reliability: infrastructure flakiness, runners and caching · Trust as a measurable property: bypass rate, green-build confidence
The security half placed by cost and signal rather than by vendor recommendation. Composition analysis and the supply chain, static analysis tuned to a survivable false-positive rate, secret detection including history, infrastructure and container scanning, and dynamic and API testing against a deployed build.
Topics: Software composition analysis, transitive dependencies and vulnerable-version reality · Static analysis: rule tuning, baselines and incremental scanning of the diff · Secret detection in the diff and in history, and what to do after a leak · Infrastructure as code and container image scanning, base image currency · Dynamic testing and API security testing against a running deployment · Where each check belongs by runtime cost and feedback value · False-positive economics: the rate at which a tool stops being read · Tool consolidation versus best-of-breed, assessed on findings you act on
The shared substrate both halves need. Ephemeral environments created per change, seeding realistic data without exporting production, masking and synthetic generation, service virtualisation for dependencies you cannot call, and running functional tests and dynamic security scans against the same deployed instance.
Topics: Ephemeral environments per pull request and their lifecycle · Test data management: masking, subsetting and synthetic generation · Data privacy obligations in non-production environments · Service virtualisation and mocks for third-party dependencies · Seeding state so both functional and security testing are meaningful · Running dynamic scans against the same environment as end-to-end tests · Environment parity: what must match production and what need not · Cost control and teardown discipline for ephemeral environments
The policy layer, written as code. What blocks and what only reports, severity mapped to real risk using exploitability and reachability, thresholds that do not ratchet into gridlock, waivers with owners and expiry dates, and break-glass paths that are logged rather than whispered.
Topics: Blocking versus reporting, and the cost of getting it wrong in each direction · Severity, CVSS, EPSS and exploitability — using them together · Reachability analysis and why most dependency findings are not exploitable · Threshold design: new findings versus total, and baseline debt handling · Policy as code with OPA or Conftest, versioned and reviewed · Waivers: justification, owner, expiry and periodic review · Break-glass and emergency release with an audit trail · Negotiating the gate with engineering, security and delivery leadership
Closing the loop. One queue for defects and vulnerabilities with deduplication, ownership routing and service levels by severity; a release artefact carrying SBOM, provenance and signed attestations; and the metrics that show whether the whole system is working — escaped defects and vulnerabilities, remediation time, pipeline duration, flake rate and bypass rate.
Topics: Aggregating findings across tools, deduplicating and assigning ownership · Service levels by severity and what happens when they are missed · Defect and vulnerability backlogs in one place, prioritised together · SBOM generation, provenance and signed attestations in the artefact · Release evidence packs assembled by the pipeline rather than by a person · Metrics: escape rate, remediation time, pipeline duration, flake rate, bypass rate · Reporting to audit and to customers from pipeline output · Rollout: sequencing the changes without stopping delivery
We rebuild the agenda around the tools you actually run.
Request a custom agendaMeasure every check in an existing pipeline for time, signal and ownership, then redesign the stage boundaries to a defended time budget and prove the new shape holds.
Rebalance a test suite towards unit and contract tests, add selection and parallelisation, and cut stage duration while proving the same failures are still caught.
Measure flake rate per test, quarantine the worst offenders with named owners and expiry, then fix three at root cause and classify the pattern behind each.
Place composition, static, secret, container and dynamic scanning across the right stages, tune the noisiest to a survivable false-positive rate, and record the coverage cost.
Write a gate policy covering test and security outcomes, run real findings through exploitability triage and the waiver process, and enforce it in the pipeline.
Produce a release artefact with test results, coverage, SBOM, provenance and signed attestations generated by the pipeline, plus the dashboard showing escape rate and remediation time.
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
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.
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.