SRE Practitioner study materials
SRE Practitioner study resources

SRE Practitioner study plan

SRE Practitioner · Give each week a clear focus.

8 weeks · About 7 hours per week

Week 1

SRE culture, principles and antipatterns & SLIs, SLOs and error budgets in a distributed ecosystem

  • Write out each core SRE principle (embracing risk, SLOs as the reliability contract, toil elimination, monitoring distributed systems, automation over heroics) with one concrete example from your own organisation per principle

  • Classify eight real behaviours or past incidents from your experience into SRE anti-patterns such as alert-driven heroics, change avoidance, and toil-as-a-service

  • Author two SLI specifications (one availability, one latency) for a single user journey, justifying the measurement point, aggregation, and window

  • Compute a 28-day error budget from a proposed SLO and state what fraction of the budget a weekly release cadence would consume

Your checkpoint

A two-page SLI/SLO specification sheet for one user journey: two SLIs with defined measurement points, one SLO with a window, and a fully worked 28-day error-budget calculation with arithmetic shown.

Week 2

SLIs, SLOs and error budgets in a distributed ecosystem & Full-stack observability, distributed tracing and observability-driven development

  • Define SLIs for a multi-service request path and justify where to instrument (client, load balancer, service, dependency) at each hop

  • Derive multi-window multi-burn-rate alerting rules from an SLO and state the false-positive/false-negative trade-off of each window pair

  • Instrument a single service across metrics, logs, and traces, then demonstrate correlation of one metric spike to a specific trace

  • Select among request-based, windowed, and resource-based SLI shapes for three distinct workload profiles and defend each choice

Your checkpoint

An error-budget policy plus a burn-rate alert set: three burn-rate thresholds expressed as concrete alerting expressions, each with a named owner and a pre-agreed action (freeze releases, escalate, page).

Week 3

Full-stack observability, distributed tracing and observability-driven development & Security and resilience by design in a zero-trust environment

  • Trace one request end-to-end and annotate the waterfall with the span attributes required to answer 'which dependency caused this latency'

  • Specify a sampling strategy and span-attribute naming convention for one service, and state what observability data is deliberately excluded and why

  • Enumerate the trust boundaries in one request path and state the authentication and authorisation decision made at each boundary

  • Write a blast-radius analysis for one compromised component under a zero-trust assumption, listing what the attacker can and cannot reach

Your checkpoint

An observability-plus-trust-boundary diagram of one request path with at least eight annotated spans and trust boundaries, each paired with the exact signal or control that proves correct behaviour.

Week 4

Security and resilience by design in a zero-trust environment & Organizational impact of adopting SRE

  • Specify a resilience pattern set (timeouts, retries with jitter, circuit breaking, load shedding, bulkheads) and name the failure mode each pattern addresses and each pattern's failure mode

  • Build a threat model for one service with at least six threats and a matching mitigation, detection signal, and residual risk for each

  • Estimate the cost of toil for one team in hours per week and propose a concrete toil budget with a target reduction percentage

  • Draft an SRE adoption model (consulting, embedded, ownership) with entry and exit criteria for each stage and the organisational incentives that make it stick

Your checkpoint

A two-page SRE adoption proposal: current-state toil estimate, chosen operating model with stage gates, three measurable 90-day outcomes, and the SLO/error-budget guardrails that govern release pace.

Week 5

AI-curated data, AIOps and DataOps for proactive and predictive incident management & Major incident response responsibilities

  • Define the schema and join keys for an incident telemetry pipeline that unifies alerts, deploy events, traces, and on-call actions into one queryable record

  • Write four anomaly-detection or predictive-alerting hypotheses and state the ground-truth labels and evaluation metric needed to validate each before shipping it

  • Assign incident roles (incident commander, communications lead, operations lead, scribe) and write a responsibility matrix showing who decides what

  • Draft a four-level severity matrix with an explicit escalation trigger and notification scope for each level

Your checkpoint

An incident-response package: severity matrix, role responsibility matrix, three escalation triggers with thresholds, and a blameless post-incident review template that includes an AI-assisted timeline reconstruction section.

Week 6

Major incident response responsibilities & Platform engineering for consistency and predictability

  • Run a tabletop exercise for a Sev-1 affecting a shared distributed dependency and record time-to-detect, time-to-decide, and time-to-mitigate

  • Write customer-facing communication templates (initial, update cadence, resolution) for three severity levels with a stated cadence rule

  • Define a platform golden path for one service type, naming each paved-road component and its self-service interface and owner

  • Select four platform adoption metrics (time to first deploy, percentage of services on the golden path, change failure rate, lead time) and capture their current baseline values

Your checkpoint

A golden-path specification for one service type covering at least six paved-road components, each with owner, interface, and SLO, plus a table of four adoption metrics with today's measured baselines and 90-day targets.

Week 7

Platform engineering for consistency and predictability & Practical chaos engineering

  • Write five falsifiable steady-state hypotheses for one system, each with a measurable indicator and a threshold that defines normal

  • Design three chaos experiments mapped to specific failure modes, each with scope, injected fault, blast radius, and abort condition

  • Define a stop/abort procedure with explicit numeric thresholds and a named decision owner for unattended experiment runs

  • Plan a game-day agenda with roles, timeboxes, safety controls, and a rollback path for every experiment

Your checkpoint

An experiment design document: three experiments each with steady-state hypothesis, blast radius, abort conditions, and rollback steps, plus a timeboxed game-day agenda with named roles.

Week 8

Practical chaos engineering & Full-stack observability, distributed tracing and observability-driven development & SLIs, SLOs and error budgets in a distributed ecosystem

  • Execute or dry-run one chaos experiment end to end and record whether the steady-state hypothesis held, with the evidence that proves it

  • Rank all nine domains by mock-exam accuracy and close the five largest gaps with targeted review notes

  • Re-derive error-budget arithmetic and burn-rate alert thresholds from memory on a blank page without reference material

  • Complete a timed 60-question mock exam and itemise every miss by domain and root cause (knowledge gap, misread, or unknown term)

Your checkpoint

A scored mock-exam report with target of at least 80 percent overall and no domain below 60 percent, every missed item mapped to its domain with a one-line remediation note, plus a 30-day post-exam maintenance plan.

Milestones

Week 2: Without notes, explain why a 100 percent SLO target is wrong, how an error budget governs release pace, and where the SLI measurement point belongs on a multi-hop request path - recorded as a five-minute self-explanation you can replay.

Week 4: A peer can review and critique your error-budget policy and threat model using only your written artifacts, with no verbal explanation from you; both documents pass review with fewer than three open questions.

Week 6: Lead a tabletop Sev-1 to resolution in 45 minutes or less with all four incident roles filled, a decision log kept, and a timeline reconstructed to within five minutes of actual event order.

Week 8: Score at least 80 percent on a timed 60-question mock exam with no single domain below 60 percent, and demonstrate reproduction of the error-budget and burn-rate math from a blank page.