Private corporate batches, live online cohorts and 1-on-1 mentoring in declarative infrastructure as code across cloud providers, with state you can reason about — 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 Terraform around state rather than syntax — the plan/apply lifecycle, state files and remote backends with locking across S3, azurerm, GCS and Artifactory, workspaces for multi-environment work, and the lifecycle meta-arguments that determine in-place updates versus destroy-and-recreate. Sessions cover variables and type constraints in depth, the function library, provisioners and their limits, and module design and publishing, all demonstrated live against real cloud providers.
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 Terraform that means a trainer who has run it in production — declarative infrastructure as code across cloud providers, with state you can reason about — 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 Terraform batchTerraform is an infrastructure-as-code tool that provisions and manages resources through declarative configuration. You describe the infrastructure you want in HCL; Terraform compares that description against recorded state, works out the difference, and applies only what changed. The distinction from imperative scripting matters: a shell script says how to create a server, while Terraform says what should exist and lets the tool determine the steps.
State is the concept that separates people who use Terraform from people who fight it. Terraform records what it created in a state file, and every plan is a three-way comparison between configuration, state and reality. Once state is understood, the behaviour that otherwise looks arbitrary — resources being replaced, drift appearing, imports being necessary — becomes predictable. In a team, that state has to move to a remote backend with locking, or two engineers running apply at once will corrupt it.
The provider model is what gives Terraform reach. Rather than knowing about any particular cloud, Terraform loads providers that translate resource declarations into API calls, so AWS, Azure, GCP, Kubernetes, GitHub and hundreds of other systems are managed through one workflow. Modules package that configuration for reuse, and the registry distributes it.
Clicking through a cloud console does not survive contact with an audit, a second environment, or staff turnover. Infrastructure as code has become the default expectation for anything running in production, and Terraform is the tool most organisations standardise on because it works across providers rather than locking to one.
The skill gap is rarely syntax. Most engineers can write a resource block within an hour. What causes production incidents is state management — remote backends, locking, workspace strategy — along with module design that does not collapse under reuse, and the lifecycle meta-arguments that decide whether a change updates a resource in place or destroys and recreates it. That last one has taken down more environments than any syntax error.
Demand also comes from the compliance side. Infrastructure defined in code is reviewable, diffable and attributable, which is why regulated organisations increasingly mandate it, and why Terraform skills appear in platform, cloud and security engineering roles alike.
The problem before the tool. Why infrastructure drifts, the declarative versus imperative distinction, and an honest comparison of Terraform against the alternatives including where it is the wrong choice.
Topics: Infrastructure through the SDLC · Problems with many infrastructure tools · Declarative vs imperative · Terraform advantages and disadvantages · Alternatives to Terraform · Terraform use cases
The building blocks. Installing Terraform, the provider model and registry, resources and their argument references, then deploying a first configuration end to end.
Topics: Installing Terraform · Providers · The Terraform Registry · Resources and argument reference · Deploying a first configuration · Adding a new provider
The commands and the concept underneath them. init, validate, plan, apply, show and destroy — then the state file, resource behaviour and lifecycle, and why state is the thing that actually needs managing.
Topics: terraform init and validate · terraform plan · terraform apply · terraform show and destroy · The state file · Resource behaviour and lifecycle · Updating and reconfiguring resources
The language and the five meta-arguments that control resource behaviour. depends_on, count, for_each, provider and lifecycle — the last of which decides whether a change is an update or a replacement.
Topics: HCL syntax and style · depends_on · count · for_each · provider · lifecycle · create_before_destroy and prevent_destroy
Parameterising configuration properly. Input variables and where to declare them, the full type system, precedence and scope, then output values and local values.
Topics: Input variables · Where to declare variables · Types: string, number, bool · Types: list, set, map · Types: object, tuple · Variable precedence and scope · Output values · Local values
Reading existing infrastructure and transforming values in-language rather than shelling out. Data sources, HCL operators, and the function library across numeric, string, collection, encoding, filesystem, date, crypto, IP and conversion categories.
Topics: Data sources · HCL operators · Numeric and string functions · Collection functions · Encoding and filesystem functions · Date and time functions · Hash and crypto functions · IP network and type conversion functions
The escape hatch, and why it should be a last resort. file, local-exec and remote-exec, when each is defensible, and the configuration-management boundary where Ansible is the better answer.
Topics: Introducing provisioners · The file provisioner · local-exec · remote-exec · Provisioner failure behaviour · When to use configuration management instead
Terraform for a team rather than an individual. Templates, workspaces for multiple environments, remote backends on S3, azurerm, GCS and Artifactory, and state locking — the thing that stops two concurrent applies corrupting everything.
Topics: Terraform templates · Workspaces for multiple environments · Remote backends: s3 · Remote backends: azurerm · Remote backends: gcs · Remote backends: artifactory · State locking
Packaging configuration so it can be shared without becoming unmaintainable. Consuming registry modules, developing custom modules, versioning and publishing.
Topics: Introducing modules · Using modules from the registry · Developing custom modules · Module inputs, outputs and versioning · Publishing to the registry · Module composition patterns
Running Terraform as part of a delivery process. Debug logging and common errors, the interactive console, tagging strategy, Terraform Cloud, and driving multi-provider infrastructure from CI/CD.
Topics: Troubleshooting using logs · Common errors and their causes · Terraform console · Tagging strategy · Terraform Cloud · Multiple providers in CI/CD · Plan review as a change-control gate
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeliberately break the link between state and reality, then recover using import, targeted operations and state inspection.
Take a configuration where an innocuous change destroys a database, and fix it with lifecycle meta-arguments.
Build a single configuration that serves dev, staging and production purely through variable precedence and workspaces.
Move local state to a remote backend with locking, then demonstrate what concurrent applies do with and without it.
Extract duplicated configuration into a versioned module, publish it, and consume it by version constraint from two projects.
Build a pipeline where every infrastructure change produces a reviewable plan, requires approval, and applies with locked remote state.
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.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
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.
| 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.