Top 30 Observability Interview Questions and Answers
30 multiple-choice questions on Observability, drawn from 30 bites out of the 124 tagged Observability on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
When migrating to Koog 1.0, how should teams handle the stable and beta module split to align with JetBrains' support guarantees?
Show the answer
Answer: c · Move core dependencies to stable modules while isolating beta features to specific use cases
Koog 1.0 guarantees one year of API stability only for stable core modules, so teams should migrate core dependencies there while isolating beta features to specific use cases. Option B is tempting but wrong because the framework explicitly supports adding beta features as needed rather than avoiding them entirely.
Read the full bite: Koog 1.0 Stabilizes Kotlin AI Agent Framework
Question 2 of 30
Which characteristic is most crucial for an effective Service Level Indicator (SLI)?
Show the answer
Answer: c · It directly reflects the user's experience or perception of service performance.
The card explicitly states that an effective SLI measures what matters to the user, focusing on their experience rather than internal system metrics. Option D describes a common pitfall, as system metrics are causes, not symptoms felt by users, and should not be primary SLIs.
Read the full bite: Service Level Indicators: Measuring What Matters
Question 3 of 30
A VP questions the value of the data platform because cloud spend increased 40% after onboarding three new product teams. Which response best reframes the conversation around ROI?
Show the answer
Answer: d · Highlight metrics such as cost per workload, new team adoption rates, and time-to-insight compared to before onboarding
The correct answer reframes ROI by connecting spend to unit economics, adoption, and time-to-insight. Total data volume stored is a vanity metric that rises without indicating business value, and attributing spend solely to new teams confuses platform ROI with individual project ROI.
Read the full bite: How do you measure data platform ROI and track it?
Question 4 of 30
What is the main drawback of over-instrumenting an application with telemetry?
Show the answer
Answer: a · It creates excessive data, increasing storage costs and performance overhead.
The card explicitly states that over-instrumentation generates a 'massive volume of data that is expensive to store and process, and can even add performance overhead.' While too much data can make identification harder, the primary risk highlighted is the cost and performance impact.
Read the full bite: Code Instrumentation: Making Your App Observable
Question 5 of 30
In a distributed web service, which telemetry type is best for pinpointing which downstream service is adding latency to a single slow request?
Show the answer
Answer: d · Distributed traces, because they follow one request's spans across services
Traces follow a single request across services and attribute time to each span, localizing the slow hop. Metrics show aggregate trends and logs give per-event detail, but neither maps one request's cross-service path like a trace.
Read the full bite: Explain the three pillars of observability
Question 6 of 30
Which statement accurately describes a limitation of the Four Golden Signals?
Show the answer
Answer: c · They do not provide sufficient detail for identifying the root cause of an issue.
The card explicitly states that the Golden Signals 'tell you that a problem exists... but not necessarily why,' requiring deeper metrics for root cause analysis. Option B is incorrect because they focus on user experience, and options B and C misrepresent their purpose and applicability.
Read the full bite: The Four Golden Signals of Service Monitoring
Question 7 of 30
Why is structured logging considered foundational for observability at large scale?
Show the answer
Answer: a · Its consistent named fields enable reliable querying, aggregation, and correlation across services
Structured logs put data in named fields, so you can query, aggregate, and join on trace IDs reliably at volume, which free text cannot. It does not replace metrics or traces, and it favors machine-parseability over raw readability.
Read the full bite: Structured vs unstructured logging: why it matters
Question 8 of 30
Across three microservices handling one request, what value is identical on every span, and what value distinguishes each operation within that request?
Show the answer
Answer: a · Trace ID is shared; span ID distinguishes each operation
The trace ID is generated once and carried by every span to group them, while each operation gets its own span ID. Sharing span IDs or minting new trace IDs per hop would break correlation entirely.
Question 9 of 30
Which scenario most strongly favors implementing a push-based metrics collection system?
Show the answer
Answer: a · An application deployed as a serverless function that executes for a very short duration.
The card states that push is ideal for "short-lived or ephemeral workloads like serverless functions or batch jobs, as they might terminate before a pull-based scraper can reach them." Option D describes a risk of push systems (the 'thundering herd' problem), not a reason to favor them.
Read the full bite: Pull vs. Push: How Your Metrics Get to the Collector
Question 10 of 30
Distributed traces show your API returns in 300 ms, but a user reports the sales dashboard feels slow. What instrumentation step best identifies the remaining bottleneck?
Show the answer
Answer: a · Capture front-end Core Web Vitals and custom render timers segmented by device and browser
The card emphasizes that slowness is user-perceived and can stem from front-end rendering or parsing even when back-end latency is low, so real user monitoring with segmentation is needed. Option C is tempting because database slowness is a common culprit, but the traces already show a fast API response. Option D suggests scaling servers, which the card identifies as a red flag when the bottleneck location is unknown. Option B relies on synthetic monitoring, which the card notes misses real user conditions like cache state and data size.
Read the full bite: How would you instrument front-end and back-end to quantify reported slowness?
Question 11 of 30
Why is black-box monitoring usually the faster first step for a legacy app with no internal instrumentation?
Show the answer
Answer: d · It requires no application code changes and shows user-facing symptoms immediately
Black-box probes the system externally, so it needs no instrumentation and quickly reveals whether users are served. It cannot localize root cause or replace white-box signals, which is why those are added later.
Read the full bite: Black-box vs white-box monitoring for legacy apps
Question 12 of 30
An engineer adds a user_id label to a request counter and Prometheus memory usage explodes. What is the underlying cause?
Show the answer
Answer: b · Each unique label combination becomes a separate stored time series
An unbounded label like user_id multiplies the number of unique label combinations, and Prometheus stores one series per combination, so series count and memory explode. Scrape interval changes sample volume per series, not the series count.
Read the full bite: What is high-cardinality data in Prometheus?
Question 13 of 30
Why can tail-based sampling guarantee retention of all error traces while head-based sampling cannot?
Show the answer
Answer: b · Head-based decides before the trace outcome is known; tail-based decides after the trace completes
The sampling timing is the key difference: head-based commits at trace start with no knowledge of the result, so it cannot prefer errors, whereas tail-based waits for completion and can apply outcome-based policies. Hardware and compression are irrelevant to this distinction.
Question 14 of 30
In a high-traffic distributed system, which sampling strategy is most effective for ensuring that traces containing critical errors or high latency are reliably captured, despite increased infrastructure overhead?
Show the answer
Answer: a · Tail-based sampling, as it analyzes the complete trace before deciding to keep it.
Tail-based sampling evaluates the entire trace, including its outcome (errors, latency), before deciding to keep it, thus guaranteeing capture of interesting failures. Head-based sampling decides upfront and might discard traces that later become critical, making it unsuitable for reliably capturing all errors in high-traffic systems.
Read the full bite: Sampling: Tracing Everything Without Storing Everything
Question 15 of 30
In which scenario would log analysis be least effective compared to alternative monitoring tools?
Show the answer
Answer: a · Understanding the end-to-end journey of a single request across multiple microservices.
Log analysis is less effective for understanding a request's journey across multiple services because distributed tracing provides a more structured view for this specific task. The other options are explicitly mentioned as effective use cases for log analysis, such as troubleshooting errors, business intelligence, and performance monitoring.
Read the full bite: Log Analysis: Reading Your System's Story
Question 16 of 30
A company needs to trace data from its microservices to analytics dashboards for faster debugging. What is the most effective and scalable implementation strategy?
Show the answer
Answer: c · Instrument services and pipelines to emit metadata using a standard like OpenLineage, collecting it in a central tool for visualization.
The correct approach involves automated metadata collection via a standard like OpenLineage and a central visualization tool. Manual documentation in a wiki is unscalable and quickly becomes outdated.
Read the full bite: Explain data lineage and how you would implement it
Question 17 of 30
Which scenario, based on an error budget burndown chart, would most clearly signal that an engineering team should prioritize shipping new features?
Show the answer
Answer: b · More than half of the error budget remains available halfway through the monitoring window.
The card explicitly states, "If you have over 50% of your budget left halfway through the month, it's a green light to ship features." While a slower burn rate (option A) is a positive sign, the card provides the remaining budget condition as the direct trigger for prioritizing new features.
Read the full bite: Error Budget Burndown: Your Service's Reliability Fuel Gauge
Question 18 of 30
When a Spark-generated revenue report is off by 2% for only the last three days, what is the correct first step?
Show the answer
Answer: d · Identify the affected cells and anomaly window to contain the blast radius before tracing lineage
The card emphasizes that structured debugging must begin by containing the blast radius—pinpointing exactly which cells are wrong and when the anomaly started—before tracing lineage backward. Option A is tempting because lineage tracing is essential, but performing it without first isolating the scope skips the critical containment step and leads to unfocused investigation.
Read the full bite: How do you root-cause bad data across microservices and Spark?
Question 19 of 30
What is the most effective initial approach when debugging a critical data quality issue reported in a business dashboard?
Show the answer
Answer: b · Begin by assessing the business impact and communicating with stakeholders, then systematically trace the data backward from the dashboard to its source, validating at each stage.
A senior-level approach starts with impact assessment and communication, followed by a systematic, backward trace from the point of error (the dashboard) to the source. Immediately checking logs (Option D) is a common 'bottom-up' mistake, bypassing crucial initial steps.
Read the full bite: How would you debug a critical data quality issue in a pipeline?
Question 20 of 30
A critical financial report shows a sudden, unexpected drop in revenue. What is the most effective first step for a senior data engineer to take?
Show the answer
Answer: d · Assess the blast radius, notify stakeholders, and consider posting a data quality warning.
The correct first step is to contain the issue and manage business impact. While tracing data lineage (C) is the correct next step, a senior engineer must first address the business impact before starting a technical deep-dive.
Read the full bite: How do you debug a data quality issue in a complex pipeline?
Question 21 of 30
A global availability SLI reads 99.95% but users in one region are angry. What design flaw most likely explains this watermelon SLO?
Show the answer
Answer: b · Over-aggregation across regions lets a localized outage disappear into a healthy global number
Averaging across all regions buries a localized outage affecting a small fraction of users, so the global number stays green while real users suffer. Segmenting by region and journey, and measuring client-side, exposes the hidden pain.
Read the full bite: Fixing watermelon SLOs that hide unhappy users
Question 22 of 30
During an incident, which telemetry type best localizes which service in a request path is responsible for added latency?
Show the answer
Answer: a · Distributed traces, because they decompose one request into timed spans across services
A trace breaks a single request into spans across services, directly revealing which hop consumed the time. Metrics show that latency rose but not where, and logs explain a specific event only once you know which service to inspect.
Question 23 of 30
What happens if an application uses the OpenTelemetry API but does not configure an SDK?
Show the answer
Answer: d · The API calls will execute as "no-op" operations, effectively generating no telemetry.
The card explicitly states that "By default, if no SDK is configured, these calls do nothing; they are 'no-op'". This means no telemetry data is generated or buffered, and a default SDK is not automatically activated.
Read the full bite: OpenTelemetry API: The Stable Interface for Your Code
Question 24 of 30
What is the primary function of the OpenTelemetry SDK within an application?
Show the answer
Answer: c · To provide the concrete implementation for processing, sampling, and exporting telemetry data.
The card explicitly states the SDK is the "engine that processes and exports your telemetry data," handling sampling, batching, and sending. Option D describes the OpenTelemetry API, not the SDK. Option B is incorrect as the card advises against using the SDK directly in business logic.
Read the full bite: OpenTelemetry SDK: The Engine for Your Telemetry
Question 25 of 30
When setting SLOs for API latency, why can the mean alone give a misleading view of user experience?
Show the answer
Answer: a · A few extreme tail values can pull the mean up and hide suffering at the p95
Latency data is right-skewed, so a handful of multi-second outliers can inflate the mean and mask terrible tail experiences. Distractor B is tempting but wrong because standard deviation assumes a normal distribution, whereas latency distributions have a long tail and a hard floor near zero.
Read the full bite: Why prefer median and p95 over mean for API latency?
Question 26 of 30
An API's latency dashboard shows a mean of 500ms but a median of 150ms. What does this discrepancy most likely indicate?
Show the answer
Answer: c · Most requests complete around 150ms, but a few very slow requests are skewing the mean upward.
The median represents the typical experience. A mean that is much higher than the median indicates a right-skewed distribution with a 'long tail' of a few very slow requests, which pull the average up without affecting the midpoint.
Read the full bite: Why use median/p95 for API latency instead of the mean?
Question 27 of 30
When analyzing API response times, why are percentiles (e.g., p50, p95) generally considered more informative than the arithmetic mean?
Show the answer
Answer: c · Percentiles better represent the typical and worst-case user experiences because the mean can be heavily skewed by a small number of very slow requests.
The card emphasizes that API response times often have a long-tail distribution where a few slow requests can dramatically skew the mean, making it a poor representation of most users' experiences. Percentiles like p50 (median) accurately reflect the typical user's experience, while p95/p99 capture the worst-case for the majority, directly linking to user satisfaction. Option B, while true that mean is better for normal distributions, doesn't fully capture the user-centric reason for preferring percentiles for latency, which is the core of the card's argument.
Read the full bite: Why use p50/p95 over mean for API response times?
Question 28 of 30
Why does structured logging scale better than unstructured logging for large-system analysis?
Show the answer
Answer: b · Named machine-readable fields can be indexed, filtered, and aggregated reliably instead of parsed with brittle regex
Structured logs expose explicit fields that backends index and query precisely, enabling reliable filtering, aggregation, and correlation at scale. Free-text logs force fragile regex parsing that breaks as messages change, which does not scale.
Question 29 of 30
What is the primary benefit of using an OpenTelemetry Collector instead of an application directly exporting telemetry?
Show the answer
Answer: b · It centralizes telemetry configuration and processing, allowing applications to be decoupled from backend specifics.
The card states the Collector provides "a single, configurable layer to handle data routing, formatting, and enrichment, simplifying both application code and operational overhead" and helps "avoid vendor lock-in" by decoupling applications from specific backend formats and endpoints. While the Collector simplifies application code, applications still typically use OpenTelemetry SDKs to generate the telemetry data that the Collector then processes and exports, making option C incorrect.
Read the full bite: OpenTelemetry Collector: The Swiss Army Knife for Telemetry Data
Question 30 of 30
In OpenTelemetry, why is the API kept separate from the SDK?
Show the answer
Answer: d · So instrumentation libraries can depend on a vendor-neutral, no-op interface while the application chooses the implementation
Splitting the API from the SDK lets libraries instrument against a stable, no-op interface without forcing an implementation, and the app supplies the SDK to actually process and export. The API delegates export to the SDK and does nothing on its own.
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.