Private corporate batches, live online cohorts and 1-on-1 mentoring in projects, IAM, networking, GKE and data services on Google Cloud — 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 Google Cloud around the resource hierarchy and IAM inheritance first — organisation, folders, projects, and the allow-only policy model that behaves nothing like the deny-driven systems most engineers arrive with. Sessions run live in a real project: service account keys are deleted and replaced with Workload Identity Federation, VPC firewall rules are tightened until only the intended path works, and GKE workloads are deployed from Cloud Build so nothing built by hand in the console survives the lab.
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 Google Cloud that means a trainer who has run it in production — projects, IAM, networking, GKE and data services on Google Cloud — 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 Google Cloud batchGoogle Cloud is Google's public cloud platform — compute, storage, networking, managed databases, data analytics and machine learning services delivered on the same infrastructure that runs Google's own products. Its organising unit is the project. Every resource belongs to exactly one project, every API must be explicitly enabled per project, and billing, quota and IAM all attach at that level, which makes the project the natural blast-radius and cost boundary rather than an administrative afterthought.
Above projects sits the resource hierarchy — organisation, folders, projects — and IAM policies inherit down it. Google Cloud IAM is allow-only by default: a role binding grants permissions to a principal at a node, children inherit, and there is no implicit deny to unwind. Service accounts are first-class principals, Workload Identity Federation lets external systems act without exported keys, and organisation policy constraints impose the guardrails that IAM alone cannot express.
The networking model is what most engineers find genuinely different. A VPC in Google Cloud is a global object with regional subnets, so a single network can span continents without peering, and the global external load balancer terminates connections at the edge with one anycast address. On top of that sit Compute Engine and managed instance groups, Cloud Run and Cloud Functions for request-driven work, GKE for Kubernetes, Cloud Storage, Cloud SQL, Spanner, Firestore and BigQuery for data, and Cloud Logging, Monitoring and Trace for operations. Cloud Build and Terraform bind it all into something reproducible.
Google Cloud has become the platform of choice in two specific places: data and analytics workloads that gravitate to BigQuery, and container platforms where GKE is still the most mature managed Kubernetes on the market. That concentration means Google Cloud skills tend to be hired for a purpose rather than in general — data platform teams, Kubernetes platform teams, and increasingly ML infrastructure.
It is also the second or third cloud in a large number of enterprises. Multi-cloud is rarely a strategy anyone chose, but it is a reality after acquisitions, data-residency requirements and vendor negotiations, and it creates demand for engineers who can map concepts across providers accurately rather than by analogy. Knowing that a Google Cloud VPC is global while an AWS VPC is regional is the kind of detail that changes an architecture.
The hiring bar has moved past the console. Organisation policy constraints, Workload Identity Federation instead of exported service account keys, VPC Service Controls around sensitive data, GKE Autopilot versus Standard, and BigQuery slot and storage cost modelling are what distinguishes someone who can run Google Cloud from someone who has used it. Those are design decisions, and they are made once, early, and expensively if wrong.
The structural layer that decides everything downstream. Organisation, folders and projects; why per-project API enablement and quota matter; then IAM as an allow-only inheritance model, with service accounts as first-class principals and Workload Identity Federation as the way to stop exporting keys.
Topics: Organisation, folders, projects and resource inheritance · Billing accounts, budgets, quotas and API enablement · IAM principals, roles and policy bindings; basic, predefined and custom roles · IAM conditions and policy troubleshooting with the Policy Analyzer · Service accounts, impersonation and short-lived credentials · Workload Identity Federation for external and CI systems · Organisation policy constraints as guardrails · gcloud, Cloud Shell, the console and the REST API
The model that is genuinely different from other clouds. A global VPC with regional subnets, firewall rules evaluated by priority with implicit rules underneath, and private connectivity patterns — Private Google Access, Cloud NAT, Private Service Connect — that keep workloads off public addresses entirely. Then Shared VPC for multi-team estates.
Topics: Global VPCs, regional subnets and IP address planning · Firewall rules, priorities, tags, service accounts as targets, and hierarchical policies · Routes, Cloud NAT and Private Google Access · Shared VPC and VPC Network Peering · Private Service Connect and private access to managed services · Cloud DNS: public, private and forwarding zones · Cloud Load Balancing — global external, regional and internal · Cloud Interconnect, Cloud VPN and hybrid connectivity
Three ways to run code and the honest criteria for choosing. Compute Engine machine types, images, metadata and managed instance groups with autohealing and autoscaling; then the serverless containers of Cloud Run — concurrency, scaling to zero, min instances — and Cloud Functions for event-driven glue.
Topics: Compute Engine machine families, disks, images and metadata · Instance templates, managed instance groups, autohealing and autoscaling · Preemptible and Spot VMs, committed use discounts and sustained use · Cloud Run: containers, concurrency, revisions and traffic splitting · Cloud Run scaling, min instances, cold starts and VPC egress · Cloud Functions triggers — HTTP, Pub/Sub, Cloud Storage, Eventarc · Choosing between Compute Engine, Cloud Run, Cloud Functions and GKE · OS Login, IAP TCP forwarding and instance access without public IPs
Where state lives, from objects to warehouses. Cloud Storage classes, lifecycle rules, uniform bucket-level access and signed URLs; Cloud SQL with high availability and read replicas; Spanner and Firestore for globally distributed data; and BigQuery, treated as an engineering system with real cost mechanics rather than as a query box.
Topics: Cloud Storage: buckets, storage classes, lifecycle rules and retention · Uniform bucket-level access, IAM versus ACLs, and signed URLs · Persistent Disk, Hyperdisk and Filestore · Cloud SQL: high availability, read replicas, backups and point-in-time recovery · Cloud Spanner and Firestore — when global consistency is worth the cost · BigQuery: datasets, tables, partitioning, clustering and slots · BigQuery cost model — on-demand versus capacity pricing · Pub/Sub, Dataflow and the ingestion path into BigQuery
Kubernetes as Google Cloud delivers it. Autopilot versus Standard and what each takes away, node pools, cluster and node autoscaling, and the networking modes that decide IP consumption. Then the parts unique to GKE: workload identity for keyless access to Google APIs, Artifact Registry, and Gateway API with Google Cloud load balancers.
Topics: GKE Autopilot versus Standard, and the trade-offs of each · Node pools, node auto-provisioning, cluster autoscaler and spot nodes · VPC-native clusters, alias IP ranges and private clusters · Workload Identity for keyless access to Google Cloud APIs · Artifact Registry, image scanning and Binary Authorization · Ingress, Gateway API and container-native load balancing · GKE upgrades, release channels, maintenance windows and surge settings · Config Connector and managing Google Cloud resources from Kubernetes
Knowing what the platform is doing. Cloud Monitoring metrics, dashboards and alerting policies; Cloud Logging with log sinks, exclusions and log-based metrics; Trace, Profiler and Error Reporting. Then SLOs as the mechanism that makes alerting mean something rather than accumulate.
Topics: Cloud Monitoring: metrics, metric explorer, dashboards and uptime checks · Alerting policies, notification channels and alert fatigue · Cloud Logging: log router, sinks to BigQuery and Cloud Storage, exclusions · Log-based metrics and structured logging · Cloud Trace, Profiler and Error Reporting · SLIs, SLOs and error budgets in Cloud Monitoring · Audit logs — admin activity, data access and policy denied · Incident response and postmortem practice
Making the estate reproducible and defensible. Terraform against Google Cloud with remote state and module structure, Cloud Build for CI/CD with keyless authentication, then the security controls — CMEK, Secret Manager, VPC Service Controls, Security Command Center — and the cost mechanics that decide whether the design survives a finance review.
Topics: Terraform on Google Cloud: provider setup, remote state in Cloud Storage, module layout · Cloud Build triggers, substitutions and keyless deploys via Workload Identity Federation · Infrastructure Manager and Config Controller · Secret Manager, CMEK with Cloud KMS and envelope encryption · VPC Service Controls perimeters around sensitive data · Security Command Center, findings and posture management · Billing export to BigQuery, labels, budgets and committed use analysis · Landing zone patterns and multi-project bootstrapping
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a project that authenticates CI and workloads with exported JSON keys, migrate it to Workload Identity Federation and workload identity, then disable key creation with an organisation policy.
Build a VPC where nothing has a public address, yet workloads still reach Google APIs, pull images and egress to the internet through Cloud NAT and Private Google Access.
Stand up a private GKE cluster with workload identity and Binary Authorization, and prove that an unsigned image is rejected at admission.
Load a realistic dataset, run the same analytical queries against unpartitioned, partitioned and clustered tables, and quantify the bytes scanned and the money involved.
Instrument a service, define an availability and latency SLO in Cloud Monitoring, and build multi-window burn-rate alerts instead of threshold noise.
Deliver a Terraform-defined landing zone with hierarchy, Shared VPC, guardrails, GKE, observability and billing export, and prove it by destroying and recreating it.
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.
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.
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 advisorPrefer to call or email?
More ways to reach us on the contact page.