Card 1 of 20
Front. SLI Boundary. Why must a request-success SLI define which requests enter its denominator?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 20 cards in this deck
1.SLI Boundary
Why must a request-success SLI define which requests enter its denominator?
Health probes, malformed requests, retries, and internal traffic can change the ratio. Measure the intended user operation consistently so the SLI reflects its reliability contract.
2.Retry Accounting
A user action fails twice and succeeds on its third attempt. What can request-level success hide?
The user experienced delay and failures despite eventual completion. Track logical-operation outcomes and attempt-level load separately when retries materially affect the experience.
3.Missing Zero
Why should absent telemetry not automatically be converted to zero errors?
The collector, target, or query may have failed. Represent missing data explicitly and monitor telemetry freshness before interpreting an empty result as healthy.
4.Counter Reset
Why should a counter rate calculation account for process restarts?
Counters reset when processes restart. A raw difference can become negative or misrepresent traffic; use reset-aware rate functions and preserve the relevant series identity.
5.Rate Before Sum
Why generally calculate each counter's rate before summing across instances?
Individual resets must remain visible to the rate calculation. Aggregating raw counters first can hide one instance's reset behind another's growth.
6.Quantile Aggregate
Why is averaging instance p95 values invalid for computing fleet p95?
Each quantile summarizes a different distribution and traffic volume. Aggregate compatible histogram observations, then estimate the fleet quantile.
7.Bucket Boundary
How does histogram bucket placement affect a latency SLO check?
A boundary at the SLO threshold supports counting observations within it directly. Coarse buckets away from that threshold require approximation and can obscure regressions.
8.Cardinality Budget
Why use route templates rather than full URLs as metric labels?
IDs and query parameters create unbounded series and can expose sensitive data. Templates retain useful aggregation while controlling cardinality.
9.Trace Propagation
A request has separate traces in each service. What should be inspected?
Propagation of trace context through HTTP, queues, and asynchronous execution. Instrumentation in every service does not automatically preserve a connected causal chain.
10.Async Link
When can a span link better represent causality than forcing one parent span?
Batch processing may depend on many incoming messages or detached workflows. Links can represent multiple causal inputs without inventing a single request hierarchy.
11.Head Sampling
Why can head sampling miss a rare error that becomes visible only near request completion?
The decision occurs before that outcome is known. Retain population error metrics and choose a tracing policy appropriate to rare diagnostic cases.
12.Tail Sampling
What operational cost accompanies tail sampling that retains slow or failed traces?
The pipeline must collect and buffer enough spans to decide, route related spans together, and handle late arrivals. Sampling reduces retained data but does not eliminate collection cost.
13.Sampled Rates
Why should an error-enriched trace sample not be used directly to estimate the production error rate?
Its inclusion probabilities differ by outcome. Use population counters or a statistically valid weighting scheme; the sample is designed for diagnosis.
14.Clock Skew
Why can a distributed trace show a child apparently starting before its parent?
Host clocks may differ. Use causal relationships and local duration measurements, and inspect clock synchronization before concluding that the application violated ordering.
15.Log Correlation
What makes a log line useful for following one failed operation across retries?
Stable operation identity, attempt identity, service and release, timestamp, and structured error context. Avoid putting secrets or entire request bodies into diagnostic logs.
16.Alert Volume
Why does an error ratio of 100% over one request need different treatment from 100% over a million?
Impact and statistical evidence differ. Combine ratios with traffic context and synthetic coverage for low-volume critical paths.
17.Alert Window
Why combine a short and a longer burn-rate window for paging?
The longer window establishes sustained budget consumption while the short window confirms it is still happening. This can reduce pages for resolved spikes without ignoring fast outages.
18.Collector Pressure
What should a service do if its telemetry exporter cannot keep up?
Use a bounded policy with explicit drop or backpressure behavior and observable exporter failures. An unbounded queue can turn a telemetry outage into an application outage.
19.Monitor Monitor
How can a team detect that its primary alerting pipeline has stopped evaluating alerts?
Use an independent heartbeat or synthetic end-to-end alert check with separate failure dependencies. Monitoring only the alert manager from itself leaves a blind spot.
20.Instrumentation Test
What should a controlled failed request verify about observability?
That the intended SLI changes, trace context remains connected, useful diagnostics appear, and the expected alert can route. Existence of instrumentation code is not evidence that the operational path works.