Private corporate batches, live online cohorts and 1-on-1 mentoring in centralised secrets management, dynamic credentials and encryption as a service — 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 Vault around its four primitives — auth methods, policies, secrets engines and audit devices — rather than as a command list, so attendees can reason about a requirement they have not seen before. Sessions cover initialisation and unseal strategy, integrated Raft storage, AppRole and Kubernetes authentication, dynamic database and cloud credentials with leases, PKI issuance and the transit engine, and the Vault Agent injection patterns that get a secret into a workload — with sealing, rekeying and disaster recovery practised live rather than described.
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 Vault that means a trainer who has run it in production — centralised secrets management, dynamic credentials and encryption as a service — 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 Vault batchVault is HashiCorp's secrets management system. It holds credentials, API keys, certificates and encryption keys behind an authenticated, audited API, and it replaces the pattern most organisations start with — secrets in environment files, in configuration management, in CI variables and in a spreadsheet somebody owns. Every read is authenticated, authorised by policy and written to an audit device, so 'who could read this credential, and when did they' becomes a query rather than an investigation.
The part that changes architecture is dynamic secrets. Rather than storing a database password, Vault holds credentials for the database and mints a new, short-lived user on demand when an application authenticates. That credential carries a lease; when the lease expires or is revoked, Vault removes the user. The same model covers cloud IAM credentials, SSH access and PKI certificates. Secrets stop being long-lived shared values that nobody can safely rotate, and rotation becomes the default behaviour rather than a project.
Vault is built from a small set of composable primitives: auth methods that decide how a client proves identity, policies written in HCL that grant capabilities on paths, secrets engines mounted at paths that produce or store the secrets themselves, and audit devices that record everything. Almost every real deployment question — how a pod gets a database password, how a pipeline signs an artifact, how an application encrypts a column without holding the key — is answered by choosing the right combination of those four.
Secrets sprawl scales with the number of services, and microservice and Kubernetes adoption multiplied that count without giving teams anywhere better to put credentials. The result is the pattern auditors keep finding: the same database password in a CI variable, a container image layer, three repositories and a wiki page, with no way to rotate it because nobody knows every consumer.
Regulatory and customer pressure closed the other side. Audit questions now ask for credential lifetime, rotation evidence and per-identity access records, and none of those can be answered by a static secret in a config file. Vault has become the default answer in the HashiCorp-adjacent toolchain and, increasingly, the reference implementation that other secret stores are compared against.
The hiring gap is operational rather than conceptual. Running a dev-mode server and writing a key-value pair takes ten minutes. Designing an auth and policy model that scales across teams, choosing a storage and unseal strategy, running Vault in HA with disaster recovery, and — the part that catches people — recovering a production cluster that has sealed itself at three in the morning are the skills organisations are short of.
Why credential sprawl happens and what a secrets manager has to provide to fix it. Vault's internal model — the barrier, the storage backend, the seal, and the path-based API that everything else is built on — plus an honest account of what Vault does not solve.
Topics: Credential sprawl and its failure modes · The Vault threat model and trust boundaries · Barrier, storage backend and encryption at rest · Seal and unseal: Shamir key shares and thresholds · Paths, mounts and the HTTP API · Auth methods, policies, secrets engines and audit devices · Where Vault is the wrong answer
Getting from dev mode to something you could run. HCL server configuration, listener and TLS setup, choosing a storage backend, initialising a cluster and understanding exactly what the unseal keys and root token are — and why they should not be where you first put them.
Topics: Dev mode versus a real server, and why dev mode misleads · Server HCL: listener, storage, telemetry and cluster stanzas · TLS configuration and certificate management for the API · Integrated Raft storage versus external backends · Initialisation, unseal keys and the root token · Auto-unseal with cloud KMS and transit seal · Seal migration and what happens on restart
How a client proves who it is, which is the hardest design decision in a Vault deployment. Token mechanics first, then the machine and human auth methods, then the identity system that lets you attach policy to a person or workload rather than to each credential.
Topics: Token types, TTLs, renewal, orphan and batch tokens · AppRole: role ID, secret ID and response wrapping · Kubernetes auth and service account token review · JWT and OIDC auth for CI and for humans · LDAP and cloud IAM auth methods · Identity entities, aliases and groups · Choosing an auth method per consumer type
Vault denies by default; everything a client can do comes from policy. Path matching, the capability set, how deny interacts with allow, parameter constraints, and templated policies that let one policy serve many identities without generating one policy per team.
Topics: HCL policy syntax and path matching, including globs and segments · Capabilities: create, read, update, delete, list, sudo, deny · Policy evaluation order and the precedence of deny · Allowed and denied parameters, and required parameters · Templated policies driven by identity metadata · The default and root policies, and avoiding root in normal operation · Testing and reviewing policies before rollout
The engines that actually hold or produce secrets. KV version 1 and 2 with versioning and soft delete, then the shift that matters: database, cloud and SSH engines that generate credentials on demand with a lease, and the revocation machinery that cleans them up.
Topics: KV v1 versus v2: versioning, metadata, soft delete and destroy · Leases, TTLs, max TTL, renewal and revocation · The database secrets engine and connection configuration · Rotating the root credential Vault itself uses · AWS, Azure and GCP dynamic credentials · SSH secrets engine: signed certificates and one-time passwords · Lease accounting, tidy operations and revocation at scale
Two engines that change what applications have to implement. Running an internal certificate authority with short-lived certificates and automated renewal, and using the transit engine so services encrypt, decrypt, sign and verify without ever holding key material.
Topics: PKI engine: root CA, intermediate CA and the signing chain · PKI roles, allowed domains and certificate TTLs · Issuing, renewing and revoking certificates; CRL and OCSP considerations · Short-lived certificates and why rotation beats revocation · Transit engine: encrypt, decrypt, sign, verify and HMAC · Key rotation, key versions and rewrapping ciphertext · Convergent encryption and derived keys
The last mile, and where most implementations get sloppy. Vault Agent auto-auth and templating, the Kubernetes injector and CSI provider, the Terraform provider, and CI integration — plus the recurring question of how the first credential gets to the client at all.
Topics: The secret zero problem and response wrapping · Vault Agent: auto-auth, caching and template rendering · The Kubernetes agent injector and annotation-driven injection · The Secrets Store CSI driver as an alternative · Vault provider for Terraform, and keeping secrets out of state · CI integration patterns for Jenkins, GitLab and GitHub Actions · Application-side SDK use versus sidecar delivery
The module that decides whether a deployment survives. Audit devices and what they log, telemetry and the metrics that predict trouble, snapshots and restore, rekeying and root token generation, upgrades, and rehearsed procedures for the failures that will happen.
Topics: Audit devices, log format and the requirement that audit must succeed · Telemetry, key metrics and alerting thresholds · Raft snapshots, automated snapshots and restore drills · Rekey, rotate and generating a root token from unseal keys · Upgrade paths and rolling upgrades in HA · Disaster recovery and performance replication concepts · Break-glass procedure design and who holds the key shares · Namespaces and multi-tenancy considerations
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild an HA Vault cluster on integrated storage with TLS and cloud KMS auto-unseal, then kill the leader and observe failover.
Authenticate a pod using the Kubernetes auth method and a CI job using AppRole with response-wrapped secret IDs, with no static credentials on either side.
Configure the database secrets engine, cut an application over to leased credentials, rotate the root credential, and force-revoke an active lease.
Build a root and intermediate CA in Vault, issue short-lived service certificates, automate renewal and observe what happens when renewal fails.
Encrypt application data through the transit engine, rotate the encryption key, rewrap existing ciphertext and verify old versions still decrypt.
Take a snapshot, destroy the cluster, restore into fresh nodes, generate a root token from key shares and prove every application reconnects.
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 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.
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.
| 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.