Your interviewer says the p99 latency of photo uploads doubled 20 minutes ago and asks how you find the cause. Debugging production with telemetry means narrowing from that symptom on a dashboard to the component, request hop, and reason behind it. Metrics say how much is wrong and where, a trace shows which hop of one slow request took the time, and a log says why. You start with the cheap, broad signal and move to a richer one only as the search shrinks. Monitoring, Logs, and Alerts defines all three signals.

Reach for this when a page or customer report says latency or errors moved and nobody yet knows which component is responsible. Alerting That Pages for the Right Reasons covers the page that starts the work, so we begin with a symptom already on screen. Skip the investigation when a change just shipped and rolling back is cheap, because stopping the damage beats explaining it. Skip it too when one host is the whole problem, and take that host out of rotation instead.

This is a standard question in site reliability engineering (SRE) and production-engineering loops, and a common follow-up in senior backend rounds. Mid-level candidates show a sensible order of looking and say what each step rules out. Senior candidates also explain why percentiles do not aggregate and why per-user questions need traces. Every chapter returns to one incident on the upload service from SLIs, SLOs, and Error Budgets, now running in two regions, and the chapters follow the order a good answer takes.