Private corporate batches delivered onsite across Bangalore, 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 as an estate rather than a language: inventory layouts that separate environments cleanly, variable precedence traced end to end so surprising values stop being mysteries, collection pinning and private hubs, Vault-managed credentials that survive CI and key rotation, and the performance settings — forks, pipelining, fact caching, execution strategy — that decide how long a fleet-wide run takes. Sessions run live against real hosts, including the failure paths most courses avoid: partial runs, non-idempotent modules, delegation, and what happens when a playbook meets an estate that does not match its assumptions.
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 automation for Bangalore platform, network and infrastructure teams — inventory design, collections, Vault and fleet-scale runs — 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 happens at your own office. Sessions are most often requested at sites in Whitefield, along the Outer Ring Road between Bellandur and Marathahalli, at Manyata Tech Park and in Electronic City, and we schedule one site per day — crossing between the Silk Board and KR Puram stretch in peak hours costs an hour that belongs in the lab. You provide the room, a screen and outbound network access to your cloud accounts and internal Git; we bring the trainer, the agenda, the lab repositories and the assessment. A 09:30 start suits teams that hand over to US counterparts in the evening; groups supporting European hours usually prefer 11:00 to 18:00. All sessions are scheduled in IST (UTC+5:30) and planned around your code-freeze and release windows rather than through them. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and multi-batch bookings are quoted as a single engagement.
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 that turns operational intent into code that can be reviewed, versioned and re-run. A control node holds the playbooks, the inventory and the credentials; managed hosts need nothing beyond an SSH daemon and a Python interpreter, or WinRM and PowerShell on Windows. Because there is no agent, the unit of trust becomes the connection itself — which means access control for Ansible is, in practice, SSH key management and sudo policy written carefully.
Since ansible-core separated from the community package, content ships as collections: modules, roles, plugins and filters versioned and distributed together, resolved from Galaxy or from a private hub inside your network. A playbook is still YAML and tasks are still idempotent, but the dependency question — which collection version supplies a module, and where that version is pinned — is now part of designing an estate rather than an afterthought discovered during an upgrade.
Running Ansible against hundreds of hosts also makes it a performance problem. Forks, SSH pipelining, persistent connections, fact caching, the free versus linear strategy and the cost of gathering facts on every play decide whether a fleet-wide run finishes in four minutes or forty. Layered over that are the safety controls a change-controlled environment needs: check mode with diff, tags, host limits, serial batching, and the block, rescue and always structure that determines what a half-failed run leaves behind on a production host.
Automation debt has become a hiring category of its own. Most organisations passed the point where hosts, containers and cloud accounts could be managed by hand years ago, and what filled the gap was a mixture of Ansible, shell and institutional memory. The memory leaves; the playbooks stay.
Ansible is where that debt usually lives, because it is the tool teams adopt first — it works against existing servers, existing SSH access and existing credentials, so it can be introduced without a platform migration or a budget line. The consequence is that most Ansible estates were never designed. They grew. Inventories are flat, roles are copied rather than composed, secrets sit in a file someone means to move, and nobody is certain what a run against production will actually change.
What organisations hire for now is the repair skill, not the introduction skill: restructuring inventory so environments are separable, making runs safe to execute under change control, moving credentials into Vault without breaking CI, and putting playbooks under lint and Molecule tests so the next contractor cannot quietly regress them. In Bangalore that demand is amplified by team turnover — an estate typically outlives three sets of the engineers who wrote it.
How the pieces actually fit: control node, inventory, connection plugins and the configuration precedence that decides which ansible.cfg is in force. The split between ansible-core and the community package, and why that split changes how you version automation.
Topics: Control node, managed hosts and the SSH execution path · ansible.cfg precedence and the settings worth changing · ansible-core versus the community package · Collections as the unit of distribution · Command-line entry points: ansible, ansible-playbook, ansible-inventory, ansible-doc · Where Ansible is the wrong tool
The design decision that determines whether an estate stays maintainable at five hundred hosts. Static inventory in a directory, groups and groups of groups, host and group variables, and dynamic inventory plugins sourced from cloud accounts.
Topics: Inventory directories, multiple sources and merge behaviour · Groups, groups of groups and behavioural parameters · host_vars and group_vars layout that maps to environments · Host patterns, --limit and targeting mistakes that reach the wrong fleet · Dynamic inventory plugins for AWS, Azure and GCP · Inventory caching and keyed groups
Writing automation that a change advisory board would sign off. Play structure and ordering, handlers and notification, check mode with diff, tags and limits, serial batching, and the block, rescue and always structure that defines what a partial failure leaves behind.
Topics: Play structure, ordering and pre/post tasks · Handlers, notify, listen and flush_handlers · Check mode, --diff and modules that do not support them · Tags, --limit and --start-at-task · serial, max_fail_percentage and rolling execution · block / rescue / always and deliberate failure handling
Where values come from and which one wins. Role defaults, inventory variables, play and task variables, registered results, extra-vars, gathered facts, custom and external facts — and the precedence order that explains almost every surprising Ansible behaviour.
Topics: The full precedence order, worked through in a live example · Role defaults versus role vars · Registered variables, when to use set_fact, and scoping · Gathered facts, custom facts and fact caching · Jinja2 templating, filters, tests and lookups · Debugging with ansible-inventory and --extra-vars
Structuring automation so it can be shared and upgraded. Role layout, defaults, dependencies and the search path; then collections — building them, versioning them, pinning them in requirements.yml, and serving them from a private hub rather than the public internet.
Topics: Role directory structure, defaults, meta and dependencies · include_role versus import_role and when the difference matters · Building a collection: galaxy.yml, namespaces and semantic versioning · requirements.yml, pinning and reproducible installs · Private Galaxy hub or artifact repository as the source of truth · Refactoring a monolithic playbook without a big-bang rewrite
Keeping credentials inside the automation workflow instead of beside it. Encrypting files and single values, multiple vault IDs for separate environments, rekeying, and the unattended decryption problem every CI pipeline eventually hits.
Topics: encrypt, decrypt, view, edit and rekey · encrypt_string for single values inside plain files · Multiple vault IDs and per-environment keys · Vault password files, scripts and CI secret stores · Rotation without breaking running pipelines · Where Vault stops and a secrets manager begins
The practice that separates an estate that can be changed from one nobody dares touch. Syntax checking, ansible-lint rule sets, molecule scenarios against containers or cloud instances, and a CI gate that blocks a merge rather than reporting after the fact.
Topics: --syntax-check, --list-tasks and dry-run discipline · ansible-lint profiles and suppressing rules honestly · Molecule scenarios, drivers and the converge/idempotence/verify cycle · Testing idempotency as an assertion, not a hope · Wiring role tests into a CI pipeline · Managing test matrices across OS versions
Operating Ansible for an organisation rather than yourself. The settings that decide fleet-run duration, then AWX or Tower: projects wired to source control, job templates and surveys, credentials, RBAC, logging and backup — so an application team can run automation without shell access to the control node.
Topics: forks, SSH pipelining and persistent connections · Fact caching and gather_subset · linear, free and host_pinned strategies · AWX/Tower projects, inventories, credentials and job templates · Surveys, workflows and scheduled jobs · RBAC, LDAP integration, logging and backup · Writing a custom module or filter plugin when nothing fits
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake an inherited INI inventory of 200 hosts and restructure it into a directory layout with three environments, keyed dynamic groups and provable targeting.
Add check mode, diff output, tags, host limits and serial batching to a playbook that currently runs everywhere at once, then prove each control works.
Decompose a 400-line playbook into roles, package them as a versioned collection, publish it and consume it from a second repository with a pinned requirement.
Encrypt an environment's credentials with a dedicated vault ID, run unattended from CI, then rotate the key while the pipeline keeps running.
Add molecule scenarios to two roles, make the idempotence step genuinely pass, and wire lint plus tests into a CI job that blocks the merge on failure.
Profile a slow run across a large inventory, tune forks, pipelining, fact gathering and strategy, then publish the result as an AWX job template with RBAC.
Ansible work in Bangalore concentrates in three distinct places. The telecom and networking R&D sites around Manyata Tech Park and the Outer Ring Road use it for network device automation and lab provisioning, where installing an agent on a router or a traffic generator was never an option in the first place. The banking and insurance GCCs around Embassy Golf Links, Bagmane Tech Park and the Bellandur stretch run it against hardened RHEL and Oracle Linux fleets, because a security review that will not approve a new daemon on a production host will still approve SSH and a controlled sudo policy. And the silicon and EDA houses across Bangalore — where compute is licensed per seat and shared between teams — use Ansible to configure grid nodes without adding anything permanent to the node image.
The hiring picture follows from that. Bangalore platform-engineering specs almost never ask for Ansible on its own; they ask for Ansible with Terraform and one cloud, and the screening questions are about inventory layout, variable precedence and check-mode safety rather than YAML syntax. The teams that call for training are rarely starting from zero. They have inherited three hundred playbooks written by rotating contractors — flat inventories, shell tasks impersonating modules, credentials in Git — and need the estate made maintainable by people who will still be there next year. That is where most private Ansible batches in Bangalore begin, and it is a different starting point from a greenfield introduction.
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.
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.
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.