Free DevOps-SRE Practice Test Questions and Answers (2026)

Reliability is the formal term for the probability that a system will perform its intended function correctly, meeting specified performance criteria, for a given period under a specific set of conditions. This definition encompasses not just being "up" (availability), but also functioning without errors, producing correct output, and meeting performance standards like latency. It is a more comprehensive measure of a system's quality of service than availability alone.

A. Availability is the measure of a system's uptime, typically (uptime / (uptime + downtime)). It does not inherently include correctness or performance standards.
C. Durability primarily refers to the persistence and integrity of data over time, guaranteeing that stored data is not lost or corrupted.
D. Throughput is a performance metric measuring the rate at which a system processes work (e.g., requests per second), not an overall probability of correct function.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 1, "Introduction," states, "Reliability is the most fundamental feature of any product... a reliable product is one that behaves as expected."

2. Avizienis, A., Laprie, J. C., Randell, B., & Landwehr, C. (2004). Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on dependable and secure computing, 1(1), 11-33. https://doi.org/10.1109/TDSC.2004.2. The paper defines reliability as the "continuity of correct service," which aligns perfectly with the question's definition.

3. Shooman, M. L. (2002). Reliability of computer systems and networks: fault tolerance, analysis, and design. John Wiley & Sons. Chapter 1 defines reliability as "the probability that a system or a component will perform its required functions for a specified period of time under stated conditions."

Full-service ownership, a core tenet of DevOps and SRE, means a single team is accountable for the entire lifecycle of a service. This includes initial design and coding, the process of deploying or "shipping" the service to production, and its ongoing operation and improvement. This model breaks down silos between development and operations, fostering a deeper understanding of the service and leading to higher quality and reliability. Option D best encapsulates this complete "build it, run it, improve it" cycle.

A. "Coding and improvement" omits the critical "shipping" or operational responsibility, making it an incomplete description of full ownership.
B. "Development and performance" is too narrow; full ownership includes reliability, scalability, and the entire deployment process, not just performance.
C. This describes a traditional SRE role focused on operations, but it lacks the development ("coding") aspect required for full-service ownership.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 2, "The Production Environment at Google, from the Viewpoint of an SRE," discusses the software engineering focus of SRE and the shared ownership model, stating, "Google’s SRE teams are composed of software engineers... and are focused on the whole lifecycle of services."

2. Courtois, J. P., & Gousios, G. (2019). Developer-Centered Continuous Deployment: A Case Study at Microsoft. 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). (DOI: 10.1109/ICSE-SEIP.2019.00021). This paper explores the "full-service ownership" model at Microsoft, emphasizing the team's responsibility from code to production.

Toil is the kind of operational work that is manual, repetitive, automatable, tactical, and devoid of enduring value. Crucially, it tends to scale linearly with the growth of a service. As the application grows, so does the toil. The SRE model mandates that engineers spend a significant portion of their time (up to 50%) on engineering projects to reduce or eliminate toil, typically through automation. By engineering toil away, the operational workload scales sub-linearly with service growth, allowing the team to manage a larger, more complex service without a proportional increase in headcount.

A. Simply increasing staffing levels is an anti-pattern. SRE aims to scale the service without scaling the team linearly, which is achieved by reducing manual work.
B. Interruptions are a symptom of operational load, often caused by toil. While reducing interruptions is a goal, addressing the underlying toil is the root solution.
D. On-call rotations are a mechanism for handling incidents. The volume of work during on-call is the problem, which is best addressed by eliminating its root cause: toil.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 5, "Eliminating Toil," p. 50, para. 2: "If a team is exclusively focused on operations, its operational load will scale linearly with service size... To scale, the team must invest some of its time in engineering."

2. Courtois, M., & Daniels, J. (2020). The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media. Chapter 4, "Toil-busting," p. 49: "Toil is the single largest source of both unhappiness and unscalable workloads for SREs."

Capacity planning is a forward-looking process focused on ensuring a service has sufficient resources to meet future demand. It involves forecasting growth, understanding service requirements, and creating a strategic plan to provision resources accordingly. This proactive approach prevents performance degradation and outages caused by resource exhaustion, aligning resource availability with business objectives and user expectations. Monitoring usage (A) is an input to planning, and determining maximum capacity (D) defines a resource's limits, but neither is the planning process itself.

A. This describes capacity monitoring, which is an input to the planning process, not the planning process itself.
B. This is a very general description of resource management, lacking the specific focus on forecasting and meeting future demand that defines capacity planning.
D. This defines 'capacity'—the maximum capability of a resource—but not 'capacity planning,' which is the process of managing it over time.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2018). The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media. Chapter 21, "Capacity Planning for SRE," states, "Capacity planning is the process of ensuring that there is enough capacity in a system to meet an expected level of demand."

Effective product teams, particularly in a DevOps or SRE context, are characterized by being small, collaborative, and cross-functional. Small team sizes (e.g., the "two-pizza rule") enhance communication and agility. A cross-functional skillset means the team possesses all the necessary competencies (development, quality, operations, etc.) to design, build, test, and run their product with a high degree of autonomy. This structure minimizes external dependencies and enables end-to-end ownership and rapid delivery of value. Shared responsibility and open feedback are also crucial, making options 3 and 4 incorrect.

3. They do not share responsibilities: This is incorrect. A key principle of a product team is shared responsibility and collective ownership for the product's success.
4. They discourage any feedback: This is incorrect. Effective teams thrive on continuous feedback loops for learning and improvement, a core tenet of Agile and DevOps.

1. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press. Part II, "The First Way: The Principles of Flow," p. 97: Discusses organizing into "market-oriented teams" that are cross-functional and have end-to-end responsibility.

2. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. Chapter 3, "Technical Practices," p. 37: The research shows that high-performing organizations use a loosely coupled architecture that allows small, autonomous, cross-functional teams to work with high degrees of freedom.

A Service Level Indicator (SLI) is a quantitative measure of a service's performance, such as availability or latency. A critical characteristic of any SLI is that the measurement is defined over a specific period. For example, an SLI for availability might be "the percentage of successful requests over the last 28 days." Without a time horizon or measurement window, the indicator is just a point-in-time metric and cannot be used to track performance trends or evaluate against a target (SLO).

A. SLIs and SLOs can exist without being part of a formal, legally binding Service Level Agreement (SLA). SLAs are business contracts.
B. SLIs should measure what the user experiences, which may require client-side metrics (e.g., page load time), not just server-side metrics (e.g., CPU load).
D. Agreement between teams is essential for setting the target (the SLO), but it is not an inherent technical characteristic of the SLI measurement itself.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 4, "Service Level Objectives," describes SLIs as metrics aggregated over a time window.

2. Jones, C., Rosenthal, D., & Caplinger, J. (2018). The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media. Chapter 2, "Implementing SLOs," provides the formula for SLIs which is calculated over a period, stating "SLIs are typically aggregated over a window of time."

3. Adkins, A., et al. (2020). Building Secure and Reliable Systems. O'Reilly Media. Chapter 11, "Understanding and Managing Risk," reinforces that reliability metrics like SLIs are measured over time to assess system performance against objectives.

The effectiveness of an SRE team, and the DevOps culture it embodies, is critically dependent on transparency and rapid feedback loops. The free flow of data—including metrics, logs, alerts, and postmortem reports—within the SRE team and between SRE and development teams is essential. This practice breaks down information silos, enables shared context, facilitates blameless problem-solving, and allows for data-driven decisions about reliability and engineering priorities. Limiting or siloing data creates friction and slows down the entire system.

A. Limiting data and requiring requests for it creates bottlenecks and information silos, which is directly contrary to effective SRE and DevOps principles.
C. Separating SRE data from others prevents developers and product managers from understanding the operational reality of their services, hindering collaboration and shared ownership.
D. Individual team members managing data discretely leads to a fragmented view of the system and prevents the team from collaborating effectively on systemic issues.

1. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press. Part III, "The Second Way: Amplify Feedback Loops," p. 167: This section emphasizes the need to "enable feedback so that everyone can see the consequences of their actions."

2. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 15, "Postmortem Culture: Learning from Failure," p. 181: The principle of blameless postmortems relies entirely on open, honest, and free-flowing communication and data sharing to identify systemic causes.

The Error Budget is a direct derivative of the Service Level Objective (SLO). It is calculated as 100% - SLO %. The Service Level Indicator (SLI) provides the real-time or historical measurement of the service's actual performance. By comparing the current SLI measurement against the SLO target over a specific window, an SRE team can determine how much of the error budget has been consumed or how much remains. For example, if the SLO is 99.9% and the SLI measures 99.95% performance, the team knows they are well within their budget.

This is a TRUE/FALSE question, so there are no other options to evaluate.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 3, "Embracing Risk," section "Error Budgets," explicitly states, "The error budget is the SLO subtracted from 100%... The current SLI measurement is compared with the SLO to see if the budget is 'in the black' or 'in the red'."

2. Adkins, J., et al. (2020). Building Secure and Reliable Systems. O'Reilly Media. Chapter 13, "Managing Risk," p. 211, defines the error budget as the "delta between the SLO and 100%," which is consumed when the SLI indicates service degradation.

Traditional IT operations models commonly rely on two primary escalation paths. The first is hierarchical, where an issue is passed up the chain of command from junior staff to senior staff and then to management. The second is functional, where an issue is passed between different specialized teams (silos) based on the required expertise, such as from a general help desk to the network team, then to the database team. These paths are often rigid and can introduce delays, which SRE models aim to reduce through shared ownership and automation. Why IncorrectOptions are Wrong:
3. Cyclical: This is not a standard term for an escalation path. An effective escalation process should lead to resolution, not a repeating cycle.
4. Logical: While an escalation path should be logical, "logical" is a quality of a path, not a type of path itself like hierarchical or functional.

B. Cyclical escalation is not a recognised ITIL/DevOps term.
C. See above; cyclical & logical are non-standard in incident escalation literature.
D. Logical escalation is not defined in service-management frameworks.

Kim, G., et al. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press. Part II, "The First Way: The Principles of Flow," discusses the negative impact of functional silos and handoffs, which are characteristic of functional escalation.

Coury, D. & Joseph, K. (2019). What is SRE?. ACM Queue, 17(3), pp. 60-79. https://doi.org/10.1145/3338533.3339131. The article contrasts SRE with traditional operations, implicitly referencing the siloed (functional) and tiered (hierarchical) structures that SRE seeks to improve.

Puppet Discovery is a feature within the Puppet Enterprise suite designed to scan your infrastructure, including on-premise data centers and cloud environments, to locate and identify unmanaged nodes. It gathers detailed information (facts) about these nodes, such as operating system, IP address, and hardware details. This capability allows administrators to gain visibility into their entire estate, group resources based on specific criteria, and then bring them under Puppet management to enforce a desired state, thereby reducing configuration drift and improving security posture.

A. Provisioning is the act of creating new infrastructure, which is a separate function from discovering existing nodes.
B. Delivery refers to the process of deploying applications and code, such as with Puppet's Continuous Delivery for PE.
D. Insight is a general term for analytics or reporting. While discovery provides data for insight, the feature itself is named for its discovery function.

1. Puppet by Perforce. (2019). Puppet Enterprise 2019.8 Documentation. Section: "Discovering and managing nodes with Puppet Discovery." The documentation states, "Puppet Discovery is a tool that helps you find and classify unmanaged resources in your network."

2. Puppet by Perforce. (2021). Puppet Enterprise 2021.7 Documentation. Section: "Discover nodes". The documentation describes how to "Use the node discovery tool to find nodes in your network that you want to manage with Puppet." This confirms the terminology and function.