Private corporate batches delivered onsite across Bangalore, 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 demands: the compile and converge phases traced live so timing surprises stop being mysteries, the full attribute precedence table worked through against a real node object, search and data bags, custom resources with proper notifications, and the Berkshelf to Policyfile migration path. Testing is treated as core rather than optional — Cookstyle, ChefSpec, Test Kitchen and InSpec profiles that gate a pipeline and then double as audit evidence — with every concept demonstrated against converging machines rather than slides.
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 for Bangalore infrastructure teams — attribute precedence, Policyfiles, Test Kitchen and InSpec evidence on inherited 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 sessions run at your own office. Chef engagements in Bangalore typically land along the Outer Ring Road between Bellandur and Marathahalli, in Whitefield, at Manyata Tech Park or Embassy Golf Links, and we schedule one site per day so a peak-hour crossing does not consume lab time. You provide the room, a screen and network access to a lab Chef Infra Server or a hosted trial; we bring the trainer, agenda, cookbooks and assessment. Where an estate is under change control we work against a copy of your cookbooks under NDA rather than your production organisation. Sessions are scheduled in IST (UTC+5:30), and a 09:30 to 17:00 shape leaves the evening free for teams that overlap with US counterparts. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included in the quote.
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 system in which infrastructure is expressed as Ruby that runs in two distinct phases. During compile, the client evaluates every recipe in the run list and builds a resource collection — nothing has touched the machine yet. The converge phase then walks that collection in order, and each resource does whatever is required to reach the state it declared — or nothing at all, if the machine is already there. Almost every confusing Chef behaviour, from a variable that seems to be set too early to a notification that fires at an unexpected moment, comes back to that two-phase model.
The node is the other central object. Ohai gathers facts about the machine at the start of every run; those automatic attributes then compete with default, normal, override and force levels set in cookbooks, roles, environments and the node itself, resolved through a precedence table that is genuinely the most common source of production surprises. Chef Infra Server holds node objects, data bags, environments, roles and cookbook versions, and makes them searchable — which is how one node discovers another without a service registry.
How that code is assembled has changed. Berkshelf and environment version pinning gave way to Policyfiles, which lock an entire dependency set and run list into a single, promotable artifact — a materially different operating model, and the migration most existing estates are somewhere inside. Around it sits the tooling that makes Chef testable: Cookstyle for linting, ChefSpec for unit tests of the compile phase, Test Kitchen for converging on a real machine before a node ever sees the change, and InSpec for controls that can gate a pipeline and then be re-run against production as evidence.
Configuration management did not disappear when containers arrived; it moved. The workloads that were easy to containerise went to Kubernetes, and what remained on virtual machines is the harder half — databases, licensed software, appliances, hosts with hardware dependencies, and the long tail of systems that a regulator, a vendor contract or a physics constraint keeps where it is. Those estates still drift, still need patching, and still need to prove they match policy.
Chef is disproportionately represented in that remaining half, because organisations that adopted it did so for large, long-lived, compliance-heavy fleets. The result is a specific and durable skills gap: plenty of engineers can write a recipe, very few can safely change a ten-year-old cookbook tree with sixteen levels of attribute precedence, an undocumented data bag dependency and no test coverage.
Separately, InSpec has developed a life of its own. Compliance teams use it as a control language against fleets that have nothing to do with Chef Infra, because a control that is executable, version-controlled and runnable on demand beats a screenshot in an evidence folder. Between estate maintenance, migration decisions and compliance-as-code, Chef skills now sell on judgement rather than novelty — which is exactly the kind of skill that is scarce.
What actually happens between chef-client starting and the machine changing. Ohai, node object load, cookbook synchronisation, compile, converge, notifications and the report handler — traced live with verbose logging on a real node.
Topics: chef-client run sequence end to end · Ohai and automatic attributes · Cookbook synchronisation and the local cache · Compile phase versus converge phase, with worked examples · why-run mode and its honest limitations · Reading run logs and failure output
The table that explains most Chef surprises. Default, force_default, normal, override, force_override and automatic levels, set from cookbooks, roles, environments and the node — plus deep merge behaviour and why normal attributes persist between runs.
Topics: The full precedence order and where each level is set · Deep merge and array behaviour · Normal attributes persisting on the node object · Role and environment attributes in a Policyfile world · Debugging with knife node show and node attribute dumps · Conventions that keep precedence usage sane
The building blocks, then the extension mechanism. Core resources and their properties, guards and idempotency, notifies and subscribes with immediate and delayed timing, then writing custom resources with actions, properties and converge_if_changed.
Topics: Core resources: package, file, template, service, user, execute · Guards with not_if and only_if, and the ones that are lies · notifies, subscribes, :immediately and :delayed · Templates, partials and node data in ERB · Custom resources: properties, actions, converge_if_changed · Migrating legacy definitions and LWRPs
The server as the shared index. Organisations, users, clients and keys; uploading and versioning cookbooks; roles, environments and run lists; then search as a discovery mechanism, and data bags — including encrypted data bags and where they stop being appropriate.
Topics: Organisations, clients, users and key management · knife workflow and cookbook upload · Roles, environments, run lists and version pinning · Search syntax and node discovery patterns · Data bags and encrypted data bags · Bootstrap options and node registration
The change most estates are in the middle of. Berkshelf and environment pinning, what breaks about them at scale, then Policyfiles: policy names, revisions, the lock file, policy groups as environments, and a promotion workflow that does not require a freeze.
Topics: Berkshelf resolution and environment version pinning · Policyfile structure, run lists and included policies · Policy revisions, lock files and reproducibility · Policy groups as environment promotion · Migrating an existing estate incrementally · Publishing and pushing policy revisions from CI
Making an inherited estate safe to change. Cookstyle for lint and auto-correction, ChefSpec for asserting the compile phase without touching a machine, Test Kitchen for converging on a real instance across platforms, and the CI gate that ties them together.
Topics: Cookstyle rules, auto-correct and adopting it on legacy code · ChefSpec: matchers, stubbing search and data bags · Test Kitchen drivers, platforms and suites · The converge, verify and idempotency cycle · Running the matrix in CI without a two-hour build · Writing the first test on a cookbook that has none
Compliance expressed as executable code. Resources and matchers, profile structure, attributes and inputs, inheriting and overriding community profiles like CIS, running against local and remote targets, and producing reports that satisfy an auditor rather than only a dashboard.
Topics: InSpec resources, matchers and control structure · Profile layout, metadata and dependencies · Inputs and per-environment parameterisation · Inheriting CIS and vendor profiles and overriding honestly · Running against SSH, WinRM, cloud APIs and containers · Reporters, waivers and evidence retention
Living with Chef over years. Client run scheduling and convergence intervals, handling failed runs at fleet scale, upgrade paths for client and server, Chef Automate visibility, Habitat and Bolt-style task work at the edges, and how to evaluate a migration honestly.
Topics: chef-client scheduling, splay and convergence intervals · Detecting and triaging fleet-wide run failures · Client and server upgrade planning · Chef Automate: visibility and compliance reporting · Where Habitat fits and where it does not · Assessing a migration to another tool without wishful thinking · Backup and disaster recovery for the server
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument a verbose chef-client run, mark exactly where compile ends and converge begins, and place code deliberately on each side to prove the difference.
Reproduce an attribute conflict across cookbook, role, environment and node, then resolve it by naming the exact precedence rule rather than by moving code until it works.
Write a custom resource with two actions, correct guards and converge_if_changed, then prove a second run reports zero changes.
Convert an existing cookbook set to a Policyfile, produce a reproducible lock, and promote one revision through three policy groups with a rollback at each step.
Add Cookstyle, ChefSpec and a Test Kitchen suite to a legacy cookbook, find a real defect, and wire the whole set into a CI gate that blocks the merge.
Build an InSpec profile from a real benchmark, parameterise it per environment, gate a pipeline with it, then run it against production and produce a retained report.
Chef in Bangalore is almost entirely an inherited-estate skill, and that shapes every engagement. The cookbooks were usually written between 2013 and 2017 by a platform group at a parent organisation abroad; the servers they configure are still running; and the team that now owns them sits along the Outer Ring Road, in Whitefield or at Manyata Tech Park, several years and two reorganisations removed from anyone who remembers why a particular attribute is set at role level. The practical questions that come up in a Bangalore Chef batch are therefore specific: why did this attribute win, what does this run list actually do to a node, can we move from Berkshelf to Policyfiles without a freeze, and how do we test a change when the only environment that reproduces the problem is production.
The second driver is audit. Banking, insurance and healthcare GCCs here have to produce evidence that a fleet matches policy, repeatedly and on demand, and InSpec is frequently already in the toolchain for exactly that reason — sometimes used entirely on its own, with no cookbooks involved, by a compliance team that has never written a recipe. That produces two very different audiences in the same city and often the same building. Chef appears in Bangalore job specs less often than Ansible, but when it does the role is senior, it is retained rather than growth hiring, and it usually carries a second responsibility: keeping the estate healthy while a migration decision is made somewhere else. Training that pretends the estate is new is useless to those teams.
What those estates look like in this city is also fairly consistent. The heaviest Chef usage sits with storage, virtualisation and networking product groups whose build and test laboratories run hundreds of long-lived virtual machines, and with the infrastructure arms of financial GCCs that manage a mixed Red Hat and Windows fleet under quarterly attestation. Both carry a Windows population large enough that the cookbook tree has two dialects in it, which is where inherited estates most often break. Turnover compounds it: a Bengaluru infrastructure team can rotate substantially inside two years, so the knowledge that a particular data bag exists to work around a vendor package lives in exactly one head until that person moves. The teams who book this training are usually trying to write that knowledge down as ChefSpec assertions and documented attribute defaults rather than as a wiki page, so that the next rotation inherits something executable.
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.
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.
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.
| 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.