Private corporate batches, live online cohorts and 1-on-1 mentoring in policy-driven configuration management with Ruby cookbooks, test-first resources and continuous compliance — 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 Chef around the converge, not the syntax — the compile and converge phases, attribute precedence, resource idempotency and how search and data bags feed a run-list at run time. Sessions cover the parts that decide whether a Chef estate stays maintainable: custom resource authoring, Policyfiles versus Berkshelf, Test Kitchen and ChefSpec harnesses, InSpec profiles used both as pipeline gates and as continuous compliance, and Chef Infra Server operations including bootstrap, backup and backend recovery — all demonstrated live against running nodes.
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 — policy-driven configuration management with Ruby cookbooks, test-first resources and continuous compliance — 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 Chef batchChef is a configuration management platform that describes infrastructure as executable Ruby. A recipe declares resources — a package, a file, a service, a user — and the chef-client on each node compiles those declarations into a resource collection, then converges the machine to match. The two-phase model, compile then converge, is the detail that separates Chef from tools that simply execute a list top to bottom, and it is the reason Chef code can compute at compile time and still act idempotently at run time.
The platform is more than one binary. Chef Workstation is where cookbooks are written and tested; Chef Infra Server is the searchable index of nodes, roles, environments, data bags and cookbook versions that clients pull from; Chef InSpec expresses compliance controls as code that can be run standalone or inside a converge; Chef Automate gives fleet-wide visibility across both. Chef Habitat packages applications with their runtime configuration, and Chef Supermarket hosts community cookbooks.
What teams actually buy with Chef is testability. Because a cookbook is Ruby, it can be unit-tested with ChefSpec, linted with Cookstyle, and integration-tested on a real machine with Test Kitchen before it goes anywhere near a node — and the same InSpec profile that gates the pipeline can be run against production to prove the estate still matches policy. Chef suits organisations that treat infrastructure code as software, with a review, test and release process to match.
Chef sits in a mature part of the market, and that is precisely why the demand for it is specific rather than broad. The estates that run Chef are large, long-lived and usually regulated — banks, telcos, retail platforms, government suppliers — and they are not migrating away quickly, because thousands of nodes and years of cookbook logic do not port on a whim.
That produces two kinds of hiring. The first is maintenance and modernisation: teams need engineers who can read an inherited chef-repo, understand why a run-list resolves the way it does, move from Berkshelf to Policyfiles, and upgrade a Chef Infra Server without losing node data. The second is compliance. InSpec has outgrown Chef itself — it is used by teams who run Ansible or Terraform everywhere else — because expressing a CIS benchmark as version-controlled, executable controls is a problem every audited organisation has.
The scarce skill is not writing a recipe. It is designing the cookbook boundaries, attribute precedence and data-bag strategy so a change to one application does not converge into an outage somewhere else, and building the Test Kitchen and InSpec harness that catches it before it does.
The problem before the tool: why estates drift, what that costs, and how the major approaches differ. Then an honest map of the Chef product family — Workstation, Infra, Infra Server, Automate, Desktop, Habitat, InSpec and Supermarket — so you know which piece solves which problem, and the client/server architecture that ties them together.
Topics: Overview of DevOps and SRE practice · Introduction to configuration management and why it matters · Comparing configuration management tools · What Chef is: pull model, Ruby DSL, resource abstraction · Chef products: Workstation, Infra, Infra Server, Automate, Desktop · Chef Habitat, InSpec and Supermarket · Why Chef Infra and why Chef Infra Server · Architecture of the Chef Infra client and server
Getting a working development environment, then writing something that converges. Installing and configuring Chef Workstation, the chef and knife command surfaces, resources as the fundamental unit, and a first recipe run in local mode against a real machine — with the troubleshooting path when it does not converge.
Topics: Installing Chef Workstation · Workstation setup and configuration · Troubleshooting with chef-run and chef-shell · Understanding Chef Infra resources and actions · Writing and testing your first recipe · What a cookbook is and how it is generated · chef commands · knife commands and knife.rb
Everything inside a cookbook directory and why it is there. The chef-repo layout, recipes, attributes, files, templates, libraries and metadata.rb — then cookbook versioning and dependency constraints, which is where most inherited Chef estates start to hurt.
Topics: About chef-repo and its layout · Understanding the cookbook directory structure · Attributes files and attribute types · Files and file specificity · Libraries and helper methods · metadata.rb, dependencies and version constraints · Recipes and recipe includes · Templates and ERB · Versioning cookbooks · The top Chef Infra resources you will actually use
Standing up the server side and getting nodes talking to it. Prerequisites and installation, organisations, groups and users, the RSA key-based authentication and RBAC authorisation model, uploading cookbooks, and bootstrapping both Linux and Windows nodes so they converge on a schedule.
Topics: Chef Infra Server overview and prerequisites · Installing and configuring Chef Infra Server · Authentication: keys, clients and the validator · Authorisation: RBAC, ACLs and permissions · Server users, organisations and groups · Uploading cookbooks to the server · Bootstrapping Linux nodes · Bootstrapping Windows nodes · Running cookbooks from the server · Working with Chef Supermarket
What actually happens between chef-client starting and the node reporting success. Ohai and node data collection, the compile and converge phases, search against server-held node data, handlers for reporting and exception routing, the compliance phase, and where Chef Solo and local mode still make sense.
Topics: Chef Infra client configuration · Chef Infra client features and run phases · Ohai and automatic node attributes · Compile phase versus converge phase · Search: querying node data at converge time · Report and exception handlers · The compliance phase · Chef Solo and local mode
How Chef decides what a given node should be. Run-lists and role composition, environments and cookbook version pinning, data bags and encrypted data bags for shared and sensitive data, then Policyfiles — what they replace, what they fix about dependency resolution, and how to migrate to them.
Topics: Run-lists and recipe ordering · Roles and role composition · Environments and version pinning · Data bags and encrypted data bags · Reading data bags from a recipe · About Chef Infra Policy and Policyfiles · Policyfile.rb, locks and policy groups · Migrating from run-lists and Berkshelf to Policyfiles
Chef code is Ruby, and that cuts both ways. Conditionals, loops, operators and helper functions; platform detection; guards and not_if/only_if; editing and reopening resources; node tags; reading Windows registry keys; and the logging and debugging techniques that make a failed converge legible.
Topics: Conditionals in recipes: only_if, not_if and Ruby guards · Loops and iteration over attributes · Operators and expressions in the Chef Infra language · Built-in and custom helper functions · Declaring and using dependencies in a recipe · Platform and platform_family checks · Cookbook execution order and lazy evaluation · Editing and reopening existing resources · Node tags · Reading data bags and Windows registry keys · Logging, log levels and troubleshooting a converge
When the built-in resource library does not fit, you write your own. Resource properties, actions, default_action, converge_if_changed and idempotency; the difference between a custom resource and a definition; unit testing it; and when a library helper is the right answer instead.
Topics: Understanding Chef custom resources · Properties, defaults and validation · Actions and default_action · Idempotency with converge_if_changed and load_current_value · Custom resources versus definitions and libraries · Shipping custom resources inside a cookbook · Extending Chef Infra beyond the core resource set
The discipline that makes Chef defensible on a large estate. Cookstyle for lint and auto-correction, ChefSpec for fast unit tests against the compiled resource collection, and Test Kitchen for real convergence on real machines — driven by Vagrant locally and cloud instances in CI.
Topics: Cookstyle: linting and automated correction · ChefSpec unit tests against the resource collection · Test Kitchen: drivers, platforms and suites · kitchen.yml configuration and test matrices · Introduction to Vagrant as a Kitchen driver · Installing and using Vagrant for cookbook testing · kitchen-inspec verifiers · Interpreting a failing test run
Expressing controls as executable code rather than a spreadsheet. The InSpec language, profiles, inputs, matchers and reporters; profile inheritance and the style guide; custom resources and plugins; the InSpec shell for exploration; and running profiles against cloud APIs as well as machines.
Topics: Chef InSpec overview and installation · Writing InSpec controls and the InSpec language · Profiles, profile structure and inheritance · Inputs, attributes and profile configuration · Matchers and resource selection · Reporters and output formats · InSpec for the cloud: AWS, Azure and GCP resources · InSpec custom resources and plugins · The InSpec shell and exploratory testing · Viewing and analysing results · Troubleshooting profiles
The day-two work. Managing nodes and cookbook versions on the server, Windows fleet management, backup and restore, backend failure recovery, monitoring, performance tuning and the log files that tell you what is really happening.
Topics: Managing Windows servers with Chef Infra Server · Chef Infra Server management commands · Backup and restore · Backend failure recovery · Monitoring the server · Performance tuning · Server log files and what to look for · Chef Infra security posture and key rotation
Chef as part of a delivery system rather than a standalone tool. Jenkins pipelines that lint, test and promote cookbooks; integrations with Docker, Kubernetes and AWS; then Chef Automate for fleet-wide visibility, node and job management, user administration and compliance reporting across the estate.
Topics: Introduction to Jenkins for Chef pipelines · Setting up CI/CD with Jenkins and Chef · Chef integration with Docker · Chef integration with Kubernetes · Chef integration with AWS · Getting started with Chef Automate · Installing and configuring Chef Automate · Managing Chef Automate and its settings · User management in Chef Automate · Infrastructure management and node visibility · Jobs and node management with Automate
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a cookbook that installs, templates, configures and manages a service, driven entirely by attributes — then converge it twice and prove nothing changes on the second run.
Install Chef Infra Server, create an organisation with two differently privileged users, upload cookbooks and bootstrap both a Linux and a Windows node onto it.
Take an estate driven by roles, environments and Berkshelf, migrate it to Policyfiles and policy groups, and compare the resolved dependency graph before and after.
Take an untested 600-line cookbook and bring it to a passing Cookstyle, ChefSpec and Test Kitchen suite across two platforms without changing its behaviour.
Write an InSpec profile encoding a real hardening standard, run it in CI as a build gate, then schedule the same profile against production and report the drift.
Wire a Jenkins pipeline that lints, unit tests, integration tests and promotes a cookbook through policy groups, with Chef Automate reporting node and compliance status across the fleet.
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.
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.
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.
| 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.