Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Ansible 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 Ansible around the transport and the change window rather than around YAML: SSH and WinRM authentication including Kerberos and CredSSP, become under a sudoers policy you did not write, inventory that models an estate you do not own, and the check-and-diff discipline that turns a play into a change record. The syllabus carries the operational edges that decide outcomes on mixed RHEL and Windows estates — idempotency failures that only appear on the second run, delegation and run_once across tiers, serial execution during a live shift, rescue paths that leave a host in a known state, and Vault rotation when the credential belongs to a customer. Twenty years across DevOps, SRE and security engineering sits behind the material, and every concept is demonstrated against running hosts rather than slides.
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 Ansible that means a trainer who has run it in production — agentless configuration management across Pune's plant-floor, BFSI and services estates — 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.
Onsite delivery covers Hinjewadi, Baner, Balewadi, Kharadi, Yerwada, Magarpatta, Viman Nagar and Talawade, and we travel out to the Pimpri-Chinchwad and Chakan industrial belt for plant-IT teams — you provide the room, network and a screen, we bring the trainer, agenda, lab repositories, assessments and certificates. Sessions run 09:30 to 17:30 IST; Pune teams carrying a US or EMEA handover usually take the 08:00 to 13:00 IST half-day format instead so the afternoon overlap stays free, and where a manufacturing client works to a shift calendar we schedule around changeover weeks rather than through them. For labs each attendee needs two throwaway hosts with sudo and outbound SSH — free-tier cloud instances or local VMs both work, and we walk the team through provisioning them. Invoicing is in INR with GST against your PO from the Indian entity; travel to the outer industrial belt is quoted separately from the training fee.
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 Ansible batchAnsible is an automation engine, and the property that decides where it is allowed to run is that it installs nothing. A run starts on a control node, opens an SSH session — or a WinRM session against Windows Server — copies a small module to the target, executes it, reads back JSON and closes the connection. No daemon is left listening, no service is added to the boot sequence, and no certificate has to be renewed on a host somebody else owns. On plant-adjacent servers whose uptime is counted in production shifts, and on hosts sitting behind a change advisory board, that is frequently the entire reason the tool is approved when a permanently resident agent is refused.
The second consequence of the push model is that a run is bounded. Nothing happens until an engineer invokes it, against a host pattern they typed, for as long as the play takes. That maps cleanly onto a maintenance window: check mode with diff output produces the predicted change set before the window opens, limits and tags narrow the blast radius inside it, and serial execution controls how much of a tier is touched at once. Playbooks are YAML, tasks call idempotent modules, and a second pass over an already-correct estate reports no change — which is what makes a rerun during an incident defensible rather than reckless.
Where Ansible gets hard is not syntax. It is inventory that has to model a naming convention somebody else invented, privilege escalation through a sudoers policy you cannot edit, credentials issued for a fixed window against an estate you do not own, and Windows targets where the connection itself — listener, authentication mode, Kerberos or CredSSP, certificate validation — fails long before any module gets the chance to run.
Pune's appetite for Ansible is not driven by the same thing that drives it in a pure product city. A large share of the hosts under management here sit inside the manufacturing corridor running out through Pimpri-Chinchwad, Chakan and Talegaon, where the owner of a server will refuse anything that adds a permanent process to a machine attached to a production line. Patching still has to happen, drift still has to be corrected, and the tool that gets signed off in that room is the one with nothing to install. That is a structural advantage rather than a fashion, and it is why local infrastructure teams keep buying depth in it.
The services and ER&D floors supply a second and larger pull. Engineers in Hinjewadi, Talawade and Hadapsar write automation against a customer's estate using credentials with an expiry date, so the skills that get people hired are the unglamorous ones: an inventory that survives a naming convention nobody documented, become semantics under a restricted sudoers file, secrets handled inside the repository when the client's own vault is out of reach, and a dry run whose output can be pasted straight into a change ticket.
The third pull is Windows. The banking and insurance captives around Kharadi, Yerwada and Magarpatta run estates where most managed hosts are Windows Server, and WinRM is where nearly every team loses its first week. Job specifications across the city reflect all three patterns — Ansible named beside RHEL, Windows Server administration and evidence of having worked under change control far more often than beside a container platform.
Why the push model is the one that clears a change advisory board. What actually happens on a managed host during a run, what is left behind afterwards, and how that compares with a pull model that must be versioned, patched and trusted permanently. Includes an honest account of where agentless is the weaker answer.
Topics: What a run does on the target host, step by step · Push versus pull, and what each asks of the host owner · Why no resident process changes the security conversation · Architecture: control node, inventory, modules, plugins, connection layer · Terminology used precisely — play, playbook, task, handler, role, collection · Where continuous enforcement makes a pull-based tool the better choice
Connectivity is where most first weeks are lost, and almost none of it is the automation's fault. Key and password SSH, a bastion in the path, connection plugins and timeouts, then the full Windows route — listener configuration, HTTP against HTTPS, NTLM, Kerberos and CredSSP — followed by privilege escalation on both platforms.
Topics: SSH with keys, agents, known_hosts and a jump host in the path · ansible.cfg, connection plugins, timeouts and pipelining · become, become_user and become_method under a restricted sudoers policy · WinRM listeners, ports and certificate validation · Windows authentication: NTLM, Kerberos and CredSSP · Reading a connection failure and deciding whose problem it is
The design decision that determines whether automation stays maintainable when the hostnames were invented by somebody else. Inventory as a directory rather than a file, groups and groups of groups, host and group variable layout, behavioural parameters, and dynamic sources from a cloud account or a read-only asset register.
Topics: Inventory as a directory, and the order files are loaded in · Groups, groups of groups and the patterns that select them · host_vars and group_vars layout, precedence and naming · Behavioural inventory parameters per host and per group · Dynamic inventory plugins, caching and constructed groups · Mapping an undocumented naming convention onto groups you can target
Before playbooks, the single-task run — the fastest way to answer a question about a fleet and the safest way to learn how targeting, modules and privilege interact. It is also the right tool during an incident, when a full playbook is more ceremony than the moment allows.
Topics: One task on one host, then a group, then a pattern · Choosing a module from the command line · Verbosity levels and reading module output as JSON · Fact gathering on demand and fact subsets · Ad-hoc runs against Windows targets · Recognising the point where an ad-hoc command should become a playbook
From a single play to something you would attach to a change ticket. Play targeting and ordering, the result contract every module returns, then the safety machinery: check mode, diff output, tags, limits, step and start-at-task, and serial execution sized to the window you were actually given.
Topics: Play targeting, ordering and the run of tasks · Check mode, and which modules honour it faithfully · Diff output read as a predicted change set · Tags, limits, step mode and start-at-task · serial, max_fail_percentage and rolling behaviour · Idempotency in practice, and the modules that quietly are not
The modules that appear in almost every real play, on both sides of a mixed estate. Files, packages, services, users and scheduled tasks on Linux, their Windows counterparts, and the recurring judgement call between a purpose-built module and command, shell, raw or script.
Topics: file, copy, template, lineinfile and blockinfile · package, yum, apt and dnf against win_package and chocolatey · service and systemd against win_service · user, group, cron and win_scheduled_task · command, shell, raw and script — and when each is defensible · Registry, feature and update modules on Windows Server
Most surprising behaviour is a precedence question in disguise. Every place a variable can be defined, the order in which they override one another, registered results, prompts and extra variables, gathered and custom facts, and fact caching when gathering is expensive across a slow link to a remote site.
Topics: Variable sources and the full precedence order · Registered variables and exactly when they are set · vars_prompt, extra variables and command-line overrides · Gathered facts, subsets and gather_timeout · Custom facts and fact caching · set_fact against defaults against vars, and why the difference matters
The constructs that separate engineering from scripting. Conditionals, loops and loop control, blocks with rescue and always, handlers and flush_handlers, include against import, lookups, and Jinja2 filters and tests — then failed_when, changed_when and controlled failure, because automation is judged on how it behaves when something is wrong.
Topics: when, loop, loop_control and until with retries · Blocks, rescue and always · Handlers, notify, listen and flush_handlers · include_tasks against import_tasks, and what that costs tags · Lookups, filters, tests and the map and select family · failed_when, changed_when, ignore_errors and the retry file
Structuring automation so another team can consume it without reading it. Role layout, defaults against vars, dependencies and duplication rules, the search path — then collections as the distribution unit, with namespaces, versions, requirements files and resolution from a private hub when there is no outbound path to Galaxy.
Topics: Role directory structure and what belongs in each folder · defaults, vars, meta and dependency behaviour · Role duplication, allow_duplicates and the role search path · Collections: namespaces, structure and versioning · requirements.yml and pinning content versions · Consuming collections inside an estate with no route to the public index
Handling secrets inside the workflow when the credential belongs to somebody else and expires on a date you do not control. Encrypting whole files and single values, multiple vault identities for different audiences, where the vault password lives once a pipeline is running the play, and rotation without a coordinated outage.
Topics: Creating, editing, viewing, rekeying and decrypting vault content · encrypt_string for single values inside a readable file · Vault identities and labels for multiple audiences · Where the vault password lives in a pipeline or an automation server · Separating secret from non-secret variables cleanly · Rotation procedure, offboarding, and proving old material is gone · Reading from an external secret store with a lookup instead
Nobody should discover a bug on a host attached to a production line. Lint and syntax gates on merge, Molecule scenarios against containers or virtual machines, assertion-based verification, a staging inventory that genuinely mirrors the target, and a rollback path that is itself automated and tested.
Topics: ansible-lint and yamllint as merge gates · Molecule scenarios, drivers and the converge and verify cycle · Assertions and idempotence checks in verification · A staging inventory that mirrors production rather than approximating it · Writing and testing a rollback path · What evidence to capture from a rehearsal run
Turning working playbooks into something another team can run safely without shell access or a copy of the repository. Projects wired to source control, job templates and surveys, credential types and injection, inventory sources, role-based access, workflow templates with approval nodes, and logging an auditor will accept.
Topics: Installing and configuring AWX or Automation controller · Projects, inventory sources and scheduled synchronisation · Job templates, surveys and credential injection · Organisations, teams and role-based access · Workflow templates, approval nodes and convergence · Logging, external aggregation, backup and restore
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a host list with an undocumented naming convention and build a directory inventory, constructed groups from facts, and group variables that survive the next hundred hosts.
Configure a WinRM listener, work through NTLM, Kerberos and CredSSP, fix certificate validation, and then run a real win_ module against the host.
Produce the predicted change set with check mode and diff, scope it with tags and limits, and assemble the output into evidence a reviewer will accept.
Decompose an inherited monolithic playbook into composable roles with defaults and dependencies, then package them as a collection with pinned versions.
Encrypt a customer-issued credential with Vault, run against it from a pipeline, then rotate the key and prove the previous material no longer decrypts.
Plan and execute a rolling patch across a production-adjacent tier using serial execution, handlers, blocks with rescue and an automated rollback, inside a fixed window.
Ansible lands differently in Pune than it does in a pure product city, because a large share of the estate it has to manage is not a web fleet — it is plant IT. The manufacturing corridor running from Pimpri-Chinchwad out through Chakan, Talegaon and Ranjangaon keeps RHEL and Windows Server hosts sitting close to production lines, and the people who own them will not accept a permanent agent on a box whose uptime commitment is measured in shifts. Ansible's agentless SSH-and-WinRM model is the specific reason it gets approved in those environments when a pull-based tool does not.
The second Pune audience is the services and ER&D floor across Hinjewadi, Talawade and Hadapsar, where engineers write Ansible against an estate the client owns, using credentials issued for a bounded window. That shapes what a batch must cover: inventory that models somebody else's naming convention, become semantics under a locked-down sudoers policy, Vault when the client's own secret store is off-limits, and check-mode discipline because a bad run is a customer incident rather than an internal one. The BFSI captives around Kharadi, Yerwada and Magarpatta add a third pattern — Windows-heavy estates where WinRM, not SSH, is the connection everyone gets wrong first. Local hiring reflects all of this: Pune listings ask for Ansible alongside RHEL and change-management evidence far more often than alongside a service mesh.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| 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.