Top 30 Easy Monitoring & SRE Concepts Quiz for Beginners
30 easy multiple-choice Monitoring & SRE concept questions, the vocabulary and first principles, the parts you need before anything else makes sense. They come from 30 bites in the Monitoring & SRE library, the gentlest slice of the 132 Monitoring & SRE concept questions in the 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 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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
Question 11 of 30
What is the main challenge log aggregation addresses when debugging issues in a distributed system?
Show the answer
Answer: c · The time-consuming and error-prone process of manually collecting and correlating logs from multiple, scattered sources.
Log aggregation primarily solves the problem of logs being scattered across many machines, making manual collection and correlation for debugging slow, error-prone, and unscalable. While it can aid in managing storage or enabling alerts, these are secondary benefits or features built upon the core centralization.
Read the full bite: Log Aggregation: Centralize Your System's Story
Question 12 of 30
Which statement accurately describes a core aspect of Prometheus's data model and a potential pitfall?
Show the answer
Answer: c · It uses a dimensional model with labels, where high-cardinality labels can cause performance and storage issues.
Prometheus uses a dimensional data model with key-value labels, allowing flexible data slicing and aggregation. However, using high-cardinality labels creates too many unique time series, leading to performance and storage problems. Option A is incorrect because Prometheus is pull-based and excels in dynamic cloud environments.
Read the full bite: Prometheus: Monitoring with a Dimensional Data Model
Question 13 of 30
What is Grafana's primary function in an observability stack?
Show the answer
Answer: d · To provide a unified visualization interface for data from various sources.
Grafana is described as a "universal visualization layer" that connects to various data sources to display information in one place. It is explicitly stated that Grafana is not a data storage solution, a deep log analysis tool, or an event streaming platform.
Read the full bite: Grafana: Your Single Pane of Glass for Observability
Question 14 of 30
What is the ultimate goal for an on-call engineer, beyond just responding to immediate alerts?
Show the answer
Answer: b · To use operational insights to drive engineering projects that reduce future alerts.
The card states, "The ultimate goal for an on-call engineer is to use their operational insights to drive engineering projects that make their own future shifts quieter." This highlights the proactive aspect of improving systems to prevent future incidents. While documenting incidents (Option C) is important, it is not the ultimate goal of reducing the need for on-call responses.
Read the full bite: On-Call Rotations: Engineering Reliability Under Pressure
Question 15 of 30
For which scenario would implementing the Incident Command System (ICS) be most beneficial?
Show the answer
Answer: d · A critical production service experiences an outage requiring coordination across multiple engineering teams.
ICS is designed for urgent, large-scale problems that require multiple people or teams to resolve, as described in option D. The other options represent minor issues, single-team resolutions, or routine tasks where the formal structure of ICS would introduce unnecessary overhead.
Read the full bite: Incident Command: Who Does What in a Crisis
Question 16 of 30
Which scenario best illustrates the core value of an on-call management platform?
Show the answer
Answer: a · Ensuring that critical production alerts reliably reach the appropriate engineer and are escalated if unacknowledged.
The card highlights that an on-call platform acts as a "smart switchboard" to ensure critical alerts reliably reach the right person and are escalated if not acknowledged, which is crucial for effective incident response. The other options describe functions of logging, deployment, or monitoring dashboards, not the primary role of an on-call platform.
Read the full bite: On-Call Management Platforms: Who Wakes Up?
Question 17 of 30
According to the incident management lifecycle, what is the most critical step for long-term organizational improvement?
Show the answer
Answer: c · Conducting a post-incident review to prevent future occurrences.
The card explicitly states that "Prevention and Learning" through a post-incident review is "most critically" important for implementing changes to prevent recurrence. While other steps like identification and resolution are crucial for immediate service restoration, they do not inherently lead to long-term organizational improvement by preventing future incidents.
Question 18 of 30
What is the primary responsibility of the Incident Commander within an activated ICS structure?
Show the answer
Answer: a · Coordinating efforts, delegating tasks, and removing obstacles for the team.
The card states the IC's job is to "coordinate, delegate, and remove roadblocks," explicitly noting they "do not perform hands-on technical work." Managing external communications is typically delegated to a Communications Lead.
Read the full bite: Incident Command System (ICS): Taming Outage Chaos
Question 19 of 30
When managing a complex system like container orchestration, why is declarative automation generally preferred over imperative?
Show the answer
Answer: c · It allows the system to automatically reconcile the actual state with the desired state.
Declarative automation is preferred for complex systems because it defines the desired end state, and the system's control loop automatically works to enforce that state, enabling self-healing. Option A describes imperative automation, which focuses on explicit step-by-step instructions.
Question 20 of 30
What is the main objective of implementing a CI/CD pipeline?
Show the answer
Answer: c · To automate the process of building, testing, and deploying software changes.
The correct answer (C) accurately describes the CI/CD pipeline's core function: automating the entire software release process from code changes to deployment. Option D is a tempting distractor as it describes Continuous Deployment, which is an optional final step, and the pipeline's main objective also includes rigorous testing and delivery, which might involve manual gates.
Read the full bite: CI/CD Pipeline: Automating Code from Commit to Production
Question 21 of 30
What is the immediate consequence if a critical, show-stopping bug is identified during Release Candidate (RC) testing?
Show the answer
Answer: c · The bug is fixed, and a new Release Candidate (e.g., RC2) is created, which then undergoes renewed validation.
The card explicitly states that if a critical bug is found, it is fixed, and a new RC (e.g., RC2) is issued, restarting the final validation process. This ensures the 'promise' of the RC as a stable, shippable version is upheld. Option D is incorrect because a new RC is issued, not the old one patched and released.
Read the full bite: Release Candidate: The Final Dress Rehearsal
Question 22 of 30
What is the primary goal of conducting a load test on a software application?
Show the answer
Answer: c · To confirm the system can maintain acceptable performance under expected user traffic levels.
Load testing's core purpose is to ensure a system performs adequately under a realistic, expected load, as stated by 'Can our system handle expected traffic?'. Option A describes stress testing, which aims to find the breaking point, not the expected performance.
Read the full bite: Load Testing: Simulating Real-World User Traffic
Question 23 of 30
What is the primary purpose of conducting a stress test on a critical software system?
Show the answer
Answer: a · To determine its breaking point and how it behaves under extreme pressure.
Stress testing aims to push a system beyond its normal limits to find its breaking point and observe how it fails under extreme load. It is not designed to verify functional correctness or performance under typical loads, nor is its primary goal security vulnerability identification.
Read the full bite: Stress Testing: Finding Your System's Breaking Point
Question 24 of 30
Which factor is most crucial for ensuring a benchmark provides reliable and actionable performance data?
Show the answer
Answer: a · Defining a repeatable workload and executing it in a stable, isolated environment.
The card emphasizes that a benchmark is a "controlled experiment" requiring a "specific, repeatable workload" and a "stable, isolated environment" to get trustworthy numbers. Running tests with live user traffic (option B) introduces uncontrolled variables, making consistent comparisons difficult.
Question 25 of 30
In system development, what is the main objective of defining Non-Functional Requirements (NFRs)?
Show the answer
Answer: c · To specify measurable criteria for the system's quality attributes like speed and reliability.
NFRs define "how well" a system performs by specifying measurable criteria for quality attributes such as performance, security, and reliability, ensuring the system is robust and usable. Options A and D describe functional requirements, which define "what" the system does, while option D describes a specific aspect of usability, which is an NFR, but not the overarching objective of defining NFRs as measurable criteria.
Read the full bite: Non-Functional Requirements: How a System Should Be, Not Just What It Does
Question 26 of 30
Which statement best describes a Single Point of Failure (SPOF) in a system?
Show the answer
Answer: a · A component whose failure will cause the entire system to become unavailable.
A Single Point of Failure (SPOF) is defined as a component whose failure leads to a total system outage, making the entire system unavailable. While other options might describe characteristics sometimes associated with SPOFs, they are not the defining feature; for instance, a difficult-to-replace component might still have redundancy.
Read the full bite: Single Point of Failure: Your System's Achilles' Heel
Question 27 of 30
What is a fundamental requirement for an application to effectively leverage horizontal scaling?
Show the answer
Answer: c · It must be designed to be stateless, allowing any instance to handle any user request.
Horizontal scaling requires applications to be stateless so that any instance can handle any request, with shared state managed externally. Option B describes a stateful application, which is explicitly stated as a 'footgun' and a reason *not* to use horizontal scaling.
Read the full bite: Horizontal Scaling: Add More Machines, Not Bigger Ones
Question 28 of 30
Which statement best describes the primary goal of Chaos Engineering?
Show the answer
Answer: c · To identify and fix systemic weaknesses in a complex system before they cause real-world outages.
Chaos Engineering's primary goal is to proactively find systemic weaknesses in complex systems to build resilience and prevent outages, as stated in the card. It does not aim to eliminate all bugs in individual services, nor does it focus on optimal performance under ideal conditions or attempt to simulate every conceivable failure.
Read the full bite: Chaos Engineering: Finding Weaknesses Before They Find You
Question 29 of 30
In Chaos Engineering, what is the intended outcome when an experiment successfully disproves the steady state hypothesis?
Show the answer
Answer: c · It reveals a systemic vulnerability requiring attention to enhance resilience.
Disproving the steady state hypothesis means the system failed to maintain its normal behavior under a fault, thereby revealing a systemic weakness that needs to be addressed. Option D is incorrect because the hypothesis focuses on observable, external behavior, not internal component logic.
Read the full bite: Steady State Hypothesis: The Core of Chaos Engineering
Question 30 of 30
What is the core principle that differentiates Site Reliability Engineering (SRE) from traditional operations models?
Show the answer
Answer: b · SRE treats the challenges of running a service as software engineering problems that require automated solutions.
SRE's fundamental shift is applying software engineering principles to operations, focusing on automation and reducing manual toil. Option A describes a key aspect of traditional operations that SRE aims to reduce, not its core differentiating principle.
Read the full bite: The SRE Mandate: Breaking the Dev vs. Ops Cycle
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.