Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Chef 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 Chef the way an inherited estate has to be approached. Compile and converge are traced live against a running node so timing behaviour stops being folklore, the attribute precedence table is worked through against a real node object rather than a diagram, and run-lists, search and data bags are read the way a maintainer reads them instead of the way a greenfield author writes them. The syllabus is weighted toward what an audit or a migration decision actually needs: Cookstyle, ChefSpec and Test Kitchen added to cookbooks that have never had a single test, InSpec profiles that gate a pipeline and then stand as continuous evidence, Windows node behaviour in a mixed fleet, Infra Server backup, restore and upgrade rehearsed under change control, and an honest comparison against a push-based tool that ends in a written recommendation.
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 Chef that means a trainer who has run it in production — Chef Infra and InSpec for Pune's inherited cookbook estates and audit obligations — 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 Viman Nagar; 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 usually schedule outside their monthly freeze window because the most valuable labs run against a real converge. The single thing that raises the value of a private Chef batch here is bringing a redacted copy of your own cookbook repository — we work through your resources, your Berksfile or Policyfile and your attribute precedence rather than a textbook example, under NDA if needed. Attendees each need a workstation plus two throwaway nodes, and we walk the group through standing up a server or using a hosted one. 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 Chef batchChef expresses the desired state of a machine as Ruby, applied by a client that runs on the node itself and pulls what it needs from an infrastructure server. Reading somebody else's Chef code is a different skill from writing your own, and it begins with the two-pass run. During compile, chef-client evaluates every recipe in the run-list in order and assembles a resource collection — at that point nothing has been installed and no file has been written. Only in the converge pass does the client work through that collection, resource by resource, making the machine match what was declared. Almost everything that looks like a Chef defect to a maintainer, from a value that was empty when it obviously should not have been to a service restarted before its configuration existed, resolves into something happening in the wrong pass.
The node object is the second thing to read carefully. Ohai collects facts about the machine at the start of each run, and attribute files, roles, environments, the run-list and the recipe itself all contribute values that a precedence table then arbitrates. Data bags hold shared and encrypted data on the server, and search lets a recipe query live node data during converge — powerful, and also the reason a change on one node can rewrite a file on another.
Around Chef Infra sit the pieces that make an old estate defensible. Cookstyle lints, ChefSpec asserts against the compiled resource collection without touching a machine, and Test Kitchen converges a real one. Chef InSpec expresses controls as executable code, runs against the same nodes Chef converges, and produces machine-generated evidence in a form an auditor will accept. Policyfiles replace the older Berkshelf and environment-pinning arrangement with one locked dependency set per policy group, and that is usually the first modernisation an inherited estate needs.
Nobody in Pune is choosing Chef this year, and that is precisely why this training exists. The estates running it here were standardised years ago inside banking and insurance back offices around Kharadi, Yerwada and Magarpatta, and inside long-running delivery accounts in Hinjewadi, and they still converge thousands of nodes on a schedule. The people who wrote the cookbooks have moved on, the documentation was never written, and the team holding it now is asked to keep it stable, extend it safely and answer questions about it. That is a maintenance capability, and it is not what an authoring course teaches.
Evidence is the second reason Chef keeps its seat. Regulated Pune estates are asked to show that a control was in place continuously, not that somebody checked it the week before an audit, and an InSpec profile running against the same nodes Chef converges produces exactly that. It is why InSpec stayed in use in places that have otherwise moved on, including teams whose day-to-day automation is now a push-based tool entirely.
The third is the migration question, which the local market asks out loud. Pune postings mentioning Chef mention coexistence, migration or audit reporting far more often than a new platform build, and a large share of the managed estate here is Windows Server rather than Linux, which changes the arithmetic considerably. What teams want at the end is a defensible position — where continuous enforcement earns its cost, where a push model is simpler, and what a phased split would look like — backed by evidence they gathered themselves rather than a vendor comparison.
The first day of a maintenance engagement, done as a method. Working out what a chef-repo contains, which cookbooks are actually on a run-list, which are dead, what the server holds that the repository does not, and how to build an accurate picture of a live estate before touching anything.
Topics: The chef-repo layout, and what it deliberately does not contain · knife and the chef command surfaces for investigation · Listing nodes, run-lists, environments, roles and cookbook versions on the server · Reading a node object field by field · Finding cookbooks that are uploaded but never converged · Reconciling the repository against what the server is actually serving · Chef Workstation setup and connecting to an existing server safely
The two-pass model taught as a debugging instrument rather than a piece of theory. Where a run splits between building the resource collection and applying it, which code runs during which pass, and how to look at a failed run and say with confidence which pass produced the surprise.
Topics: The run in sequence: Ohai, node load, cookbook sync, compile, converge, report · Ruby that executes at compile time against resources that act at converge time · lazy evaluation and ruby_block for deferring work · Notifications, subscriptions, and the delayed against immediate distinction · Why a resource appeared to fire at the wrong moment · Log levels, why-run mode and reading a stack trace from a converge · Chef Solo and local mode for reproducing a run without the server
The unit everything is built from, examined the way you examine code you have to keep working. Common resources and their actions, guards that are correct against guards that merely look correct, notification wiring, and the difference between a recipe that is idempotent and one that has simply not been run twice recently.
Topics: The resource set that appears in almost every real cookbook · Actions, default actions and multiple actions on one resource · not_if and only_if, and the guard that lies · Guard interpreters and platform-specific guards · notifies and subscribes, and ordering the restart correctly · Editing and reopening a resource declared elsewhere · Proving idempotency: the second converge that must change nothing · execute and script resources, and how to retire them
The single most common source of a maintainer's confusion. Where every value on a node came from, how the precedence table arbitrates between defaults, normals, overrides and automatics, and how to answer the question 'why is this value what it is' with a method instead of a guess.
Topics: Ohai and automatic attributes, and writing a custom Ohai plugin · default, force_default, normal, override, force_override and automatic · Attribute files, recipes, roles, environments and Policyfiles as sources · The full precedence table, worked through against a real node · Deep merge behaviour on hashes and arrays · Node tags and their appropriate use · Debugging a value with node.debug_value · Data bags and encrypted data bags for shared and sensitive values · Search: querying live node data during a converge
How the estate decides what a given node should be, and how to modernise that without a freeze. Run-lists and role composition, environments as version pins, then Policyfiles: what they fix about dependency resolution, what they cost, and a migration that can be done one policy group at a time while everything keeps converging.
Topics: Run-lists, recipe ordering and role composition · Environments and cookbook version pinning · Berkshelf, dependency resolution and where it goes wrong · Policyfile.rb, the lock file and policy groups · What a Policyfile replaces and what it deliberately does not · Migrating one node group at a time without a change freeze · Promotion through policy groups instead of editing node objects · Include_policy and shared policy composition
The half of the estate most Chef material skips. Bootstrapping and converging Windows Server, the Windows-specific resource set, registry and service handling, path and permission behaviour that differs from Linux in ways a shared cookbook rarely anticipates, and keeping one cookbook honest across both platforms.
Topics: Bootstrapping a Windows node and the transport it uses · The Windows resource set: features, services, tasks, packages and registry keys · Reading and writing registry keys from a recipe · PowerShell and batch resources, and their guard behaviour · File paths, permissions and line endings across platforms · platform and platform_family checks without duplicating recipes · Domain accounts, credentials and running as a service identity · Diagnosing a converge that succeeds on Linux and fails on Windows
The extension points an old estate is full of, and what to do with them. Recognising a custom resource, a library helper and a legacy definition on sight, understanding how each behaves during a run, then writing a properly idempotent custom resource when the built-in set genuinely does not fit.
Topics: Custom resources: properties, validation, actions and default_action · load_current_value and converge_if_changed for honest idempotency · Custom resources against library helpers against legacy definitions · Recognising and retiring a definition safely · Where a resource lives inside a cookbook and how it is found · Reporting: making a resource say truthfully whether it changed anything · Unit testing a custom resource · Versioning a resource other cookbooks already depend on
The work that makes an inherited estate changeable again. Cookstyle first because it is the cheapest signal, ChefSpec against the compiled resource collection so a test runs in seconds without a machine, and Test Kitchen for real convergence on real platforms — introduced in an order that gives value before the suite is complete.
Topics: Cookstyle: linting, autocorrection and adopting it on a large repository · ChefSpec: asserting against the resource collection, not the machine · Stubbing search, data bags and command execution in ChefSpec · Test Kitchen: drivers, platforms, suites and the test matrix · kitchen.yml for a mixed Linux and Windows matrix · kitchen-inspec as the verifier · Getting a first meaningful test onto an untested cookbook · Running the suite in CI and what to gate on
Compliance expressed as executable code and, more importantly, as output somebody outside the team will accept. Controls, profiles and inputs, profile inheritance for a shared baseline with local exceptions, reporters and formats, and the difference between a test that satisfies a developer and a report that satisfies an audit.
Topics: InSpec controls, describe blocks, matchers and impact · Profile structure, metadata and inputs · Profile inheritance and overriding a control for a documented exception · Attesting a control that cannot be tested automatically · Custom InSpec resources for your own applications · Reporters and output formats for downstream consumers · Running profiles against machines and against cloud APIs · InSpec inside a converge through the compliance phase · Scheduling profiles as continuous evidence rather than a point-in-time check
The day-two work an inherited estate defers until it becomes urgent. Server management, users, organisations and permissions, backup and restore rehearsed rather than assumed, upgrade planning across major versions, and doing all of it in an environment with a monthly freeze and a change board.
Topics: Server management commands and the reindex you will eventually need · Organisations, groups, users and the authorisation model · Client keys, the validator and key rotation · Backup, restore and verifying a restore actually works · Backend failure recovery · Monitoring the server and tuning it before it is slow · Planning an upgrade across major versions, including client version skew · Sequencing all of the above around a change freeze
The session most of these engagements are really booked for. An honest assessment of where Chef earns its cost against where a push-based tool is simpler, what a phased split looks like when both run against the same fleet, and how to write the recommendation up so an architecture forum can act on it.
Topics: What continuous pull-based enforcement actually buys, and where it does not · Comparing Chef against a push model on drift, reporting and blast radius · Running Chef and another tool against one estate without conflict · Choosing the boundary: which node classes move and which stay · Carrying attribute and data bag content across a migration · Keeping InSpec when the configuration tool changes · Cost, licensing and support considerations in the decision · Writing a recommendation with the evidence attached
We rebuild the agenda around the tools you actually run.
Request a custom agendaGiven server access and an unfamiliar repository, produce the node, run-list, cookbook version and orphan inventory a new maintainer would need on their first day.
Take a converge where a service restarted before its configuration was written, locate the compile-time code responsible, and fix it with lazy evaluation and correct notification ordering.
Given a node where the wrong value keeps winning, work the precedence table against the real node object until you can name the exact level that set it, then fix it without breaking any other node.
Bootstrap a Windows Server node, converge an existing cookbook that assumes Linux, and repair paths, permissions, services and registry handling until both platforms converge from the same code.
Write an InSpec profile for a real hardening standard, inherit a shared baseline, attest one documented exception, and schedule it so the output stands as ongoing evidence.
Assess one node class against continuous enforcement and a push model, migrate a representative cookbook to Policyfiles with tests, and produce a decision note an architecture forum could act on.
In Pune, Chef is almost never a greenfield choice — it is an inheritance, and the training market reflects that precisely. The captives and larger delivery accounts that standardised on Chef during the middle of the last decade, mostly the banking and insurance back offices around Kharadi, Yerwada and Magarpatta and the long-running services engagements in Hinjewadi, still converge thousands of nodes against an infrastructure server they cannot simply switch off, while the engineers who wrote the cookbooks have long since moved on. So what Pune teams buy is the ability to read an undocumented cookbook, understand the two-pass compile and converge model well enough to explain why a resource fired at the wrong moment, and add tests to code that has never had any.
Compliance is the second driver and the reason Chef keeps its seat here. Regulated Pune estates need continuous, machine-generated evidence, and an InSpec profile that runs against the same nodes Chef Infra converges is far easier to defend in an audit than a screenshot in a spreadsheet. The shape of local demand follows: Pune postings that mention Chef also mention migration, coexistence with Ansible, or audit reporting far more often than they mention a new platform build, and the batches booked here usually need to end in a defensible decision — keep Chef where enforcement and evidence matter, move the rest — rather than in a certification track. Teams also want the Windows story, because a large share of the Pune estate under Chef management is Windows Server rather than Linux.
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 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.
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.
| 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.