Top 30 Monitoring & SRE Concepts Quiz
30 multiple-choice questions on the Monitoring & SRE fundamentals, drawn from 30 bites in the Monitoring & SRE library. 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.
Observability, incident response, reliability, SLOs
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
What is the core philosophy behind Site Reliability Engineering (SRE)?
Show the answer
Answer: b · To treat operational challenges as software problems that can be solved through engineering.
SRE's fundamental principle is to approach operations as a software problem, using engineering to automate and manage systems, as stated in the card. Option D is incorrect because SRE was developed as a new approach to overcome the limitations of traditional operations.
Read the full bite: Site Reliability Engineering (SRE): Ops as a Software Problem
Question 2 of 30
Which of the following best exemplifies 'toil' in an engineering context?
Show the answer
Answer: c · Manually running a script to provision resources for each new customer
Option C perfectly matches the definition of toil: it is manual, repetitive, automatable, tactical, provides no lasting value, and scales linearly with service growth. Option A, attending meetings, is explicitly categorized as 'overhead' rather than toil, as it doesn't scale with service load in the same way.
Read the full bite: Toil: The Repetitive Work That Kills Engineering Velocity
Question 3 of 30
What does it signify if an SRE team consistently operates well within its allocated error budget?
Show the answer
Answer: b · The team is being overly cautious, potentially sacrificing innovation for unnecessary stability.
The card explicitly states that having too much error budget left over signals being "too conservative and slowing innovation," indicating that resources might be better spent on new features or calculated risks. Option D is tempting but incorrect because the card notes that users often cannot perceive the difference between high and extreme reliability, making excessive investment in stability pointless.
Read the full bite: Embracing Risk: Reliability Is a Budget, Not a Goal
Question 4 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 5 of 30
What is the typical immediate consequence when a service's error budget is exhausted?
Show the answer
Answer: c · All non-essential feature releases are temporarily halted to prioritize reliability work.
The card states that exhausting the error budget typically triggers a freeze on non-essential releases, redirecting focus to reliability work. The Service Level Objective (SLO) is the target from which the budget is derived; exhausting the budget means the service is failing to meet the SLO, not that the SLO itself should be changed.
Read the full bite: Error Budgets: Balancing Reliability and Innovation
Question 6 of 30
Which core principle defines the 'blameless' approach in a postmortem?
Show the answer
Answer: b · Human errors are symptoms of systemic issues, and everyone involved acted with good intentions.
The card explicitly states that a blameless postmortem 'assumes that everyone involved in an incident acted with good intentions' and 'treats human error not as the cause of failure, but as a symptom of a deeper, systemic issue.' Option A describes a blame-focused approach, which is the antithesis of a blameless postmortem.
Read the full bite: Blameless Postmortems: Fix Systems, Not Blame
Question 7 of 30
What is the primary reason a service provider's internal Service Level Objective (SLO) is typically set higher than its external Service Level Agreement (SLA)?
Show the answer
Answer: a · To provide a safety margin for the engineering team before contractual penalties are triggered.
The card explicitly states that "The buffer between the SLO and SLA gives engineering a margin for error before a failure costs the company money." This means the higher SLO acts as an internal target that, if met, ensures the external, contractually binding SLA is also met, thus avoiding financial penalties. Option D describes a potential positive outcome, but not the primary strategic reason for the buffer from the provider's perspective.
Read the full bite: Service Level Agreement (SLA): The Contract Behind Uptime
Question 8 of 30
To achieve the highest leverage and scale SRE's impact across numerous product teams, which engagement model is most effective?
Show the answer
Answer: a · SRE Platform, which provides validated, reliable infrastructure for product teams to build upon.
The SRE Platform model is described as 'the most scalable model' where SREs build reliable infrastructure for product teams to use, allowing them to inherit reliability by default. While Early Engagement is proactive, it still involves direct SRE consultation per team, which offers less leverage and scalability than a shared platform.
Read the full bite: SRE Engagement Models: From Gatekeeper to Platform Builder
Question 9 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 10 of 30
What is the primary purpose of a health check endpoint, distinguishing it from merely confirming a service process is running?
Show the answer
Answer: d · To allow external systems to detect if the service can perform its core functions and route traffic accordingly.
The card explicitly states that a health check answers 'Can you do your job?', enabling load balancers and orchestrators to stop routing traffic to sick instances. Options A and D are incorrect because health checks provide a binary signal, not detailed metrics or comprehensive logs. Option A is a distractor because while orchestrators may restart services based on health checks, the health check itself provides the signal of functional impairment, not the direct trigger for a restart based solely on resource thresholds.
Read the full bite: Health Checks: Is Your Service Alive or Just Running?
Question 11 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 12 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 13 of 30
When designing metrics for a time-series monitoring system, what is the most critical concern associated with adding a label that has a very large number of unique values (high cardinality)?
Show the answer
Answer: c · It causes the monitoring system's in-memory index to bloat, leading to increased resource consumption and slower queries.
The card explicitly states that high cardinality "bloats this index, consuming RAM and slowing down queries." The canonical example further illustrates how memory usage skyrockets and queries time out, making the system unusable. High cardinality affects performance and resource usage, not the mathematical accuracy of aggregations.
Read the full bite: Cardinality: The Hidden Cost of Time-Series Metrics
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
According to the error budget concept, when should a development team prioritize reliability work over shipping new features?
Show the answer
Answer: a · When the error budget is low or exhausted, indicating a risk to the SLO.
The card states that when the budget is low or exhausted, all non-essential changes are frozen to focus on reliability. Option B describes the opposite scenario, where a healthy budget allows for new features and experiments, not a shift to prioritizing reliability.
Read the full bite: Error Budgets: The Currency of Reliability
Question 16 of 30
What is the primary reason the card advises against using calendar months for SLO time windows?
Show the answer
Answer: b · Their varying lengths complicate consistent error budget calculations.
The card explicitly states that calendar months have 'unequal lengths and complicate budget math,' making a 1% error budget represent different amounts of downtime. This inconsistency makes it difficult to calculate and manage the error budget reliably. Option A is a general issue with long windows, not specific to calendar months' primary drawback.
Read the full bite: SLO Time Windows: Choosing Your Measurement Period
Question 17 of 30
Which statement best describes the fundamental purpose of an SLO document?
Show the answer
Answer: c · To establish a formal, measurable agreement on a service's acceptable reliability, guiding engineering decisions.
The card defines an SLO document as a "formal contract" that specifies "measurable targets" for reliability, guiding "engineering priorities" and "data-driven decisions." Option C directly reflects this core purpose. The other options describe different types of documentation or tools, not an SLO document.
Read the full bite: SLO Document: Your Service's Reliability Contract
Question 18 of 30
What is the primary advantage of using SLO burn rate alerting compared to a simple alert when the error rate exceeds the SLO threshold?
Show the answer
Answer: c · It enables early detection of both rapid service failures and gradual performance degradations.
SLO burn rate alerting was developed to provide early, actionable warnings for significant events, addressing the limitations of simple threshold alerts which are often too slow for outages and too noisy for minor issues. Option A is incorrect because burn rate monitors consumption rate, it doesn't primarily calculate the total budget. Options C and D describe unrelated functions; burn rate is an alerting mechanism, not an auto-scaler or an SLO definition tool.
Read the full bite: SLO Burn Rate: Alerting on Budget Consumption
Question 19 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 20 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 21 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 22 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 23 of 30
When should a developer typically create a new Span in a distributed application?
Show the answer
Answer: b · To mark the beginning and end of any I/O operation or significant computation.
The card states Spans should be used for "distinct, time-bound operation" such as "network calls" or "significant in-process computations." Option C is incorrect because over-instrumenting trivial operations adds overhead and noise. Option A describes a Trace, which is a collection of Spans, not a single Span.
Read the full bite: Span: The Building Block of a Distributed Trace
Question 24 of 30
What is the primary problem OpenTelemetry Semantic Conventions are designed to solve in a distributed system?
Show the answer
Answer: c · Providing a unified and consistent way to name telemetry attributes across different services and technologies.
The card states that Semantic Conventions solve the "chaos" of different services reporting status using "different naming conventions" by creating a "single, shared standard" for attributes. While conventions enable powerful features like automatic dashboards, their core purpose is to standardize the data's meaning, not to directly generate visualizations or reduce collection overhead.
Read the full bite: OpenTelemetry Semantic Conventions: A Shared Vocabulary
Question 25 of 30
What is the primary advantage of using OpenTelemetry Protocol (OTLP) in an observability ecosystem?
Show the answer
Answer: d · It provides a unified, vendor-neutral standard for transmitting traces, metrics, and logs.
OTLP's core purpose is to provide a standardized, vendor-neutral wire protocol for transmitting all types of telemetry data (traces, metrics, logs), solving vendor lock-in. Option A is incorrect because OTLP defines a new standard for transmission, rather than directly translating existing proprietary formats; that translation is typically handled by an OpenTelemetry Collector.
Read the full bite: OpenTelemetry Protocol (OTLP): The Universal Adapter for Telemetry
Question 26 of 30
What is the primary benefit of using an OpenTelemetry Resource in a distributed system?
Show the answer
Answer: b · It establishes a stable, common context for all telemetry from a specific service instance.
The correct answer is C because a Resource provides a stable, consistent "return address" for all telemetry from a service instance, enabling correlation and filtering. Option D is incorrect as Resource attributes are immutable for the process lifetime, not dynamically modifiable.
Read the full bite: OpenTelemetry Resource: The 'Who' of Your Telemetry
Question 27 of 30
In a distributed microservice architecture, what fundamental problem does W3C Trace Context-based context propagation address?
Show the answer
Answer: b · It provides a standardized way to link individual service logs to a single, end-to-end user request.
Context propagation's primary role is to pass a shared identifier (trace-id) across service calls, enabling all related events for a single user request to be correlated for end-to-end debugging and monitoring. Options A, B, and D describe other important but distinct concerns in microservice architectures, not the function of context propagation.
Read the full bite: Context Propagation: Stitching Microservices Together
Question 28 of 30
How is a defined Telemetry Processor integrated into the active data flow of an OpenTelemetry Collector?
Show the answer
Answer: a · By referencing its name within the processors list of a pipeline under the service section.
The card states that defining a processor does not activate it; to make it part of the data flow, it must be referenced by name in the pipelines section under the service section. Configuring its settings (option C) only defines the processor, but does not integrate it into an active pipeline.
Read the full bite: Telemetry Processors: The Middle of the OTel Pipeline
Question 29 of 30
A developer wants to use Prometheus Exemplars to ensure a complete, auditable record of all slow requests over the past month. Why is this an inappropriate use case for exemplars?
Show the answer
Answer: c · Exemplars store only a fixed-size, recent sample of events in memory, not a comprehensive historical record.
The card states exemplars are "samples, not an exhaustive record" and are stored in a "fixed-size circular buffer in memory," meaning they only keep recent examples and are "not suitable for auditing or getting a complete list of every event." Option D is incorrect because exemplars link aggregate metrics to specific trace details. Option A is incorrect as the card explicitly mentions linking to trace IDs for systems like Jaeger or Zipkin. Option B is an exaggeration; while they add overhead, the card advises mindfulness, not universal impracticality.
Read the full bite: Prometheus Exemplars: Link Your Metrics to Traces
Question 30 of 30
Which task is a Time-Series Database (TSDB) uniquely optimized to perform efficiently?
Show the answer
Answer: c · Aggregating and analyzing millions of sensor readings collected every second over long periods.
The card states TSDBs are optimized for "constant, high-volume writes of timestamped records, and queries that aggregate data over time ranges," making them ideal for sensor data. Option D describes a strength of relational databases, which TSDBs are explicitly not suited for due to their lack of support for complex relationships.
Read the full bite: Time-Series Databases: Optimized for Data Over Time
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.