SRE Fundamentals: SLOs, Error Budgets, and Reliability Practice

FAUN.dev() is where engineers from GitHub, Netflix, and Shopify go to stay ahead — fast.

An effortless, straightforward way to keep up with technologies...so you can keep your tabs closed and your mind open!

70,000+ developers already joined our ecosystem ⭐⭐⭐⭐⭐
Trusted by engineers at:

Google • Microsoft • AWS • Netflix

Take the quiz

Your score will show up right here.

SRE Fundamentals: SLOs, Error Budgets, and Reliability Practice

A 10-question quiz on core Site Reliability Engineering concepts, escalating from easy to hard. It covers the SLI/SLO/SLA distinction, error budgets, the four golden signals, toil, blameless postmortems, and availability math (the "nines").

What is a Service Level Indicator (SLI)?

A contract with users that specifies penalties if reliability targets are missed.
A quantitative measure of some aspect of the service, such as request latency or the fraction of successful requests.
The internal target value that the service aims to keep its reliability at or above.

How is a service's error budget calculated from its availability SLO?

1 minus the SLO, so a 99.9% SLO gives a 0.1% error budget.
The SLO multiplied by the currently measured SLI.
The SLA target minus the SLO target.

The four golden signals of monitoring, as defined in Google's SRE book, are:

CPU, memory, disk, and network.
Availability, durability, latency, and cost.
Latency, traffic, errors, and saturation.

What is the key difference between an SLA and an SLO?

An SLA is measured by live monitoring, while an SLO can only be estimated after the fact.
An SLA is a contract that carries explicit consequences, such as refunds or penalties, if the target is missed, whereas an SLO is an internal target with no contractual consequence.
An SLA is always stricter, meaning more nines, than the SLO it is based on.

Which task best matches Google's definition of toil?

Manually running the same recovery script every week to clear a full disk, work that is repetitive, automatable, and adds no lasting value.
Designing and writing an automation tool that permanently removes a recurring manual task.
Investigating a novel failure mode that the team has never seen before.

Google's SRE guidance recommends keeping toil below what share of an SRE's time?

What is the central principle of a blameless postmortem?

Identifying which engineer caused the incident so that accountability is clear.
Focusing on the systemic and contributing causes of the incident while assuming everyone acted in good faith with the information they had at the time.
Avoiding any written record so that no individual can be held responsible later.

Why do SRE teams deliberately set availability SLOs below 100%?

Because 100% is effectively unattainable and not worth its cost, and a sub-100% target creates an error budget that leaves room for change and feature velocity.
Because monitoring tools are physically unable to measure availability above 99.999%.
Because SLAs legally prohibit any provider from promising 100% availability.

Roughly how much downtime does a 99.9% ("three nines") availability target allow per 30-day month?

About 8.8 hours.
About 4.4 minutes.
About 43 minutes.

Under a typical error budget policy, what happens when a service exhausts its error budget?

The SLO is automatically lowered so that the budget is no longer reported as exceeded.
New feature launches are frozen and the team shifts focus to reliability work until the service is back within its SLO.
The on-call engineer responsible for the overspend is placed on a performance improvement plan.