Observability Fundamentals
What the exam tests
Observability Fundamentals checks whether you can separate monitoring from observability and apply SLIs, SLOs, error budgets, and telemetry economics. Monitoring answers known questions; observability lets you ask new questions from high-dimensional telemetry. The exam expects you to choose the right signal and control cost.
Core rules
- An SLI is a measured ratio, such as successful requests / valid requests. An SLO is a target for that SLI over a window, e.g. 99.9% over 28 days. The error budget is 1 - SLO.
- Prefer user-facing SLIs: availability, latency, correctness, freshness. Golden signals are latency, traffic, errors, saturation; USE covers utilization, saturation, errors for resources.
- Metrics aggregate cheaply but lose detail; logs preserve events but scale with volume; traces show causal paths but are sampled.
- Cardinality is the main cost driver. Avoid unbounded labels such as user_id, request_id, or raw URL in metrics.
- Instrument at boundaries and propagate context, but sample only when the sampled data still answers the question.
- Observability is socio-technical: ownership, runbooks, and retention matter as much as dashboards.
Worked example
A checkout API has an SLO of 99.9% successful requests over 28 days. The error budget is 0.1% of 40,320 minutes, or 40.32 minutes of full failure. If a bad deploy causes a 2% error rate, the burn rate is 2% / 0.1% = 20x. At that rate the 28-day budget is consumed in 28 / 20 = 1.4 days. A fast-burn alert should fire long before 1.4 days, using a short window to catch the deploy and a longer window to confirm.
Traps
Averaging per-instance p99 values is mathematically wrong; aggregate distributions or use histogram_quantile. Confusing an SLI with an SLO loses marks. Adding request_id to a metric label creates cardinality explosion. Collecting every log and trace without retention or sampling is not observability; it is cost.