Lesson 18 · Senior observability judgment
Senior observability interview questions
High-signal questions about metrics, alerting, SLOs, tracing, logs, and cross-pillar debugging — with answer structures that sound like real operational judgment.
Your win: answer senior observability questions with mechanism + trade-off + repo-grounded consequence, not just tool definitions or slogan-level best practices.
Why these questions are different from the base course
The base course teaches the stack clearly. This page asks whether you can defend the stack honestly under real operational pressure. That means your answer has to sound less like a glossary and more like engineering judgment.
The strongest answers here usually do three things: name the mechanism, name the important trade-off or weakness, and connect it to a concrete repo consequence. That structure is what makes the answer sound practiced and trustworthy.
How to get the most out of this page
Do not read this as a glossary. Read the left column as the prompt an interviewer could ask you with no warning, and read the right column as the shape your answer should roughly follow. Then close the page and try to answer out loud.
That last step matters. The strongest earlier lessons in this course always pull you back toward recall and explanation, not just recognition. Treat this page the same way and it becomes much more useful.
Question bank
| Question | Best answer shape |
|---|---|
| Why can “measure everything” be a bad observability strategy? | Because telemetry must stay queryable and affordable; high-cardinality or low-value signals can make the platform noisier and more expensive without improving diagnosis. |
| What makes an alert high-quality? | It is actionable, urgent enough for its channel, and routed to the right owner with labels and escalation that make human response clear. |
| How would you describe the repo’s SLO maturity honestly? | It has SLO-like p95/error-rate alert thresholds, but not full first-class SLO objects, explicit error budgets, or burn-rate operations yet. |
| Why is Thanos important if Prometheus already exists? | Prometheus gives local scraping and short retention; Thanos adds object-storage retention, global query, and cross-cluster fan-out. |
| What is the main operational cost of poor metric label design? | Cardinality growth that makes storage, queries, and dashboards harder and more expensive to operate. |
| Why is sampling not just a tracing implementation detail? | Because it changes what the trace view can and cannot prove during incident analysis. |
| What is the honest role of Grafana in this repo? | Visualization and dashboarding over datasources like Thanos and Jaeger, not the primary long-term store of observability data. |
| What should a senior review ask about an observability design? | What production question it answers, how reliably it answers it, and what cost or blind spot comes with the design. |
| Why are logs still necessary when metrics and traces exist? | Because metrics quantify and traces localize, but logs still explain the concrete failure context and message details. |
| What makes an observability answer sound mature? | Separating visibility, cost, ownership, and confidence instead of presenting the stack as perfect instrumentation. |
What stronger answers sound like
If you listen to the answers on this page, a pattern repeats. They are honest about trade-offs. They name where the platform is partial rather than pretending everything is ideal. And they use repo specifics to sound like someone who has operated a real system, not just memorized the vendor docs.
That is the tone you want when you practice these. Calm, specific, and honest. Strong senior observability answers rarely sound flashy. They sound believable.
Use the playbook and map together
The senior playbook compresses the judgment layer; the repo map gives you the ground truth that makes answers sound real.
Check yourself (from memory)
Q1. A strong senior observability answer usually includes…
Sources. Repo observability map; curated observability resources.