Question 1

What are the three pillars of observability?

Accepted Answer

The three pillars of observability are metrics, logs, and traces. Metrics show quantitative trends, logs provide event-level detail, and traces show how a request flows across systems.

This framework is useful because no single signal is enough for every incident. Metrics tell you that something is wrong, logs help explain what happened, and traces help locate where latency or failure occurred in a distributed request path.

Question 2

What is the difference between monitoring and observability?

Accepted Answer

Monitoring is the practice of collecting and watching known signals with dashboards, thresholds, and alerts. Observability is the ability to understand internal system behavior from external telemetry, especially for unknown failure modes.

In simple terms, monitoring is about known questions, while observability helps answer new questions during debugging. Strong answers usually explain that observability is broader than just “having dashboards.”

Question 3

What makes a good alert?

Accepted Answer

A good alert is actionable, high-signal, and tied to meaningful impact. It should tell responders something important that requires attention and should not fire constantly for noise.

Great alerts are designed around user impact or service objectives rather than low-level metrics alone. For example, rising error rate or latency on a critical path is usually more valuable than a generic CPU alert with no context.

Question 4

What are SLI, SLO, and SLA?

Accepted Answer

An SLI is a Service Level Indicator, which is the metric used to measure service behavior. An SLO is a Service Level Objective, which is the target you want that metric to meet. An SLA is a Service Level Agreement, which is an external commitment often tied to business or contractual terms.

Interviewers often look for clarity here because these terms are related but not identical. SLOs are especially important operationally because they help teams decide how reliable a system should be and when action is needed.

Question 5

Why centralize logs?

Accepted Answer

Centralized logging makes it easier to search, correlate, retain, and analyze logs across many hosts, containers, and services.

This is especially important in distributed systems, where the relevant information for one incident may be scattered across multiple components. Good answers also mention structured logging and correlation identifiers.

Question 6

How do distributed traces help debugging?

Accepted Answer

Distributed traces show the path a request takes across services and how long each step takes.

This is valuable because latency or failure in one request may span APIs, message brokers, databases, and background services. Traces help pinpoint which dependency or code path is responsible for the user-visible problem.

Question 7

What are the golden signals?

Accepted Answer

The golden signals commonly refer to latency, traffic, errors, and saturation. They provide a concise set of indicators for understanding service health.

These are useful because they connect operational data to user experience and resource pressure. A good answer should explain that they are a practical starting point, not the only metrics worth tracking.

Question 8

What is alert fatigue, and how do you reduce it?

Accepted Answer

Alert fatigue happens when responders receive too many noisy or low-value alerts and become desensitized to them.

It can be reduced by tuning thresholds, removing duplicate pages, suppressing non-actionable alerts, routing lower-priority issues differently, and designing alerts around symptoms that matter. Strong teams treat alert quality as an engineering problem, not just an operations problem.

Question 9

What is a useful dashboard?

Accepted Answer

A useful dashboard highlights the health and behavior of a system in a way that supports fast understanding and decision-making. It should emphasize important service indicators, recent changes, dependencies, and trends rather than overwhelming people with every possible metric.

Good dashboards are audience-specific. A service owner may need saturation and error views, while leadership may care more about uptime trends and customer-facing impact.

Question 10

Why are correlation IDs useful?

Accepted Answer

Correlation IDs make it easier to follow a request or workflow across services and logs by attaching a shared identifier to related events.

This is especially helpful in microservices and asynchronous systems. Without correlation IDs, incident responders may have the data they need but struggle to connect the pieces quickly.

Question 11

How do you measure whether observability is actually helping?

Accepted Answer

I would look at whether teams detect incidents earlier, isolate causes faster, reduce mean time to recovery, and spend less time guessing during debugging.

Observability is successful when it improves decision-making and response, not just when more telemetry exists. More data is not automatically better if it is noisy, expensive, or hard to interpret.

Question 12

What is a mature observability practice?

Accepted Answer

A mature observability practice includes high-quality telemetry, meaningful dashboards, actionable alerts, strong service ownership, clear SLOs, and instrumentation that supports both routine operations and deep investigations.

The important idea is that observability is not only tooling. It is a combination of engineering habits, service design, and operational discipline.

Question 13

What is the difference between white-box and black-box monitoring?

Accepted Answer

White-box monitoring looks at internal system metrics and telemetry, while black-box monitoring tests the system from the outside as a user or client would.

Both are valuable. White-box signals help explain internal behavior, while black-box checks tell you whether the service is actually usable from a consumer perspective.

Question 14

Why are synthetic checks useful?

Accepted Answer

Synthetic checks simulate user actions or service requests on a schedule to verify behavior proactively.

They are useful because they can detect failures even when real user traffic is low. Good answers mention that they complement, not replace, real production telemetry.

Question 15

What is cardinality in metrics?

Accepted Answer

Cardinality refers to how many unique label combinations a metric produces.

High cardinality can create storage and performance problems in metrics systems. Strong answers show awareness that observability design has cost and scalability tradeoffs.

Question 16

Why is structured logging important?

Accepted Answer

Structured logging uses consistent machine-readable fields instead of only free-form text messages.

It makes logs much easier to search, filter, correlate, and analyze at scale. This becomes especially important in distributed systems and centralized logging platforms.

Question 17

What is sampling in tracing?

Accepted Answer

Sampling is the practice of recording only a subset of traces instead of every request.

It helps control cost and storage, especially in high-traffic systems. Good answers may mention head-based and tail-based sampling tradeoffs.

Question 18

Why are burn-rate alerts useful?

Accepted Answer

Burn-rate alerts indicate how quickly an error budget is being consumed relative to the SLO target.

They are useful because they connect alerting to actual reliability objectives, reducing noise from alerts that do not reflect meaningful service impact.

Question 19

What is dashboard sprawl?

Accepted Answer

Dashboard sprawl is the uncontrolled growth of too many dashboards with overlapping, outdated, or low-value information.

It makes observability harder rather than easier because responders waste time searching for the right view. Mature teams curate dashboards deliberately.

Question 20

What is log retention, and why does it matter?

Accepted Answer

Log retention is how long logs are stored before deletion or archival.

It matters for incident response, compliance, cost management, and troubleshooting. Too little retention limits investigations, while too much can become expensive or hard to manage.

Question 21

Why are service maps useful?

Accepted Answer

Service maps visualize how services depend on and communicate with one another.

They are especially useful in complex distributed systems where understanding dependency flow quickly can shorten incident response time.

Question 22

What is mean time to detect?

Accepted Answer

Mean Time To Detect, or MTTD, measures how quickly a team becomes aware of an incident after it starts.

It matters because even fast recovery is limited if detection is consistently slow. Good observability improves both detection speed and diagnosis quality.

Question 23

What is instrumentation?

Accepted Answer

Instrumentation is the act of adding metrics, logs, traces, and related telemetry to systems so their behavior can be observed.

It is a design choice, not just a tool setting. Good instrumentation makes debugging easier and produces signals tied to meaningful system behavior.

Question 24

Why should alerts have ownership?

Accepted Answer

Every alert should have a clear team or service owner responsible for responding and improving it over time.

Without ownership, alerts become noise and no one feels accountable for fixing weak signal quality. Ownership is a key part of observability maturity.

Question 25

How do you tell whether a metric is actionable?

Accepted Answer

A metric is actionable when changes in it help a team decide what to do next or whether users are being impacted.

Not every measurable thing is useful. Strong answers show awareness that observability should drive decisions, not just collect numbers.

Question 26

What are common observability anti-patterns?

Accepted Answer

Common anti-patterns include alerting on everything, collecting telemetry without purpose, using inconsistent labels, relying only on logs, and ignoring cost or signal quality.

Mature teams treat observability design as engineering work. Poorly designed observability can create confusion instead of clarity.

Question 27

How do you improve observability in an existing weak system?

Accepted Answer

I would start by identifying critical user journeys and service objectives, then improve instrumentation, dashboards, alert quality, and correlation across the most important paths first.

Trying to instrument everything at once is usually less effective than starting with the most business-critical services and the most common failure modes.

Question 28

Why is context important in alerts?

Accepted Answer

Alerts are more useful when they include relevant context such as service name, environment, recent change information, runbook links, and key metrics.

This reduces responder guesswork and speeds up triage. Alert quality is about clarity as much as detection.

Question 29

What is an error budget dashboard useful for?

Accepted Answer

An error budget dashboard helps teams see how much reliability margin remains relative to the SLO target.

This makes it easier to connect operations and product decisions, especially when balancing release velocity against stability.

Question 30

Why should observability data be tied to business-critical flows?

Accepted Answer

Telemetry is most valuable when it reflects the user journeys and system paths that matter most to the business.

That focus helps teams prioritize instrumentation and alerting where failure would hurt the most instead of spreading effort too thinly.

Monitoring, Logging & Observability

1. What are the three pillars of observability?

2. What is the difference between monitoring and observability?

3. What makes a good alert?

4. What are SLI, SLO, and SLA?

5. Why centralize logs?

6. How do distributed traces help debugging?

7. What are the golden signals?

8. What is alert fatigue, and how do you reduce it?

9. What is a useful dashboard?

10. Why are correlation IDs useful?

11. How do you measure whether observability is actually helping?

12. What is a mature observability practice?

13. What is the difference between white-box and black-box monitoring?

14. Why are synthetic checks useful?

15. What is cardinality in metrics?

16. Why is structured logging important?

17. What is sampling in tracing?

18. Why are burn-rate alerts useful?

19. What is dashboard sprawl?

20. What is log retention, and why does it matter?

21. Why are service maps useful?

22. What is mean time to detect?

23. What is instrumentation?

24. Why should alerts have ownership?

25. How do you tell whether a metric is actionable?

26. What are common observability anti-patterns?

27. How do you improve observability in an existing weak system?

28. Why is context important in alerts?

29. What is an error budget dashboard useful for?

30. Why should observability data be tied to business-critical flows?