Private corporate batches, live online cohorts and 1-on-1 mentoring in the Linux, networking, Git, scripting and cloud baseline every later course assumes — plus the assessment that proves a cohort has it — 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 builds the readiness diagnostic that decides how a corporate programme is sequenced: a domain-by-domain assessment across Linux, networking, Git, scripting, build and cloud, scored into a levelling matrix that produces a per-engineer profile and a cohort profile the buyer can act on. The teaching that follows is hands-on against real hosts — permissions and processes, systemd and journald, a request traced from DNS through TLS to HTTP, a genuine merge conflict resolved and a lost commit recovered — with every topic selected because a specific later course fails without it. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the banding and sequencing decisions.
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 DevOps Prerequisites that means a trainer who has run it in production — the Linux, networking, Git, scripting and cloud baseline every later course assumes — plus the assessment that proves a cohort has it — 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 DevOps Prerequisites batchDevOps prerequisites are the baseline competencies that every downstream course silently assumes and rarely teaches: Linux as an operating system rather than a set of memorised commands, networking to the level of TCP, DNS, HTTP and TLS, version control fluency in Git, enough shell and Python to automate a task, an understanding of how source becomes a build artefact, and working familiarity with virtualisation, containers and a cloud provider's core primitives. A Kubernetes course that begins with pods assumes namespaces, cgroups, process isolation and container images. A Terraform course assumes IAM, VPCs and credentials. Where those assumptions are wrong, the cohort splits within the first afternoon.
This page is about closing that gap deliberately, and about knowing where it is before a programme starts. Readiness is assessed rather than guessed: a short diagnostic covering each domain, scored against a levelling matrix, produces a per-engineer profile and a cohort profile. The cohort profile is the more useful of the two, because it determines whether one batch will work or whether the group needs banding into two, and it identifies which modules of the main programme need extra time.
The teaching itself is hands-on and unglamorous. Attendees work on a real Linux host rather than reading about one: permissions and ownership, processes and signals, systemd units and journald, package management, filesystem layout, text processing with grep, sed and awk. They trace a request from DNS resolution through a TCP handshake, a TLS negotiation and an HTTP exchange, and read it in tcpdump. They resolve a genuine merge conflict, rebase a branch and recover a commit they thought they had lost. Every DevOps prerequisites topic is chosen because a specific later course fails without it.
Corporate DevOps and cloud programmes fail on readiness far more often than on content. A batch of thirty engineers drawn from application development, support, testing and infrastructure will contain people who have never used ssh alongside people who maintain production Linux, and a single-track syllabus serves neither. The trainer slows down, the strong half disengages, the weak half still does not follow, and the feedback afterwards is that the course was simultaneously too fast and too basic.
The skills gap has widened for a structural reason. A generation of developers has worked entirely inside managed platforms and IDEs, and never needed to know what a process is, how a package is installed, or what happens between typing a hostname and receiving a response. That was a reasonable trade until the job description added a pipeline, a container image and a cloud account — at which point every one of those abstractions leaks.
For an L&D buyer this is a budget question. A five-day Kubernetes programme delivered to a cohort that cannot navigate a shell converts poorly and is usually repeated. Two days of assessed foundations in front of it changes the completion and application rate of everything that follows, and the assessment data itself is worth having — it tells you who to send on which track rather than sending everyone on all of them.
The module that makes the rest of the programme fit. A timed practical diagnostic across every domain, scored against a defined levelling matrix, producing an individual profile and a cohort profile. Ends with each attendee holding a personal gap list and the buyer holding a banding recommendation.
Topics: The levelling matrix: domains, levels and observable behaviours · Practical diagnostic tasks rather than multiple choice · Scoring, calibration and avoiding false confidence · Individual profiles and personal gap lists · Cohort profiles and the case for banding a batch · Mapping gaps to the modules of a downstream programme · Re-assessment and measuring movement
The single largest predictor of success in every later course. Not a command list — the model underneath: what a process is, what a file descriptor is, how permissions are evaluated, what init does, and where the system writes down what happened. Taught entirely at a shell on a real host.
Topics: Filesystem hierarchy and what lives where · Users, groups, permissions, ownership and the setuid bits · Processes, signals, exit codes and job control · systemd units, targets and dependency ordering · journald and reading logs when something fails · Package management on Debian and Red Hat families · Disks, mounts, inodes and running out of space · SSH: keys, agents, config and port forwarding
Enough networking to debug rather than to pass an exam. A single request traced end to end — name resolution, routing, the TCP handshake, TLS negotiation, the HTTP exchange — and observed in packet capture. Then the failure modes that dominate real incidents: DNS caching, MTU, timeouts, certificate chains and firewall rules.
Topics: IP addressing, subnets and CIDR in practice · Routing basics and reading a routing table · DNS: records, resolvers, caching and TTL · TCP handshake, connection states and timeouts · TLS: handshake, certificates, chains and SNI · HTTP methods, status codes, headers and keep-alive · Ports, firewalls, NAT and security groups · Diagnosis with dig, curl, ss, tcpdump and openssl
Git taught as a data model rather than as a set of commands, which is the only way the awkward situations become recoverable. Commits, trees and refs; branching and the difference between merge and rebase; and the recovery techniques that turn a frightening state into a routine one.
Topics: The object model: blobs, trees, commits and refs · Staging area, working tree and the three states · Branching, merging and rebasing — and when each is right · Resolving a real conflict rather than accepting theirs · Remotes, fetch, pull, push and tracking branches · reflog, reset, revert, cherry-pick and stash · Tags, releases and semantic versioning · Pull request workflow, review and branch protection
Automation as a baseline skill. Shell for gluing commands together, with the quoting, exit status and error handling that separate a script that works from one that fails silently. Then Python at the level needed to read, modify and debug the scripts that already exist in most estates.
Topics: Variables, quoting and word splitting · Conditionals, loops, functions and exit codes · set -euo pipefail and defensive scripting · Pipes, redirection and process substitution · Text processing with grep, sed, awk and jq · Python basics: types, collections, functions, modules · Reading files, calling APIs and handling JSON in Python · Virtual environments, pip and dependency basics
The path from source to a deployable thing, which every CI course assumes is already understood. What a compiler, a build tool and a dependency manager each do, what an artefact is, why it is versioned and immutable, and where it is stored before it is deployed.
Topics: Compilation, linking and interpretation · Build tools across ecosystems and what they have in common · Dependency resolution, transitive dependencies and lock files · Artefacts: JAR, WAR, wheel, package, container image · Versioning schemes and immutability · Repository managers and why builds should not reach the internet · Build once, deploy many — and what breaks when you rebuild per environment · Reading a failing build log
The runtime concepts underneath every platform course. Virtual machines against containers and what each actually isolates, images and layers, then the cloud primitives that Terraform, Kubernetes and every cloud course assume: identity and permissions, networking, compute, storage and how each is billed.
Topics: Hypervisors, virtual machines and the resource model · Namespaces, cgroups and what a container really is · Images, layers, registries and tags · Running, inspecting and debugging a container · Cloud identity: users, roles, policies and least privilege · Virtual networks, subnets, routing and security groups · Compute and storage primitives and their trade-offs · Regions, availability zones and the cost model
Everything applied once, then the sequencing conversation. Attendees build a small end-to-end system that touches every domain, are re-assessed against the same matrix, and leave with a personal learning path aligned to the programme they are about to start.
Topics: An end-to-end exercise crossing all six domains · Re-assessment against the entry matrix and measuring movement · Personal learning paths by role and target course · Which programme to take next and in what order · Habits that keep the baseline from decaying · Reference material worth keeping and what to ignore · Preparing an environment for the next course
We rebuild the agenda around the tools you actually run.
Request a custom agendaComplete a timed practical assessment across Linux, networking, Git, scripting, build and cloud, then receive a scored profile and a ranked personal gap list.
Diagnose a deliberately broken systemd service using journald, systemctl and file permissions alone, with no internet search allowed.
Trace a single HTTPS request from DNS resolution through TCP and TLS to the HTTP exchange, observed in dig, tcpdump, openssl and curl.
Create a genuine three-way conflict, resolve it by hand, then hard-reset away a commit and recover it from the reflog.
Take a repetitive task from your own work, automate it in shell or Python with real error handling, and hand it over with documentation.
Build a small system that crosses every domain — host, network, repository, script, artefact and container — then re-sit the diagnostic and measure the movement.
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
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.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| 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.