Private corporate batches, live online cohorts and 1-on-1 mentoring in running a cloud estate day two onward — guardrails, drift, observability, incident response, recovery and cost — 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 CloudOps as estate management rather than console tours: multi-account and multi-subscription structure with preventative policy guardrails, infrastructure as code as the only sanctioned change path with drift detection behind it, observability designed around managed services and provider health events, incident response and runbook automation, rehearsed backup and disaster recovery against stated objectives, and cost attribution that traces a bill back to the architectural decision that caused it. Every module runs against a live estate, including deliberately introducing drift and failure and then operating through it.
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 CloudOps that means a trainer who has run it in production — running a cloud estate day two onward — guardrails, drift, observability, incident response, recovery and cost — 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 CloudOps batchCloudOps is the operating discipline that takes over once a cloud estate exists. Building an environment is a project with an end date; running it is a continuous job of keeping accounts structured, resources accounted for, workloads healthy, recovery rehearsed, access least-privilege and spend defensible — across an estate that changes every day because self-service provisioning is the whole point of the cloud.
What makes CloudOps distinct from traditional infrastructure operations is that almost nothing is manual and almost nothing is permanent. There is no rack to visit and no ticket queue standing between an engineer and a new database. The controls that matter are preventative rather than procedural: organisational policy that refuses a non-compliant resource, infrastructure as code as the only sanctioned way to change state, tagging enforced at creation so the bill can be attributed, and automated remediation for the drift that gets through anyway. Monitoring shifts too — you are watching managed services whose internals you cannot reach, so service-level signals and provider health events matter more than host metrics.
CloudOps overlaps with SRE and with FinOps without being either. SRE supplies the reliability practice — objectives, error budgets, incident review — and FinOps supplies the financial operating model. CloudOps is the estate-level work underneath both: which accounts exist, what runs in them, whether it is patched, backed up, tagged, monitored, recoverable and worth what it costs. In most organisations it is the function that decides whether the cloud stays an asset or quietly becomes an unmanaged liability.
The first cloud project is usually a success and the second year is usually a mess. Accounts multiply, ownership blurs, half the estate is provisioned by hand, tags are missing on exactly the resources that cost the most, and nobody is certain which backups restore. That gap between a working migration and a governed estate is what CloudOps roles exist to close.
Demand has moved accordingly. Organisations that hired cloud engineers to build now hire for operation: someone who can define guardrails without blocking teams, detect and remediate drift, run an on-call rotation against managed services, evidence compliance to an auditor, and take twenty percent out of a bill without degrading a workload. Those are operational skills, and they are scarcer than build skills because they only develop on an estate that has been running long enough to go wrong.
There is a regulatory pull as well. Data residency, audit evidence and recovery obligations increasingly require demonstrable operational control rather than good intentions, and the ability to produce that evidence from the platform itself — rather than from a spreadsheet — is now a hiring criterion in regulated sectors.
The shift from managing hardware to operating an API-driven estate. What day two actually contains, why traditional change control fails against self-service provisioning, and how CloudOps relates to SRE, FinOps, platform engineering and the security function without duplicating any of them.
Topics: Day one versus day two responsibilities · Why ticket-based change control breaks in a self-service estate · Preventative controls versus detective controls · CloudOps, SRE, FinOps and platform engineering — the actual boundaries · Operating models: central team, embedded, or platform-as-a-product · Defining ownership for a resource that anyone can create
The controls that stop problems being created rather than finding them afterwards. Organisation hierarchy, account or subscription vending, policy that denies non-compliant resources at the API, tagging enforced at creation, and quota and region restrictions.
Topics: Organisation hierarchy, organisational units and management groups · Account, subscription and project vending · Preventative policy: service control policies, Azure Policy, organisation policy · Region and service allow-lists · Tagging strategy and enforcement at creation · Quotas, limits and requesting increases before you need them · Baseline resources every new account receives · Exception handling that does not become the default path
Making the desired state authoritative. Pipelines for infrastructure change, review and approval, state and locking, environment promotion, then drift — how it happens even under discipline, how to detect it continuously and when to reconcile versus adopt.
Topics: Infrastructure pipelines: plan, review, approve, apply · State, locking and blast-radius partitioning · Environment promotion and parameterisation · Modules, versioning and an internal module registry · Drift detection and continuous conformance · Reconcile, adopt or delete — deciding what to do about drift · Emergency change and how to bring it back into code · Importing an existing estate into code
Monitoring things you cannot log into. Provider-native metric and log platforms versus open-source stacks, structured logging and retention cost, distributed tracing across managed components, synthetic checks, and the provider health events that explain outages you did not cause.
Topics: Provider-native monitoring versus Prometheus, Grafana and OpenTelemetry · Metrics that exist for managed services, and the ones that do not · Centralised logging, retention tiers and query cost · Distributed tracing across functions, queues and managed databases · Synthetic monitoring and real user signals · Provider health events and status feeds · Dashboards for operators versus dashboards for stakeholders · Instrumenting an estate consistently by default
Turning signals into action. Alerting on symptoms rather than causes, routing and escalation, on-call rotations that are humane, the anatomy of a cloud incident including provider-side failures, and the review that turns an outage into a change.
Topics: Symptom-based alerting and alert fatigue · Severity definitions, routing and escalation policy · On-call rotations, handover and follow-the-sun · Incident command, roles and communication · Triage when the failure is on the provider's side · Runbooks that are executable rather than descriptive · Automated remediation and when to allow it · Blameless review and tracking the actions to completion
Recovery you have actually performed. Deriving RTO and RPO from the business, backup coverage across every data store in the estate, cross-region and cross-account copies, restore testing on a schedule, and DR patterns priced honestly.
Topics: Deriving RTO and RPO, and costing each level · Backup coverage audit across every stateful service · Immutable and cross-account backup against ransomware and error · Restore testing as a scheduled, evidenced activity · DR patterns: backup-restore, pilot light, warm standby, active-active · Failover mechanics, DNS and data reconciliation · Zonal and regional failure modes, and correlated risk · Game days and chaos exercises against a real estate
The continuous half of cloud security. Posture management and misconfiguration detection, identity hygiene as an ongoing task, secrets and key rotation, vulnerability and patch operations for images and managed platforms, and producing audit evidence from the platform rather than by hand.
Topics: Posture management and misconfiguration detection · Identity hygiene: unused credentials, stale roles, privilege creep · Secrets management, rotation and eliminating long-lived keys · Image, patch and managed-platform version lifecycle · Public exposure detection — storage, databases, endpoints · Audit logging, tamper resistance and retention · Continuous compliance and evidence generation · Handling a credential leak or exposed resource
Operating the bill as a system signal. Attribution through tagging and account structure, unit economics, commitment and discount management, rightsizing from evidence, and the architectural decisions — storage class, instance family, egress, idle non-production — behind most waste.
Topics: Cost attribution: tags, accounts and shared-cost allocation · Unit economics — cost per customer, per transaction, per environment · Budgets, forecasts and anomaly detection · Commitment discounts, coverage and utilisation · Rightsizing from observed usage rather than requested size · Storage class and lifecycle optimisation · Egress, cross-zone and inter-service traffic cost · Non-production scheduling and idle resource reclamation · Showback, chargeback and making teams accountable without blocking them
We rebuild the agenda around the tools you actually run.
Request a custom agendaVend a new account with a compliant baseline, then prove the guardrails by attempting to create untagged, unencrypted and out-of-region resources.
Introduce configuration drift manually, detect it with continuous conformance checks, and reconcile it through the infrastructure pipeline without recreating the resource.
Instrument a managed database and a serverless function using only exposed signals, build an operator dashboard, and cut log spend without losing incident-critical fields.
Run a full incident against a live environment — triage, provider health checks, mitigation, stakeholder comms — then complete a blameless review with tracked actions.
Audit backup coverage across the estate, find the unprotected stateful resources, then restore a production-shaped dataset and record the real RTO.
Attribute a month of spend, identify the architectural drivers behind the top lines, and deliver a rightsizing and lifecycle plan with quantified saving and risk.
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
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.
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.
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.
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.