Free DEVSPS-SRE Practice Test

The "engineering" in SRE specifically refers to using software development skills to address operational challenges. Instead of manually managing systems, SREs build software to automate tasks, manage configurations, and improve system reliability. This includes creating tools for monitoring, provisioning, and incident response. The core principle is to solve problems permanently through scalable, automated solutions rather than through repetitive manual labor (toil). This approach ensures that systems are more robust, predictable, and can scale effectively.

A. Applying network and infrastructure development best practices...: This is too narrow; SRE applies software principles to all aspects of operations, not just network and infrastructure.
B. Applying network design and deploying best practices...: This is also too focused on networking and deployment, omitting the broader software development aspect of SRE.
C. Applying infrastructure engineering principles...: While related, "software development best practices" is more precise, as it emphasizes coding and automation over traditional infrastructure management.

Bets, B., et al. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 1, "Introduction," paragraph 2, explicitly states SRE's approach is to "...use engineers with software expertise, and have them solve... operational problems with software."

Beyer, N. R., et al. (2018). The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media. Chapter 2, "Implementing SLOs," Section "Why This Is Engineering," emphasizes that SREs "...use data, and they use a principled, engineering approach to a problem that historically has been approached with ad hoc, 'best effort' tactics."

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."

The foundational definition of Site Reliability Engineering (SRE) is the application of software engineering principles and practices to the domain of IT operations. SRE treats operations as a software problem, focusing on creating scalable and highly reliable software systems through automation, codification, and data analysis. This approach contrasts with traditional operations models that often rely on manual intervention. The goal is to solve operational problems with code rather than with human effort (toil).

A. ....structural engineering....: This discipline deals with the design and analysis of physical structures like buildings and bridges, not software systems.
B. ....security engineering....: While a critical component of SRE, security engineering is a specialized field and not the overarching approach that defines SRE.
D. ....simulation engineering....: Simulation is a tool used in many engineering fields, including SRE, but it is not the fundamental approach itself.

Bets, B., et al. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 1, "Introduction," paragraph 2, states, "SRE is what you get when you treat operations as if it’s a software problem... SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise..."

Jones, D., et al. (2020). Seeking SRE: Conversations About Running Production Systems at Scale. O'Reilly Media. Chapter 1, "What SRE Is and What It Is Not," Section "SRE Is Software Engineering," states, "SRE is an engineering discipline that applies the principles of computer science and software engineering to the design and development of computing systems..."

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.

The core of the Site Reliability Engineering (SRE) approach is applying software engineering principles to operations problems. A primary goal is to eliminate "toil"—manual, repetitive, and automatable operational work. The scenario of an SRE coding a solution to automate a daily tuning activity perfectly illustrates this. The SRE is not just performing the task but is engineering a permanent, automated solution, which reduces future manual effort, scales better, and embodies the engineering discipline central to the SRE role.

B. While learning from others is good practice, the core engineering approach is the act of building the software solution itself, as described in A.
C. Using a CI/CD pipeline is a common practice in modern software development and operations, not a unique illustration of the SRE engineering approach.
D. Resolving an incident is a reactive, operational task. The SRE engineering approach focuses on proactive, long-term solutions to prevent such incidents or automate their resolution.

1. Beyer, B., Kripalani, A., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. The preface states, "SRE is what happens when you ask a software engineer to design an operations function." Chapter 5, "Eliminating Toil," details the SRE mandate to automate repetitive operational work.

2. MIT OpenCourseWare. (2018). 6.033 Computer System Engineering, Spring 2018. Lecture 22, "Reliability, Part 2: Coping with Overload." The lecture notes discuss the SRE principle of automating operational tasks to ensure system reliability and scalability, which aligns with coding solutions for repetitive activities.

The Kaizen mindset, in the context of SRE and DevOps, is best described as a proactive and continuous desire to improve system reliability and performance. This is practically manifested by actively seeking out problems, whether from incidents or proactive analysis, and performing deep root cause analysis. The goal is not to assign blame but to understand the systemic causes of failure. Documenting and sharing the lessons learned from this analysis is crucial for ensuring that the same problems do not recur, thus creating a cycle of incremental, continuous improvement.

A. While enthusiasm for learning is part of the culture, this option is too general; the Kaizen mindset is more specifically about the process of improvement.
C. This is similar to the correct answer but "recognize problems" is more passive than "seek out the problem," which better captures the proactive nature of Kaizen.
D. While experimentation is a valid improvement technique, Kaizen traditionally emphasizes small, incremental changes made by everyone, not necessarily formal experimentation to find the single "best" solution.

1. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. Part II, "The Second Way," emphasizes amplifying feedback loops to see and solve problems as they occur, a core tenet of Kaizen applied to DevOps.

2. Imai, M. (1986). Kaizen: The Key to Japan's Competitive Success. McGraw-Hill. This foundational text defines Kaizen as a continuous improvement process that involves everyone and is based on a disciplined, problem-solving methodology focused on identifying root causes.

3. Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill. Principle 12, "Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu)," and Principle 14, "Become a learning organization through relentless reflection (Hansei) and continuous improvement (Kaizen)," directly support the process of seeking out problems and their root causes.

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 "four golden signals" are a set of key metrics recommended for monitoring a user-facing system. The 'Errors' signal specifically tracks the rate of requests that are failing. This failure can be explicit, such as an HTTP 500 error code, or implicit, where a request returns a success code but the content is incorrect or incomplete. It can also be defined by policy, such as a request that exceeds a latency threshold being counted as an error. Monitoring this signal is critical for understanding the immediate health and correctness of a service.

A. This describes the golden signal of Latency, which measures the time it takes to service a request.
C. This describes the golden signal of Traffic, which measures the overall demand on the system.
D. This describes the golden signal of Saturation, which measures how "full" the service is in terms of its constrained resources.

1. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Chapter 6, "Monitoring Distributed Systems," defines Errors as "The rate of requests that fail, either explicitly (e.g., HTTP 500s), implicitly..., or by policy."

2. Schulman, A. (2018). Monitoring and Alerting for SREs. In Proceedings of the 2018 USENIX Conference on System Administration (LISA18). Section 2.1, "The Four Golden Signals," reiterates the Google SRE book's definition for the error signal.

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.