Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Puppet 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 Puppet at the point where most inherited estates actually hurt: the resolved value. Sessions work through catalogue compilation and the fact and classification inputs that feed it, Hiera hierarchy design and lookup explanation, roles and profiles imposed on a codebase that grew by accretion, and control-repository and environment mechanics including isolation and pinned module versions. The syllabus carries the operational edges — certificate lifecycle and autosigning, rspec-puppet and noop verification before a change converges on a fleet, mixed Linux and Windows agent behaviour, report processors and corrective-change data as audit evidence, and the honest boundary between an enforced catalogue and an imperative Bolt plan.
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 Puppet that means a trainer who has run it in production — Puppet Enterprise, Hiera and compliance reporting for Pune's enforced-baseline 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 Kharadi, Yerwada, Magarpatta, Hinjewadi, Baner, Hadapsar and Talawade; you provide the room, a screen and network, we bring trainer, agenda, lab repositories, assessments and certificates. Hours are 09:30 to 17:30 IST, and Pune teams under change control typically schedule outside their monthly freeze window, since the most useful labs end in a real catalogue applied to a real node. Bring a redacted copy of your control repository and Hiera data if you can — working through your own hierarchy, your roles and profiles and your module versions is worth more than any prepared example, and we will sign an NDA first. Each attendee needs a server and two agent nodes, which we walk the group through provisioning on free-tier cloud or local VMs; where your estate mixes Linux and Windows we make sure at least one lab node is Windows so the agent differences are seen rather than described. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 Puppet batchPuppet is a configuration management system built around a compiled catalogue. An agent on each node wakes on a schedule, sends its facts to the Puppet Server, receives a catalogue — a dependency-resolved graph of the resources that node is supposed to have — enforces it locally and posts back a report of what it changed. For a team that inherited an estate rather than built it, the report is as valuable as the enforcement: it is a continuous, machine-generated statement of what state was applied, on which host, at which time, and that is a far stronger position in front of an auditor than a spreadsheet of intentions.
Most of the Puppet you meet in a long-lived estate is not the language, it is the layout. Code lives in a control repository whose branches map to environments and which a code-deployment tool renders onto the server; modules come from the public forge or an internal source, pinned in a Puppetfile; and the manifests themselves should hold almost no data, because environment- and node-specific values belong in Hiera, resolved through a layered hierarchy keyed on facts and node group. Roles and profiles give classification a stable interface, so a node is assigned exactly one role and everything else follows from data.
Around that sit the parts that break first and are documented least. The certificate authority decides whether an agent is trusted at all. Environment isolation matters the moment two environments disagree about a custom type. PuppetDB holds facts, reports and exported resources. PDK, puppet-lint and rspec-puppet exist so a change can be proved before it converges on thousands of nodes, and Puppet Enterprise adds console classification, role-based access control, orchestration with Bolt for imperative work a catalogue cannot express, and the reporting that turns enforcement into evidence.
Pune's Puppet estates are inherited, large and audited, and that combination sets the whole training brief. The banking, insurance and telecom-adjacent captives around Kharadi, Yerwada and Magarpatta chose continuous enforcement deliberately: a node that drifts overnight is corrected on the next run and the report proves the correction happened. Nobody replaces that lightly, so the engineers who arrive on those teams do not need to be sold configuration management — they need to be able to read a control repository written by people who have left, and to say with confidence why a particular resource appeared in a particular node's catalogue.
That pushes the valuable skills toward data and structure rather than syntax. Hiera hierarchies that answer lookups predictably, roles and profiles imposed on classification that grew by accretion, module upgrades proved with tests before they converge on a fleet, and environments that have quietly diverged brought back together. Windows makes it harder: a large share of the managed estate here is Windows Server, where the agent, the resource providers and the certificate story all behave differently from the Linux examples in most documentation.
The third driver is the coexistence question. Almost every Pune team running Puppet also runs a push-based tool, and the architecture forum wants a written boundary rather than a preference — the enforced baseline and its evidence on one side, sequenced orchestration and one-off remediation on the other. Local roles that name Puppet usually name compliance reporting or a migration assessment in the same paragraph.
Why a scheduled, pull-based agent that corrects drift is a different operational proposition from a tool somebody has to remember to run, and where that difference is worth its cost. An honest comparison with push-based and imperative alternatives, the open source and Enterprise split, and the coexistence position most estates should be arguing for rather than a migration.
Topics: Drift as an operational and audit risk rather than an inconvenience · Pull-based enforcement against push-based execution · Open source Puppet and Puppet Enterprise: what the licence actually buys · Recent release changes and deprecated features you will meet in old code · Where Puppet is the wrong answer, stated plainly · Drawing the boundary with a push-based tool already in the estate
What actually happens between an agent waking and a report landing: fact submission, node classification, catalogue compilation, graph resolution, local enforcement and the report cycle. Facter is covered in depth because facts are the input to every decision the catalogue makes, and installation covers both Unix-like and Windows agents so platform differences are seen rather than described.
Topics: Puppet Server, the agent run cycle and the ports and services involved · Catalogue compilation and dependency graph resolution · Facter: built-in facts, custom facts, external facts and facter.conf · Trusted facts and why they cannot be spoofed by a node · Installing Puppet Server and agents on Linux · Installing and running the agent on Windows Server · The report cycle and what the agent sends back
The declarative language taught from the position most engineers here are in: something is already written and it has to be understood before it can be changed. Resource types and attributes, relationships and ordering, classes, defined types and node definitions, plus the duplicate-resource and dependency-cycle errors that teach how the graph really behaves.
Topics: Resource declaration, types, titles and attributes · Core resource types and their Windows equivalents · Variables, data types and conditional expressions · Ordering and relationships: require, before, notify and subscribe · Classes, class parameters and defined resource types · Node definitions and what replaces them in a modern layout · Duplicate resource declarations, cycles and reading a compilation error
Getting configuration out of files and into data. EPP and the ERB templates you will still meet in older modules, expressions and built-in functions, type aliases and data validation so a bad Hiera value fails at compile time rather than on a thousand nodes, and custom functions where the built-in set genuinely falls short.
Topics: EPP templates, parameters and scope · ERB templates and how to migrate one safely · Expressions, operators and the built-in function library · Data types, type aliases and validating parameters · Writing functions in the Puppet language and in Ruby · Failing fast at compile time instead of failing late during enforcement
The module that decides whether an estate stays maintainable. How lookups actually resolve, hierarchy layers ordered by fact and node group, automatic parameter lookup, module data and defaults, merge behaviour when two layers both answer, and secrets held in an encrypted backend rather than in the repository. Explaining a resolved value is treated as a core skill, not a debugging trick.
Topics: hiera.yaml, layers and the global, environment and module hierarchy · Automatic parameter lookup and how a class parameter is filled · Fact-driven hierarchy design, including per-site and per-platform keys · First-found, hash and deep merge behaviour and when each is right · Module data and sensible defaults · Encrypted backends for secrets, and rotation · Explaining a lookup result end to end when the answer surprises you
Structure imposed on something already in production. What belongs in a profile against a component module, why a node gets exactly one role, and how to migrate classification without changing a single node's resolved catalogue on the day of the change. Custom resource types and providers are covered here because inherited estates usually contain one nobody understands.
Topics: The roles and profiles pattern and the classification interface it creates · Profiles, component modules and the boundary between them · Migrating node definitions and console classification into roles · Comparing compiled catalogues before and after a refactor · Custom resource types and providers, and when to retire one · Keeping a migration reversible while it is in progress
The mechanics behind everything the previous modules assumed. The code directory layout, a control repository whose branches become environments, a Puppetfile that pins module versions so a forge update cannot arrive by accident, environment isolation when two environments disagree about a type, and file server mount points and server tuning.
Topics: codedir, confdir, modulepath, vardir and ssldir · The control repository and branch-to-environment mapping · Puppetfile pinning and internal module sources · Deploying code onto the server and validating before it lands · Environment isolation and generated type information · File server mount points and static content · Puppet Server configuration, JRuby instances and tuning
The layer that breaks first and is understood least, and the one that keeps an agent from being enforced at all. How agent and server establish trust, the certificate authority commands, the real security trade-off in autosigning, CSR attributes that become trusted facts, regeneration, revocation and recovering a node that has lost its identity.
Topics: The trust model between agent and server · Certificate authority commands and the signing workflow · Naive and policy-based autosigning, and the risk each accepts · CSR attributes, extensions and trusted facts for classification · Regenerating agent and server certificates · Revocation, the CRL and what an agent does when trust fails · External certificate authority integration and TLS termination
The discipline that makes a change to shared code defensible on a large fleet. PDK for scaffolding, conversion and packaging, style and lint enforcement, rspec-puppet for catalogue unit tests, multi-platform fact matrices so a Windows regression is caught in CI, and acceptance testing before anything reaches a production node group.
Topics: PDK: creating, converting and packaging modules · Metadata, versioning and dependency declarations · puppet-lint, metadata-json-lint and an enforceable style · rspec-puppet: asserting what the compiled catalogue contains · rspec-puppet-facts and multi-platform test matrices · Acceptance tests against a real node before a fleet rollout · Running the whole harness in CI on every pull request
Running the platform for an organisation. Node management and console classification, role-based access control across teams and vendors, patch management, and then orchestration — on-demand runs, the orchestrator, and Bolt tasks and plans for the imperative, sequenced work that has no place in a catalogue.
Topics: Node inventory, node groups and console-based classification · Role-based access control for multiple teams and external vendors · Patch management across a mixed fleet · Running Puppet on demand and inspecting infrastructure from the console · Bolt tasks and plans, and running them across many nodes · Sequencing a change that a catalogue cannot express · Deciding what belongs in enforcement and what belongs in a plan
Everything that keeps an installation alive and defensible over years. Run reports and corrective-change data as audit evidence, noop runs that expose drift without applying it, report processors that feed a wider system, then disaster recovery, backup and restore, upgrade sequencing across server and agents, and the troubleshooting order that finds a fault quickly.
Topics: Run reports, corrective change and showing enforced state over time · Noop runs to evidence drift without applying a change · Built-in report processors, custom processors and report formats · PuppetDB queries and exported resources for cross-node data · Disaster recovery, high availability and backup and restore · Upgrading the server and agents in the right order · Troubleshooting catalogues, logs, SSL failures and slow runs under pressure
We rebuild the agenda around the tools you actually run.
Request a custom agendaGiven a node whose configuration is wrong, trace the resolved Hiera value through every layer, identify which key answered first, and fix the hierarchy rather than the symptom.
Deploy a control repository branch as a new environment with pinned modules, converge one node against it, then remove the environment without leaving state behind.
Take a module version bump, run the unit tests, compare compiled catalogues before and after, then apply it in noop to a canary group and read the difference.
Turn run reports and corrective-change data into a month-long record of enforced state for one node group, and identify a host that drifted and was corrected.
Write a profile that configures a service on both Linux and Windows agents using fact-driven data, with no platform conditional anywhere in the manifest.
Split a real change into the part Puppet enforces continuously and the part a Bolt plan sequences, execute both, then write the decision note for your architecture forum.
Where a push-based tool gets adopted in Pune because it needs no agent, Puppet persists precisely because it has one. The banking, insurance and telecom-adjacent captives around Kharadi, Yerwada and Magarpatta run estates where continuous enforcement is the whole point: a node that drifts overnight is corrected on the next run and the report proves it happened, which is a far easier story to take into an audit than a script somebody remembered to execute. Pune's Puppet demand is therefore concentrated in regulated environments and in long-lived enterprise Linux and Windows fleets, and the questions are all about the catalogue — why a resource was applied, what the data lookup returned for this particular node, and how to read a report whose most important line says that nothing changed.
The practical curriculum here is shaped by the fact that almost nobody in Pune is starting fresh. Teams inherit a control repository managed by an environment deployment tool, environments that have quietly diverged, and modules pulled from the public forge several major versions ago. So a batch tends to cover Hiera hierarchy design and the separation of code from data, roles and profiles applied to an estate that already exists, module upgrades with acceptance tests so a change can be proved safe before it converges on a thousand nodes, exported resources, and an honest position on where Puppet and a push-based tool should coexist rather than compete — Puppet holding the enforced baseline, the other driving one-off orchestration. Pune postings naming Puppet usually also name compliance reporting or a migration assessment, and both belong in the room.
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
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.
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.