Private corporate batches, live online cohorts and 1-on-1 mentoring in model-driven configuration management with compiled catalogues, enforced desired state and Hiera-separated data — 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 Puppet around catalogue compilation rather than manifest syntax — how facts, node classification, environments and Hiera layers combine into the graph the agent actually enforces, and how to debug it when the resolved value is not the one you expected. Sessions cover the structural decisions that determine whether a Puppet codebase survives: roles and profiles, defined types versus classes, module testing with PDK, rspec-puppet and puppet-lint, certificate lifecycle and autosigning, environment isolation, and Bolt tasks and plans for the imperative work a catalogue cannot express.
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 — model-driven configuration management with compiled catalogues, enforced desired state and Hiera-separated data — 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 Puppet batchPuppet is a model-driven configuration management system. You declare the state a system should be in using Puppet's own declarative language, and the Puppet Server compiles that declaration — together with facts reported by the node — into a catalogue: a directed graph of resources with dependency edges resolved. The agent then enforces that catalogue locally and reports what it changed. The compilation step is the defining characteristic. Puppet decides what a node should look like before touching it, which is why relationships, ordering and duplicate-resource conflicts are caught at compile time rather than halfway through a run.
The language is genuinely declarative rather than a scripting language with declarative decoration. Resources have types, titles and attributes; classes group them; defined resource types let you instantiate a pattern many times; and the roles-and-profiles pattern gives a codebase a shape that survives growth. Data lives outside the code in Hiera, layered by environment, node group or fact, so the same module serves every environment without conditionals scattered through the manifests.
Around the core sits the rest of the platform. Facter gathers node facts, including custom and external facts. The Puppet Development Kit scaffolds, validates and packages modules, with puppet-lint, rspec-puppet and Rubocop wired in. Puppet Enterprise adds the console, role-based access control, node classification, patch management, disaster recovery, and Bolt for imperative tasks and plans — the agentless orchestration layer for the work that does not belong in a catalogue at all.
Puppet occupies the part of the market where enforcement matters more than convenience. An agent that checks in on a schedule and corrects drift is a different operational proposition to a push tool someone has to remember to run, and in audited environments that difference is the whole argument. Estates with tens of thousands of nodes, strict change control and a real compliance obligation are where Puppet stays.
That shapes the hiring. Organisations are not looking for people who can write a manifest; they are looking for engineers who can take an inherited codebase with node definitions accreted over a decade and restructure it into roles and profiles with Hiera-separated data, without breaking the estate mid-migration. Certificate lifecycle, environment isolation, catalogue debugging and Puppet Server tuning are all specialist skills that a general DevOps background does not supply.
The second driver is orchestration. Bolt gave Puppet teams an agentless path for tasks and plans — patching, restarts, one-off remediation — which removes the historic reason to bring in a second tool. Knowing where the catalogue ends and a Bolt plan begins is now part of the job.
Why configuration drift is an operational risk rather than an inconvenience, and how the pull-based, model-driven approach differs from push-based and imperative alternatives. An honest comparison with Chef, Ansible and Salt — including where Puppet is the wrong tool — plus the Open Source versus Enterprise split and what has changed in recent releases.
Topics: Why configuration management matters · Declarative modelling versus imperative execution · Puppet compared with Chef, Ansible and Salt · Puppet Open Source versus Puppet Enterprise · Recent release changes and deprecated features · Where Puppet is the wrong answer
What actually happens between an agent waking up and a report landing. The Puppet Server, the agent run cycle, fact submission, catalogue compilation and graph resolution, enforcement and reporting. Facter in depth, because the facts are the input to every conditional decision the catalogue makes.
Topics: Puppet Master and Puppet Server · The Puppet agent run workflow · Catalogue compilation and the resource graph · Facter overview and the fact set · facter.conf, custom facts and external facts · The report cycle and what the agent sends back
Getting a working master and agents. Choosing an architecture for Puppet Enterprise, monolithic or split; infrastructure requirements; installing Puppet Server and agents on both Unix-like and Windows nodes; first login to the console; and the environment you will use for the rest of the course.
Topics: Choosing a PE architecture: monolithic versus split · Preparing infrastructure requirements · Installing Puppet Server · Installing Puppet agents on *nix · Installing Puppet agents on Windows · Accessing the console and first logins · Navigating the Puppet Enterprise console · Introduction to PE role-based access control
The declarative DSL, taught as a modelling language rather than a syntax list. Resource types and attributes, variables, conditionals, relationships and ordering metaparameters, node definitions, classes and defined resource types — and the duplicate-resource and dependency-cycle errors that teach you how the graph really works.
Topics: Puppet DSL introduction and resource declaration · Core resource types: file, package, service, exec, user, group, notify · Variables, data types and conditional expressions · Ordering and relationships: require, before, notify, subscribe · Node definitions · Classes and class parameters · Defined resource types · Duplicate resources and dependency cycles
Getting data out of manifests. EPP and ERB templating, expressions, operators and built-in functions, then Hiera — the layered data hierarchy that lets one module serve every environment. Automatic parameter lookup, hierarchy design driven by facts, and where module data belongs.
Topics: Embedded Puppet (EPP) templates · ERB templates and when they still appear · Expressions, operators and built-in functions · Hiera concepts and the data hierarchy · hiera.yaml configuration and layers · Automatic parameter lookup · Fact-driven hierarchy design · Module data and defaults
The Puppet Development Kit as the standard workflow for authoring modules. Installing PDK, creating and converting modules, customising module configuration, validation and unit-test scaffolding, and building and packaging a module for the Forge or an internal repository.
Topics: PDK overview and workflow · Installing PDK · Creating a new module · Converting an existing module to the PDK layout · Customising module configuration and metadata · pdk validate and pdk test unit · Building and packaging modules · Publishing to the Forge or an internal repository
Proving a module works before an agent enforces it on production. The Puppet style guide as an enforceable standard, puppet-lint and metadata-json-lint, rspec-puppet for catalogue unit tests, rspec-puppet-facts for multi-platform matrices, and Rubocop for the Ruby in custom functions and types.
Topics: Puppet style guide and code conventions · puppet-lint and metadata-json-lint · rspec-puppet: testing the compiled catalogue · rspec-puppet-facts and multi-platform test matrices · Rubocop for Ruby functions and custom types · Fixtures and test dependencies · Reading and acting on a failing test run
The constructs and patterns that separate a codebase that scales from one that accretes. Type aliases, writing custom functions in the Puppet language and in Ruby, custom resource types and providers, and the roles-and-profiles pattern that gives node classification a stable interface.
Topics: Type aliases and data type validation · Built-in functions and calling conventions · Writing custom functions in Ruby · Reserved words, acceptable names and expression rules · The roles and profiles design pattern · Classes, profiles and the classification interface · Custom resource types and providers
The server-side layout and the operational controls around it. The code directory structure, creating and managing environments, environment isolation and why it matters when two environments disagree about a custom type, file server mount points, Puppet Server configuration and tuning — then secrets, held in a backend rather than in the codebase.
Topics: Code directory structure: codedir, confdir, modulepath, vardir, ssldir · Creating and managing environments · Environment isolation · Puppet Server setup, configuration and tuning · File server mount points · Secrets store integrations · Hiera with encrypted and secret backends · Writing Puppet functions to store and retrieve secrets
The layer that breaks first and is understood least. How agent and server authenticate, Puppet Server CA commands, autosigning certificate requests and the security trade-off it carries, CSR attributes and extensions for trusted facts, certificate regeneration, and integrating an external CA or SSL termination.
Topics: How Puppet's SSL trust model works · Puppet Server CA commands · Autosigning certificate requests, naive and policy-based · CSR attributes, extensions and trusted facts · Regenerating agent and server certificates · External CA integration and SSL termination · Certificate lifecycle and revocation
Running PE for an organisation. Node management and console-based classification, patch management, access and permissions, infrastructure inspection — then orchestration: running Puppet on demand, the orchestrator, Bolt tasks and plans across many nodes, and Razor-based provisioning.
Topics: Managing nodes in Puppet Enterprise · Classifying nodes in the PE console · Managing patches across the estate · Managing access and permissions · Inspecting infrastructure from the console · Orchestrating Puppet runs on demand · Orchestrator overview · Bolt tasks and plans · Running tasks across multiple nodes · Provisioning with Razor
Everything that keeps a Puppet installation alive over years. Report processors and activity tracking, disaster recovery and high availability, routine maintenance, backup and restore, upgrading PE and agents, migrating from Open Source to Enterprise, securing the installation, and the troubleshooting techniques for catalogues, manifests, logs and SSL.
Topics: Tracking Puppet activity and built-in reports · Report processors, custom processors and report formats · Configuring disaster recovery in Puppet Enterprise · Backup and restore workflows · High availability design patterns · Routine maintenance, log management and recovery · Upgrading Puppet Enterprise and agents · Migrating from Puppet Open Source to PE · Securing PE infrastructure, RBAC and code · Common errors, debugging catalogues and manifests · Troubleshooting SSL issues · Reading logs and reports under pressure
We rebuild the agenda around the tools you actually run.
Request a custom agendaCompile a catalogue for a node without applying it, read the resource graph, then break it three ways — cycle, duplicate resource, wrong fact — and fix each from the compiler output alone.
Take a module riddled with environment conditionals and refactor it into a fact-driven Hiera hierarchy where the manifest contains no environment logic at all.
Scaffold a module with PDK, implement it, then bring it to green puppet-lint, metadata-json-lint, rspec-puppet and rspec-puppet-facts across two platforms.
Restructure a decade-old codebase of node definitions into roles and profiles, keeping every node's resolved catalogue identical while the code underneath changes completely.
Configure policy-based autosigning with CSR attributes, prove an unauthorised node is rejected, then rotate a compromised certificate and recover an agent that has lost trust.
Write, test and deploy a module; classify a node group in the console; orchestrate the change with a Bolt plan; then monitor, report and troubleshoot the result live.
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.
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.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
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.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.