SRE Labs (Advanced Track) — Program Overview & Curriculum Orientation
Structured educational resource covering sre labs (advanced track) — program overview & curriculum orientation.
senior 45 min read 13 sections
#kubernetes#cloud-k8s#aws#gcp
Learning Package — Projects, Methodology, Tools & Production Drill Format
Source:
2026-01-07-210713.md— Orientation / intake call for the SRE Labs (Advanced Track) 6-week bootcamp. Presenter: Lead SRE (lead instructor). This is a programme overview session, not a technical teaching session. There is no new DevOps content delivered in isolation — what is valuable here is the curriculum roadmap, the four project scopes, the tools stack, the production drill methodology, and the high-level technical agenda for each project that frames everything that follows in the program.Note on this package: Per the instruction to ignore general discussion not related to DevOps topics, the following sections are excluded: enrolment/pricing Q&A, certificate and referral admin, timezone questions, playground access duration admin, and personal background discussions from attendees. Only DevOps-relevant content is documented.
2. Table of Contents
- Executive Summary
- Table of Contents
- Programme Format and Structure
- Project 1 — AWS Cost Optimisation (HealthCorp Client)
- Project 2 — Cloud Security Audit (Fintech/Blockchain Client)
- Project 3 — Scalability & Observability (500+ Microservice Platform)
- Project 4 — Automation & AI (CleverOps / Self-Healing Infrastructure)
- Bonus — Apna Cloud (Own Data Centre Platform)
- Production Drill Methodology (War-Room Format)
- Tools & Technologies Across All Projects
- Architecture & Workflow Analysis
- Key Concepts Table
- Interview & Career Development Components
- Gaps & Assumptions
3. Programme Format and Structure
Schedule
| Day | Activity |
|---|---|
| Saturday | Production drill / war-room (live outage simulation, 60-min squad session) |
| Sunday | Project call (live client case study walkthrough) |
| Wednesday | Doubt class / Q&A session |
| Weekdays | Self-paced learning, assignments on playground clusters, squad Discord calls |
Duration
- 6 weeks of structured content + optional 7th and 8th week for mock interviews
- Cohort start: 17 January; end: 28 February (with post-programme support)
Prerequisite
- Minimum ~1 year of DevOps experience OR solid theoretical understanding of Docker and Kubernetes
- Not designed for complete beginners — the programme assumes you know how tools work; it focuses on production-grade use
Format
- Live sessions on video call (Zoom)
- Hands-on assignments on cloud playgrounds (AWS, GCP, Azure) — provided by SRE Labs
- Code, manifests, and Terraform modules on GitHub (anonymised versions)
- Labs eventually on Platform Knowledge Base (browser-based K8s clusters, team war-rooms, leaderboards)
- Recordings available after each session
What this programme is
”It’s not about creating the infrastructure but about maintaining the infrastructure.”
Focus areas: production troubleshooting, real incident patterns, observability, CI/CD at scale, security audits, cost engineering — all on actual client environments.
4. Project 1 — AWS Cost Optimisation (HealthCorp Client)
Client Context
- Healthcare client (referred to as HealthCorp)
- Running on AWS
- Monthly bill: ~$98,000/month
- Identified savings scope: ~$8,000/month
Optimisation Workstreams
Compute (EC2)
| Workstream | Description |
|---|---|
| Non-prod environment shutdown | Schedule start/stop for dev/staging environments (stop at 10 PM IST, start at 8 AM IST) to eliminate overnight spend |
| Intel → AMD architectural migration | Change instance family from Intel (no suffix) to AMD (a suffix, ~15–20% cheaper) for compatible workloads |
| AMD → Graviton (ARM) migration | Further migration to Graviton (g suffix, ~30–40% cheaper); requires compatibility assessment (different ISA) |
| Right-sizing | Analyse CPU/memory utilisation via Compute Optimizer; resize over-provisioned instances |
| On-Demand → Spot migration | Identify stateless workloads suitable for Spot (up to 70–90% discount) |
| Multi-age EC2 optimisation | Handling instances that have been running for extended periods with varying usage patterns |
EKS (Kubernetes)
| Workstream | Description |
|---|---|
| Replace Cluster Autoscaler with Karpenter | Intelligent node provisioning — right-sized nodes on demand instead of fixed node groups |
| CastAI integration | FinOps tool for EKS; workload right-sizing, Spot migration recommendations, multi-cluster visibility |
| Node-level optimisation | Node group sizing, instance type selection, Spot node pools |
| Pod-level optimisation | Resource requests/limits, QoS tuning, HPA configuration |
| Cluster-level optimisation | Namespace resource quotas, consolidation, idle workload detection |
Storage
| Service | Approach |
|---|---|
| RDS | Right-sizing, Reserved Instances, storage tier optimisation |
| S3 | Lifecycle policies, storage class tiering (Standard → Standard-IA → Glacier) |
| ElastiCache (Redis) | Right-sizing, Reserved Node options |
Savings Plans
- Analysis of committed-use discounts (Compute Savings Plans vs. EC2 Instance Savings Plans)
- Dedicated session on how to buy Savings Plans correctly (match to stable baseline spend)
Monitoring & Logging
- Smart observability stack that reduces CloudWatch costs while maintaining coverage
- Log retention tuning, metric resolution optimisation
Networking
- NAT Gateway cost analysis
- VPC Endpoint vs. NAT Gateway trade-off
- Data transfer optimisation between AZs and regions
Tools Used in Project 1
- AWS Cost Explorer
- AWS Compute Optimizer
- AWS Trusted Advisor
- Karpenter
- CastAI
- Kubecost (mentioned)
5. Project 2 — Cloud Security Audit (Fintech/Blockchain Client)
Client Context
- Fintech client operating in the blockchain industry
- End-to-end security audit: engineering tools + cloud infrastructure
Security Audit Scope
EKS / Kubernetes Security
| Tool | Purpose |
|---|---|
| Kube-bench | CIS Kubernetes Benchmark compliance — pass/warn/fail per CIS control |
| Kube-hunter | Penetration testing from inside a pod — simulates attacker with cluster access |
| Kubescape | Comprehensive misconfiguration + compliance scanning (NSA, MITRE, CIS frameworks) |
| Plus: pen testing on EKS | Broader attack surface testing beyond the three tools above |
Cloud Infrastructure Security
| Tool | Purpose |
|---|---|
| ScoutSuite | Attacker’s-view AWS/multi-cloud audit — identifies exploitable misconfigurations |
| Prowler | Compliance-focused AWS scanning (CIS, PCI-DSS, SOC2, HIPAA, GDPR) |
| GCP Audit Tool | GCP-specific security scanning (Security Command Center equivalent) |
Audit Categories
- IAM (users, roles, policies — least privilege assessment)
- Network security (VPC, security groups, NACLs, public exposure)
- Data security (encryption at rest/in transit, public S3 buckets)
- EKS cluster hardening (pod security, RBAC, network policies)
- Engineering tool security (CI/CD, code repositories, secrets management)
6. Project 3 — Scalability & Observability (500+ Microservice Platform)
Client Context
- Large MNC with 500–800 microservices
- E-commerce/enterprise platform handling high-traffic events (Black Friday, sales)
- Multi-region deployment: AP-South-1, US-East-1, EU
Subprojects
CI/CD at Scale
- Matrix deployment strategy: single codebase deployed to 3 regions simultaneously via GitHub Actions matrix
- Inter-region dependency management in the pipeline
- Rollback automation
- Caching in CI/CD pipelines (cost optimisation on compute)
- Alerting integration in CI/CD
Terraform at Scale
- Module-based IaC structure for 500+ service infrastructure
- Environment separation via Terraform workspaces/modules
- State management patterns for large-scale infrastructure
- Managing interdependencies across modules
Observability Stack
A three-level observability setup:
- System monitoring — infrastructure health metrics (CPU, RAM, disk, network)
- Application observability — request traces, error rates, latency per service
- User behaviour monitoring — user experience metrics, funnel analytics, session behaviour
Tools in the observability stack:
| Tool | Role |
|---|---|
| Prometheus | Metrics collection and storage |
| Grafana | Dashboards and visualisation (300–400 dashboards per project) |
| Tempo | Distributed tracing (Jaeger alternative) |
| Loki | Log aggregation |
| VictoriaMetrics | High-performance Prometheus-compatible metrics storage at scale |
| Jaeger / OpenTelemetry | Distributed tracing (also mentioned) |
Scalability & HA
- HPA configuration for demand and memory-based scaling
- Multi-region active-active architecture
- Traffic management during sale events (Black Friday pattern)
- PDB configuration for controlled rolling deployments
7. Project 4 — Automation & AI (CleverOps)
Concept
An in-house product built to automate DevOps operations for organisations without dedicated DevOps engineers. Targets startups and small teams who need infrastructure management but lack the expertise or budget.
Capabilities
| Capability | Description |
|---|---|
| CI/CD pipeline creation | From a Slack/Teams prompt — create a pipeline for a GitHub repo and deploy to cloud |
| Cloud deployment | Deploy services to AWS/GCP from a natural language instruction |
| Observability integration | Auto-integrate Prometheus + Grafana from scratch without requiring expertise |
| Secret rotation | Automated workflow for injecting/rotating secrets across CI/CD pipeline and infrastructure |
| Self-healing infrastructure | Automatic detection and remediation of production outages (the target state) |
| Cloud account management | For users with no AWS/GCP expertise — manage resources via conversational interface |
Tools Integrated in This Project
FlightControl (flightcontrol.dev):
- AWS-native infrastructure automation
- Self-hostable (data residency compliant)
- Slack/Teams integration
- Generates CloudFormation for resource creation
QBR.AI:
- Workflow automation platform
- Creates repeatable DevOps workflows (secret rotation, deployment, etc.)
- Foundation on which CleverOps workflows are built
Architecture
- Natural language interface via Slack or Teams
- Under the hood: agentic AI → QBR.AI workflow execution → AWS/GCP API calls
- Terraform-backed for infrastructure state management
- GitHub integration for source code deployments
Distinction from Terraform MCP
The instructor addressed this explicitly: CleverOps targets users with no technical background at all — not just those who don’t want to write Terraform. Additionally, the self-healing/autonomous remediation capability goes beyond what a Terraform MCP provides (which is infrastructure provisioning only, not incident detection and response).
8. Bonus — Apna Cloud (Own Data Centre Platform)
SRE Labs’s own managed cloud platform (private data centres):
- Own S3-equivalent object storage
- Own RDS-equivalent managed database
- Own EKS-equivalent managed Kubernetes
- Purpose: teaching participants how these managed services work under the hood by building them from scratch
- Included as a bonus module for deeper understanding of cloud primitives
9. Production Drill Methodology (War-Room Format)
This is the Saturday format. It is the core differentiated learning mechanism of the programme.
Preparation Phase (before the session)
- Documentation uploaded to Google Drive (problem statement, client infrastructure description, blast radius, timeline)
- Architecture diagram shared
- Participants read the background before the call
Session Flow
Phase 1: Context Setting (~20 min)
→ Instructor whiteboard session
→ Explain the infrastructure (architecture, components, dependencies)
→ Explain the production outage (what broke, when, symptoms)
→ Explain upstream/downstream flow
→ Define blast radius
Phase 2: CLI Walkthrough (~10 min)
→ Instructor walks through the cluster/environment live
→ Shows what the error looks like in real terminal output
→ Shows initial observations (pod statuses, events, logs)
Phase 3: Squad War-Room (~60 min)
→ Participants divided into squads (by experience/cloud platform)
→ Each squad gets their own playground cluster with the outage replicated
→ 60-minute countdown timer
→ SRE Labs team members join different squads to guide
→ Squads debug and fix the outage independently
Phase 4: Debrief & RCA (~20 min)
→ All squads reconvene on the main call
→ Each squad shares their troubleshooting approach
→ Instructor discusses the correct approach
→ RCA document written collaboratively
What Each Production Outage Contains
Each drill comes with a structured documentation pack:
- Business context — what the organisation does, why the service matters
- Infrastructure setup — cluster structure, node groups, namespaces, deployments
- Incident description — what went wrong, timeline, symptoms
- Blast radius — what was impacted, what was safe
- Troubleshooting walkthrough — step-by-step commands that were run
- Correct troubleshooting framework — the structured approach
- Root Cause Analysis (RCA) — why it happened and how to prevent it
- Challenge component — steps to reproduce on the playground
Three Published Production Outage Scenarios
Available on the programme’s GitHub with playground replication steps:
| Outage # | Domain | Description |
|---|---|---|
| 1 | CI/CD | Pipeline failure scenario — build/deploy related production issue |
| 2 | Kubernetes Security | Security misconfiguration causing a production security incident |
| 3 | Observability | Monitoring/alerting failure — metrics or alerting stack breakdown |
Playground Replication
- 3–4 commands to replicate the outage on your own cluster
- Available on GitHub after the session
- Can be repeated independently for self-study
10. Tools & Technologies Across All Projects
Cost Optimisation
| Tool | Purpose |
|---|---|
| AWS Cost Explorer | Visualise, filter, and analyse AWS costs |
| AWS Compute Optimizer | ML-based right-sizing recommendations for EC2, EKS, Lambda |
| AWS Trusted Advisor | Cost, security, and performance recommendations |
| Karpenter | Intelligent EKS node autoscaler (replaces Cluster Autoscaler) |
| CastAI | SaaS EKS/GKE/AKS cost optimiser and right-sizing platform |
| Kubecost | Kubernetes cost visibility per namespace/workload/team |
| Splunk | Mentioned in the context of FinOps tooling |
Security
| Tool | Purpose |
|---|---|
| Kube-bench | CIS Kubernetes Benchmark compliance audit |
| Kube-hunter | K8s penetration testing (attacker simulation from inside a pod) |
| Kubescape | K8s misconfiguration and compliance scanning |
| ScoutSuite | Multi-cloud security posture assessment (attacker view) |
| Prowler | AWS/GCP/Azure compliance scanning (CIS, PCI, HIPAA, SOC2, GDPR) |
| GCP Security Command Center | GCP-native security findings |
Observability
| Tool | Purpose |
|---|---|
| Prometheus | Metrics collection and alerting rules |
| Grafana | Dashboards and visualisation |
| Loki | Log aggregation |
| Tempo | Distributed tracing |
| VictoriaMetrics | High-performance Prometheus-compatible metrics storage |
| Jaeger / OpenTelemetry | Distributed tracing and instrumentation |
CI/CD & IaC
| Tool | Purpose |
|---|---|
| GitHub Actions | CI/CD pipeline (including matrix deployment strategy) |
| Jenkins | CI/CD alternative |
| Terraform | Infrastructure as Code for all projects |
Automation & AI
| Tool | Purpose |
|---|---|
| FlightControl | AWS automation via natural language (Slack/Teams) |
| QBR.AI | DevOps workflow automation platform |
| CleverOps | SRE Labs’s in-house product (agentic AI + workflow automation + self-healing) |
Kubernetes / Cloud
| Tool | Purpose |
|---|---|
| Amazon EKS | Managed Kubernetes on AWS |
| Google GKE | Managed Kubernetes on GCP |
| Azure AKS | Managed Kubernetes on Azure |
| Cluster Autoscaler | Legacy EKS node autoscaler (being replaced by Karpenter in projects) |
11. Architecture & Workflow Analysis
Programme Structure Overview
6-Week SRE Labs (Advanced Track) Bootcamp
WEEK 1–2: Foundation
Saturday: Linux/SSH production outage war-room
Sunday: K8s basics production drill
Weekdays: Self-paced Linux/K8s fundamentals + assignments
WEEK 3–4: Cost & Security
Saturday: K8s war-room drills (pod scheduling, resource issues)
Sunday: Project 1 (AWS Cost Optimisation — HealthCorp client)
Project 2 (Security Audit — fintech client)
Weekdays: Assignments on playground clusters
WEEK 5–6: Scale & Automation
Saturday: Advanced war-room drills
Sunday: Project 3 (500+ microservices — scalability, observability, CI/CD)
Project 4 (CleverOps — automation & AI)
Weekdays: Mini projects (e.g., integrate observability into Jenkins pipeline)
WEEK 7–8 (bonus): Career
Mock interviews (1:1 with SRE Labs team, by squad scheduling)
CV optimisation session
LinkedIn/Naukri profile review
Job referral network activation
Four Project Pillars
╔══════════════════════════════════════════════════════════════════════╗
║ SRE Labs (Advanced Track) — 4 Pillars ║
╠════════════════╦═════════════════╦══════════════════╦════════════════╣
║ COST ║ SECURITY ║ SCALABILITY ║ AUTOMATION ║
║ Project 1 ║ Project 2 ║ Project 3 ║ Project 4 ║
║ ║ ║ ║ ║
║ HealthCorp Client ║ Fintech/ ║ MNC (500+ ║ CleverOps ║
║ AWS ~$98K/mo ║ Blockchain ║ microservices) ║ Self-healing ║
║ ║ Client ║ ║ infra ║
║ EC2 migration ║ K8s audit: ║ CI/CD matrix ║ FlightControl ║
║ Karpenter ║ kube-bench ║ Terraform mods ║ QBR.AI ║
║ CastAI ║ kube-hunter ║ Observability ║ AI workflows ║
║ Savings Plans ║ kubescape ║ 3-region deploy ║ ║
║ RDS/S3/net ║ ScoutSuite ║ HPA + PDB ║ ║
║ ║ Prowler ║ 500 dashboards ║ ║
╚════════════════╩═════════════════╩══════════════════╩════════════════╝
Production Drill War-Room Flow
Before session:
Documentation → Architecture diagram → Problem statement
On the call:
Whiteboard context (20 min)
↓
CLI walkthrough by instructor (10 min)
↓
Split into squads
↓
60-minute war-room (each squad: own cluster + outage replicated)
↓
Debrief: squads share approaches → correct framework → RCA (20 min)
After session:
Playground remains available → self-replication (3–4 commands)
Code uploaded to GitHub (anonymised)
12. Key Concepts Table
| Concept | Explanation | Example in Programme | Why It Matters |
|---|---|---|---|
| Matrix deployment strategy | Deploy the same code to N regions simultaneously using CI/CD matrix jobs | Project 3: GitHub Actions deploying to AP-South-1, US-East-1, EU simultaneously | Enables multi-region deployments without N separate pipeline definitions |
| Karpenter | Intelligent EKS node autoscaler — provisions right-sized nodes based on pod resource requests | Replaces Cluster Autoscaler in Project 1 | Eliminates chronic overprovisioning; ~60s provisioning vs. 3–5 min CA |
| CastAI | SaaS FinOps platform for Kubernetes — right-sizing, Spot migration, multi-cluster visibility | Used in Project 1 alongside Karpenter | Provides visibility and recommendations that Karpenter alone doesn’t surface |
| War-room drill | Timed, squad-based live debugging of a simulated production outage on a real cluster | Every Saturday in the programme | Builds production confidence that cannot be gained from tutorials |
| RCA (Root Cause Analysis) | Formal document answering: what broke, why, what was the impact, how to prevent recurrence | Written after every war-room session | The primary deliverable from any production incident; required in all professional environments |
| Blast radius | The scope of what was impacted by an incident — what failed, what was safe | Documented for every production drill | Determines severity classification and escalation path |
| Self-healing infrastructure | Infrastructure that automatically detects and remediates its own failures | CleverOps Project 4 goal | Reduces MTTR to near-zero for known failure patterns |
| Savings Plans (AWS) | Committed-use discount on AWS compute — covers EC2, Lambda, Fargate | Project 1 — dedicated session | Up to 72% discount vs. On-Demand; must be sized correctly to avoid over-commitment |
| Three-tier observability | System monitoring + application traces + user behaviour, all in a single stack | Project 3 observability integration | Standard system monitoring misses user impact; three tiers are needed for complete picture |
| Production confidence | The ability to diagnose and act in real production incidents under pressure | The stated goal of the entire programme | Most DevOps engineers learn tools but not how to use them when things break in production |
13. Interview & Career Development Components
Included in the programme (weeks 7–8):
Mock Interviews:
- 1:1 with SRE Labs technical team members
- Scheduled by squad, across weeks 7 and 8
- Additional slots available by appointment
CV Optimisation Session:
- Live CV review on the call (participants bring their CV)
- Templates shared after the session
Profile Optimisation:
- LinkedIn profile review
- Naukri profile review (Indian job market focus)
- Public presence strategy
Referral Network:
- SRE Labs receives hiring requests from organisations looking for DevOps engineers
- Referrals for 6 countries: India, UK, US, Canada, Germany, Australia
- Open to programme alumni
What you can share publicly from this programme:
- Documentation (MD files, architecture descriptions, RCA documents) — shareable on personal GitHub
- Anonymised versions of workflows and manifests — shareable
- The actual client infrastructure code — not shareable outside the bootcamp (NDA)
- The learning and approach (for interview discussions) — fully shareable
14. Gaps & Assumptions
This session is an orientation, not a technical session. No new DevOps concepts were taught. The value of this package is as a programme index — a map of what was promised and what each project covers, so you can cross-reference against sessions that deliver on those promises.
Items mentioned but not covered in this session (covered in subsequent sessions):
- The actual EC2 Intel→AMD migration (Project 1, Session 1 & 2)
- Karpenter installation and demo (Karpenter/CastAI sessions)
- The security audit tools in depth (Project 2)
- The Titan Grid 500-microservice architecture (Project 3, Sessions 1 & 2)
- CleverOps architecture in depth (Project 4 — not yet delivered as of programme Week 4)
- Apna Cloud detail (bonus — not yet delivered)
Programme gap noted: The instructor mentioned 100 documented incident patterns (common + rare) across EKS, GKE, and other infrastructure components, but these were referenced rather than enumerated. This represents a significant unreleased resource.
Transcription artefacts:
- “grab it oning” = Graviton (AWS ARM instance family)
- “ease cluster / EK side” = EKS (Elastic Kubernetes Service)
- “genkins” = Jenkins
- ”carpenter” = Karpenter
- ”casti / splunker” = CastAI / Splunk (in FinOps context)
- “phops tools” = FinOps tools
- ”terapform” = Terraform
- ”cubecape” = Kubescape
- ”obsibility / obserability” = Observability
- ”AutoRemedy Engine / labor ops” = CleverOps (SRE Labs’s automation product)
- “upna cloud / APNA cloud” = Apna Cloud (SRE Labs’s private cloud platform)
- “QBI / QBR.AI” = QBR.AI (workflow automation platform)