Monitoring interview questions
5 questions interviewers actually ask, each with a model answer you can study and an AI drill that grades how you would say it out loud.
0/5
Mastered
Questions and answers
Model answer
Metrics are numeric time-series that are cheap to store and great for dashboards and alerting. Logs are detailed, timestamped events useful for understanding what happened. Traces follow a single request across services to find where latency or errors occur. Used together they let you ask and answer arbitrary questions about a system.
Model answer
Monitoring watches known signals and alerts on predefined conditions, answering questions you anticipated. Observability is the property of being able to understand a system's internal state from its outputs, including questions you did not anticipate. Rich, high-cardinality telemetry is what makes a system observable rather than just monitored.
Model answer
A good alert is actionable, urgent, and tied to user-facing symptoms rather than internal causes. It should fire when a human needs to do something now, link to a runbook, and rarely be a false positive. Alerting on symptoms like elevated error rate or latency, not every resource metric, prevents fatigue.
Model answer
An SLI is a measured indicator of service health, such as the fraction of successful requests. An SLO is the target for that SLI, for example 99.9% over 30 days. The error budget is the allowed shortfall, here 0.1%, which the team can spend on releases and risk. When the budget is exhausted, slow down and focus on reliability.
Model answer
Expose a metrics endpoint using a client library, emitting counters for events, gauges for current values, and histograms for distributions like latency. Use consistent labels but keep cardinality under control. A scraper like Prometheus pulls the endpoint, and you query with PromQL for dashboards and alerts.