SRE Labs (Advanced Track) — Kickoff Call (Session 0): Program Onboarding Reference

Structured educational resource covering sre labs (advanced track) — kickoff call (session 0): program onboarding reference.

mid 20 min read 14 sections

#kubernetes#aws#gcp#dns

Notes & Logistics Guide

2. Table of Contents

Executive Summary
Table of Contents
Program Philosophy & Positioning
Curriculum Structure (6-Week Breakdown)
Expected Outcomes
Rules of Engagement & Expectations
Weekly Cadence & Call Schedule
Squads, Cloud Tracks & the Cloud Manager Role
Communication Channels & Tools
Onboarding Process (Forms, Sequence, Deadlines)
Career Support: Referrals, Interviews, RCA League
Full Q&A Digest (organized by theme)
Key Concepts Table
Gaps, Assumptions & Open Action Items
Cheat Sheet — What To Do Before Monday

3. Program Philosophy & Positioning

The program’s core thesis, stated early and repeated throughout the call:

Technology changes; failure patterns don’t. The tool stack shifts every 3–5 years, but the underlying failure modes — misconfiguration, cascading failures, human panic under pressure — have stayed consistent for decades. The program optimizes for recognizing and handling patterns, not memorizing today’s tools.
The gap isn’t tool knowledge — it’s war-room judgment. Most participants already know Kubernetes, cloud, and CI/CD. What’s missing is the ability to make the right call, at the right moment, under pressure, as a team.
Learning is destructive by design. The stated pedagogy is: implement something, break the infrastructure, ask why it broke, and fix it. Failure itself isn’t treated as embarrassing — skipping the reflection afterward is the actual failure mode the program is trying to eliminate.
Frameworks over tools. Tools (Jenkins, Terraform, Ansible, specific AWS service names) are explicitly deprioritized as the thing worth memorizing — the argument being that vendor tools get renamed or replaced, but a troubleshooting framework survives. The program teaches named frameworks (see Section 12) rather than “collect tools for your résumé.”
RCA (Root Cause Analysis) is treated as the central artifact and skill. Every significant incident solved during the program requires a written RCA, framed as “the language of every senior DevOps engineer” — the ability to explain a technical failure to a non-technical audience is treated as a distinct, trainable skill, separate from actually fixing the issue.
Shared-scar learning. Because the cohort collectively carries 8+ years of experience per person, participants are explicitly encouraged to share their own past outage stories with the group rather than treating the sessions as one-way lectures.
Cloud-agnostic, not cloud-blind. The program is explicitly not built around teaching a specific cloud’s managed services (e.g., SQS specifics). It focuses on core DevOps/SRE disciplines — Kubernetes, observability, security — and lets participants apply them on whichever cloud they select. Production outages are described as “cloud independent”: the same outage scenario gets replicated across whichever cloud track a squad is on.

4. Curriculum Structure (6-Week Breakdown)

Week	Theme	Focus
Week 1	Core Infra Fundamentals	Linux, networking, how data flows through a system. Explicit framing: “if the OS is sick, Kubernetes isn’t going to save you.” This is the foundation layer everything else depends on.
Week 2	Modern Systems	Kubernetes internals, service mesh, Infrastructure as Code. Framed as “not just how to deploy, but how to design a system that ages well.”
Week 3	High Availability, Security & Platform Hardening	Moving systems from “demo-grade” to “production-grade.” Framed around blast radius: does an incident become a headline, or just a fix?
Week 4	Observability, Auto-Healing & Performance Engineering	”You can’t save what you can’t see.” Focus on signal-over-noise, system + user-behavior monitoring, early failure detection, and fast recovery. Mock interview access opens at the end of this week.
Week 5	Resilience & Chaos Engineering	Deliberately introducing failure to eliminate future problems proactively.
Week 6	Platform Engineering / DevOps-as-a-Product	The shift from “engineer who solves tickets” to “platform thinker who builds infrastructure self-service tooling” for other teams.

Two learning tracks within the cohort: Participants are split into Foundations Track and Advanced Track based on an initial assessment (see Section 10) — this determines which level of material and pacing a squad receives, and participants can move between the two categories week-to-week based on ongoing assessment results.

Weekday structure: Assignments and pre-reads are self-paced (explicitly stated — pacing depends on individual skill level and available time, with the instructors giving a rough estimate of 1–2 hours/week for someone with 5+ years of relevant experience, though this varies widely by person and gap areas).

Weekend structure: Live sessions —

Saturday — production outage / war-room call (~1 hour, timeboxed)
Sunday — project walkthrough call

Doubt-clarification calls — Tuesday and Thursday, offered in both a morning and evening slot (India time) to cover different participant time zones. Combined with a Wednesday morning slot, this gives four doubt-call touchpoints per week across the cohort’s time zones.

Shadowing sessions — separate from the structured curriculum. The lead instructor runs live client implementation sessions on weekdays (India time, roughly 11:00 a.m.–5:00 p.m.), open to anyone who wants exposure to how things are actually implemented for a real client. These sessions are not recorded, because they involve real client details being shared on screen.

5. Expected Outcomes

By the end of the program, stated outcomes are:

Comfort/confidence during a live war room or production incident — the goal is that “a chaos or any kind of war room will not spike” a participant’s stress response.
Ability to explain incident impact, trade-offs, and decisions made — framed as the skill that most engineers actually lack (technical competence without the ability to narrate it clearly under scrutiny).
A personal library of RCAs, runbooks, and documentation built from real (simulated) incidents, usable as future reference material.
”Production confidence” — explicitly distinguished from what a cloud certification provides. The claim is that this confidence comes only from breaking and fixing real infrastructure, not from passing an exam.
Interview-ready stories: the stated ROI of the program isn’t the tools learned, but the incident narratives a graduate can bring into interviews, leadership conversations, and promotion cases.

6. Rules of Engagement & Expectations

Stated as non-negotiable participation norms:

Show up to doubt calls, war rooms, and project calls.
Prepare in advance — go through assignments and pre-reads before each call; arrive at war rooms and project calls with the pre-read already done.
Implement on cloud infrastructure, never on a local machine. This is called out explicitly as a “must.”
Write and collect RCAs in your own drive or in SRE Labs’s shared space — also called a “must.”
Respect the clock during outage simulations — each Saturday war room has a fixed time budget (~1 hour) to diagnose the issue, and participants are expected to use that time deliberately rather than let it drift.
Break things deliberately, then ask questions — in the group and in Discord — rather than silently struggling or silently succeeding without documenting the “why.”
Share your own outage experience with the cohort if you have one, to contribute to the shared-learning model.

Four expectation categories were named explicitly on-slide:

On time — assignments, pre-reads, and labs done on schedule.
Engagement — asking questions, joining team calls, helping teammates.
Documentation — every experience captured as an RCA/playbook (called the “most crucial part” of the program).
Collaboration & accountability — supporting squad-mates, and owning the consequences (and fixes) of anything you break on shared cloud infrastructure.

7. Weekly Cadence & Call Schedule

Day	Session Type	Time Notes
Monday	Modules/assignments drop in Drive; self-paced start	Materials expected visible by Monday morning
Tue / Wed / Thu	Doubt-clarification calls (4 total across the week)	Tue & Thu evening (India) + Wed & Thu morning (India), to cover both hemispheres
Weekdays (any)	Optional shadowing session with lead instructor (live client work)	~11:00 a.m.–5:00 p.m. IST, not recorded
Thursday	Pre-read for the weekend war room + project call published	Ahead of Saturday/Sunday
Saturday	Live production war room / outage simulation	~7:00 p.m. IST, ~1 hour timeboxed
Sunday	Project walkthrough call	~7:00 p.m. IST
Day after kickoff (no live class)	Assessment day — MCQ-based skill assessment, used to sort participants into Foundations Track / Advanced Track and squads	Explicitly: do not use AI tools on this assessment — answer from current understanding, since the results are used to place you correctly

Clarification worth preserving: A participant (Ashwini) raised a strong process concern — that the project walkthrough is scheduled for the same day as the war room, meaning participants get no advance exposure to the project’s architecture before being expected to perform under pressure. The instructors’ response: the war room is a simulation, not literally the same project as the walkthrough, but they agreed to add short pre-context (a “quick contact” call) earlier in the week to reduce this disconnect. Treat the pre-read + Thursday project-call combination as the mitigation for this gap.

8. Squads, Cloud Tracks & the Cloud Manager Role

Squad size: ~6–7 people per squad.
Squad composition philosophy: Deliberately balanced — not grouped by similar experience level. The stated intent is that a squad mixes strong and weaker members per topic so people alternate between teaching and learning depending on the subject (e.g., someone strong in Kubernetes but weak in Docker learns from a squad-mate who’s the reverse).
Squad assignment inputs: Assessment score + self-reported location/time zone + experience. A participant suggested squads be time-zone-aligned for easier coordination — the instructors agreed this is already partially handled via the location field on the onboarding form.
Re-shuffling: Squads and the Foundations Track/Advanced Track split are not static — participants can be moved between categories week to week based on ongoing assessment results.
Cloud tracks: AWS, GCP, and Azure are all supported; OCI can be added if enough participants request it. A participant can select two cloud platforms on the onboarding form (write it in the remarks/notes section) — this grants full/write access on the primary cloud and read-only access on the secondary.
Cloud Manager role: For each cloud platform (AWS/GCP/Azure), one participant is elected as “Cloud Manager” based on stated experience/exposure on the onboarding form. This person gets admin access to that cloud environment and takes ownership of cost, security, and operational governance for the squad’s use of that cloud — approving changes, answering cloud-specific questions, and leading during cloud-specific incidents. This is described as replicating how cloud ownership actually works inside a real organization (cloud infrastructure “doesn’t run itself”).
Control-plane-level outages are included, not just workload-level issues — the program explicitly builds out self-managed control-plane components (etcd, API server, etc.) on cloud compute so that control-plane failure scenarios (not just managed-K8s abstractions) are part of the war-room repertoire.

9. Communication Channels & Tools

Channel	Purpose
WhatsApp	Direct/urgent communication with instructors
Email	Formal notices, access grants (auto-generated emails when Drive/GitHub/cloud access is provisioned)
Discord	Primary hub — role-gated; specific channels become visible only after completing the Discord onboarding form and being assigned a role (Foundations Track / Advanced Track / squad-specific)
Google Workspace (Drive, Meet)	Curriculum materials, modules, recordings, RCA storage
GitHub	Code/playbooks; also used informally as a signal of experience — a participant requested guidance on optimizing GitHub/LinkedIn/resume presence, and the instructors agreed to consider adding that as a supported topic

Open question flagged live but not fully resolved: A participant (Raj) asked which single channel is the canonical source of truth for deadlines/materials, given the number of channels in play. No single “source of truth” channel was explicitly named in the call — Drive appears to be the closest candidate for materials, with Discord for role-gated discussion. Worth confirming explicitly once module access opens.

10. Onboarding Process (Forms, Sequence, Deadlines)

The onboarding “guide” is a bundle of ~4–5 separate Google Forms, shared after the kickoff call ends, to be dropped in the group. Multiple participants reported being asked to re-enter the same information across forms — the instructors acknowledged this as a possible backend issue and said they’d investigate, but did not confirm a fix during the call.

Forms, in stated order:

Basic details form — name, active email, current organization, total years of experience, location, primary goal for taking the program, prior RCA/troubleshooting experience, and CV. Includes an acknowledgment that SRE Labs may share your CV with client organizations for relevant roles.
Cloud manager & access form — select your primary cloud platform; opt in (with justification) if nominating yourself as Cloud Manager for that cloud; include GitHub username. This is the form where you note if you want both a primary and secondary (read-only) cloud track — add it in the remarks field.
Discord & GitHub access form — supplies the info needed to grant role-based Discord access and repo access.
Week 1 assignment — released the day after the kickoff call; stated to take ~15–30 minutes; used (along with the assessment) to place participants into Foundations Track vs. Advanced Track and assign scores.
Drive access confirmation (email) — must use your correct/original email address here, since this is what receives the actual Drive access grant containing all modules, documentation, and code.

Deadlines stated on the call:

All forms: complete by the next day, IST afternoon.
Week 1 assignment: complete by the next day, evening.
Assessment: no live class the day after kickoff — that day is reserved entirely for the assessment, so instructors can score and categorize the full cohort before Monday.
Live classes and module drops begin Monday morning.

Assessment specifics: Multiple-choice, used purely to gauge current skill level (not a pass/fail gate). Participants were explicitly told not to use AI tools while taking it — the instructions were to answer honestly from current understanding, since the result determines squad placement and gap identification.

11. Career Support: Referrals, Interviews, RCA League

Referral network: SRE Labs maintains a referral system across the countries listed as part of their “global reach,” with a dashboard of open roles. Participants are expected to keep an updated CV in the system. A cautionary anecdote was shared: two past participants (referred and offered roles in Australia) did not end up joining, and this caused reputational friction for SRE Labs with the client — framed as a reason to only request a referral if you intend to follow through.
Mock interviews: Opens at the end of Week 4. A Calendly link will be shared to book sessions with the instructor team (multiple instructors covering different target roles — solution architect, DevOps engineer, platform engineer, engineering lead).
Resume / LinkedIn / online-profile optimization: Also begins after Week 4, bundled with interview prep.
RCA League (gamification): Each week’s toughest production outage becomes the basis for a competitive RCA-writing exercise. The best RCA each week gets featured in SRE Labs’s newsletter/channels — explicitly visible to engineering leaders, hiring managers, and founders in SRE Labs’s network. Framed as a resume/visibility mechanism, not just a learning exercise.
Public sharing of learnings: When asked whether writing public blog posts about troubleshooting work (e.g., a DNS failure solved during a war room) is encouraged, the instructors confirmed yes — citing past-batch participants who wrote Medium posts or personal newsletters about their SRE Labs experiences as a positive precedent.

12. Full Q&A Digest (organized by theme)

On tool coverage & scope

The program does not teach cloud-specific managed services (e.g., SQS specifics) — it focuses on cloud-agnostic core DevOps disciplines (Kubernetes, observability, security).
A dedicated system/architecture design session is planned, covering how to design cost-optimized, secure, highly available systems from a DevOps lens — including a guest lecture from an outside solution architect (15+ years experience).
Named troubleshooting frameworks: a Kubernetes-specific framework referred to as “the VERDICT-7” (transcription uncertain — worth confirming spelling/acronym expansion directly with instructors) and a general-system framework based on the OSI model.
Outages simulated are explicitly infrastructure-level, not application-level — though the scenario will present as an application symptom, and part of the exercise is learning to correctly localize the root cause (infra vs. OS vs. middleware vs. DB vs. application).
Kubernetes coverage goes beyond basic pod/deployment/replica mechanics — includes control-plane failure scenarios (etcd, API server) because the cloud control plane is deliberately self-hosted on compute for the program rather than relying on a fully managed abstraction.

On pacing & prior experience

No fixed weekly hour commitment — instructors gave a rough anchor of 1–2 hours/week for someone with 5+ years of relevant experience, but stressed this varies significantly by individual gap areas.
The assessment is explicitly designed to route people into either Foundations Track or Advanced Track rather than assuming a uniform starting point — participants coming in as complete Docker/Kubernetes beginners were told to expect extra self-study effort, supported by supplied videos/assignments.

On the “SRE Labs AutoRemedy Engine” internal tool

A fourth project in the curriculum centers on an internal SRE Labs product called “AutoRemedy Engine”, described as doing the job of a 2–3-years-experience DevOps engineer: building pipelines, integrating observability, and connecting RCA generation with automated triage/AI-assisted root-causing. Integrates third-party tools referenced in the call as “flight control” and “QBR.AI” (an agentic AI workflow) — instructor said they’d share the specific link in chat; not captured in this transcript, worth confirming directly. This is covered in the Week 4 Sunday project call.

On withdrawal

A participant asked to withdraw from the program mid-call, citing misaligned expectations. Instructors confirmed withdrawal is possible and directed them to contact Naven and Shakam (spelling uncertain from transcript) on the team to process it.

13. Key Concepts Table

Concept	What It Means Here
Foundations Track vs. Advanced Track	The two participant tracks the cohort is split into post-assessment, re-evaluated weekly; determines material depth and pacing.
RCA (Root Cause Analysis)	The program’s central deliverable — treated as a communication skill, not just a technical write-up; produced after every significant simulated incident.
Squad	A ~6–7 person balanced team (mixed experience levels) that works through weekday assignments and weekend war rooms together.
Cloud Manager	An elected participant per cloud platform who gets admin access and governance responsibility for that cloud’s cost/security/operations within the cohort.
War Room	The Saturday live, timeboxed (~1 hour) simulated production outage.
Shadowing session	Optional, unrecorded weekday sessions where the lead instructor implements real client work live and takes questions.
RCA League	Weekly gamified competition where the best incident write-up is published to SRE Labs’s external-facing channels.
AutoRemedy Engine	SRE Labs’s internal automation/observability/AI product, used as the basis for the program’s fourth project (Week 4).
VERDICT-7 (name as heard; unconfirmed spelling)	Named Kubernetes-specific troubleshooting framework referenced by instructors.

14. Gaps, Assumptions & Open Action Items

Transcription uncertainties to verify directly with the program (not resolved in this call):

Exact name/spelling of the Kubernetes troubleshooting framework (heard as “VERDICT-7”).
Exact name of the second tool integrated into AutoRemedy Engine (heard as “QBR.AI”).
Names of the team members to contact for program withdrawal (heard as “Naven and Shakam”).
Confirmation of instructor names/spelling: “Rahu Andar” for Ravi is likely a mis-transcription of a fuller name — worth confirming the correct spelling for your own notes.

Process items the instructors acknowledged but did not resolve live:

Multiple participants reported having to re-enter identical information across separate onboarding forms — flagged as a possible backend bug, investigation promised but not confirmed fixed.
No single channel was explicitly designated as the canonical source of truth for deadlines/announcements — worth clarifying once Discord roles are assigned.
The project-walkthrough-vs-war-room sequencing concern (Section 7) was acknowledged with a partial fix (added pre-context earlier in the week) rather than a full schedule change.

Assumptions made in structuring this document:

This transcript represents Session 0 (kickoff), prior to any technical module content — there are no commands, configs, or architecture diagrams to extract, which is why this package departs from the standard 12-section technical war-room format used elsewhere in your materials.
Speaker names are approximate where the auto-transcription was ambiguous (e.g., “Sor,” “Sur,” “Sep” appear to be the same recurring participant, possibly “Saurabh” or similar — not resolved with confidence).