PeopleCert DevOps-SRE Site Reliability Engineering (SRE) Foundation v1.2 Exam Practice Test

Comprehensive and Detailed Explanation From Exact Extract:

Google defines SRE as “what happens when you ask a software engineer to design an operations function.” (SRE Book – Introduction). The core engineering approach in SRE focuses on:

Eliminating toil

Building scalable systems

Applying software engineering to operational challenges

Learning from previous solutions and patterns

The SRE Book emphasizes: “SREs focus on designing and engineering solutions that reduce manual operations and scale service delivery.” (Chapter: Eliminating Toil). This aligns directly with Option B: designing a solution to eliminate toil and scale service delivery, informed by prior successful engineering patterns.

Option A focuses only on automating a single tuning activity—not holistic engineering.

Option C describes deployment, not engineering approach to operations.

Option D is about incident response, not engineering strategy.

Thus, B is the best representation of SRE’s engineering approach.

Comprehensive and Detailed Explanation From Exact Extract:

Automation is the primary method of reducing toil in SRE. The Google Site Reliability Engineering Book, Chapter “Eliminating Toil,” states:

“Automation is the most effective tool for reducing toil. Any recurring, manual, automatable task should be automated to prevent it from consuming engineering time.”

Automated release systems directly eliminate toil by:

Removing manual deployment steps

Removing repeated, error-prone human processes

Increasing reliability and consistency

Freeing engineers for high-value project work

The SRE Workbook reinforces this:

“CI/CD pipelines and release automation remove significant operational toil by replacing manual processes with repeatable, reliable automation.”

Why the other answers are incorrect:

B AI is not required for toil reduction.

C Meeting travel is not an SRE toil concern.

D Incorrect; automation dramatically reduces long-term toil, even though initial setup requires effort.

Thus, A is the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

Toil-reduction engineering focuses on making the service itself easier to operate. The most direct way to achieve this is through internal automation — automation built into the service that eliminates repetitive, manual operational tasks.

The Site Reliability Engineering Book, Chapter “Eliminating Toil,” states:

“Automation that replaces manual, repetitive operational tasks is the primary mechanism for reducing toil. The most effective form of toil reduction is automation that is integrated directly into the service itself.”

The SRE Workbook reinforces:

“Internal automation contributes directly to service reliability and reduces the operational burden by ensuring that manual tasks are permanently removed.”

Why the other options are not the best answer:

A Continuous delivery pipelines reduce release friction but do not directly remove service-operational toil.

B External scripts and tools help but are less effective and harder to maintain than internal automation.

C Scalable infrastructure reduces linear-scaling toil but does not address broader operational burdens.

Thus, the correct answer is D.

Comprehensive and Detailed Explanation From Exact Extract:

Chaos engineering is an SRE-aligned practice where systems are intentionally subjected to controlled failure scenarios so teams can observe how the system responds. This practice supports anti-fragility, meaning the system becomes stronger through exposure to failure.

The SRE Workbook, Chapter “Handling Overload” and Chaos Engineering sections, explains:

“Injecting failure in a controlled environment exposes the hidden dependencies, weaknesses, and systemic risks that only appear under stress.”

The Site Reliability Engineering Book reinforces this concept:

“By understanding how systems behave during partial failures, teams can make targeted improvements that reduce recovery time during real incidents.”

Improving Mean Time to Recover (MTTR) happens because:

Weak points and bottlenecks are identified early

Engineers gain familiarity with failure modes

Systems are hardened ahead of actual outages

Dependencies that cause cascading failures are revealed

Why other options are incorrect:

B Monitoring optimization is helpful but not the core mechanism of chaos engineering.

C Chaos engineering does not create auto-recovery automation; it reveals where it is required.

D Caching is an architectural resilience strategy, not an outcome of chaos engineering itself.

Thus, A is the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

SRE defines capacity planning as the discipline of ensuring that a system has enough resources to meet expected demand, both now and in the future. The SRE Book states: “Capacity planning ensures that services have sufficient resources available to meet reliability and performance targets, accounting for growth, trends, and forecasted usage.” (SRE Book – Chapter: Capacity Planning). This involves forecasting workloads, analyzing trends, and creating plans to scale infrastructure so that service-level objectives can continue to be met.

Option C correctly describes capacity planning as creating a resource management plan to meet demand.

Option A refers to capacity monitoring, not planning.

Option B reflects generic resource management or cloud provider operations, not SRE capacity planning.

Option D refers to determining maximum capacity, which is a measurement activity—not full planning.

Thus, C is the correct SRE-aligned answer.

Comprehensive and Detailed Explanation From Exact Extract:

SRE supports microservices architecture because it improves reliability by reducing blast radius, allowing independent deployments, and enabling scalable autonomous teams. The SRE Book notes: “Microservices enable teams to independently iterate and improve reliability without the constraints of large monolithic systems.” (SRE Book – Distributed Systems). One of the strongest reasons to adopt microservices is modernizing and refactoring large legacy monoliths, allowing them to be broken into independently deployable, maintainable components.

Option A is therefore the best justification.

Options B, C, and D may involve architectural choices, but they do not explain why microservices are the preferred architecture for reliability and scalability.

Thus, A is correct.

Comprehensive and Detailed Explanation From Exact Extract:

Before defining any technical details of an SLO, the SRE guidance is clear: the conversation must start from the customer’s point of view. SLOs exist to represent what reliability level users genuinely require—not internal assumptions or engineering preferences.

The SRE Workbook, Chapter “Implementing SLOs,” states:

“The process must begin by understanding what your users need from the service and what good performance actually means from the user’s perspective.”

Likewise, in the Site Reliability Engineering Book:

“SLOs capture the reliability target that makes sense for the users and the product, which is why defining them must begin with understanding the user experience.”

This means that SLO development begins with analyzing:

What users value

What reliability thresholds they notice

What failures matter to them most

Only after this understanding is established should teams discuss metrics, thresholds, SLIs, and error budgets.

Why the other options are incorrect:

A. Identify toil — Relevant to operations, not SLO creation.

B. Evaluate automation — Important for reducing toil, unrelated to initial SLO definition.

D. Assess resources — Planning happens after SLO definition, not before.

Thus, the correct answer is C.

Comprehensive and Detailed Explanation From Exact Extract:

The goal of Site Reliability Engineering (SRE) is to create ultra-scalable and highly reliable distributed software systems. This principle is clearly articulated in the foundational text of SRE, the Google Site Reliability Engineering book.

From Chapter 1: Introduction of the Site Reliability Engineering book:

"SRE is what happens when you ask a software engineer to design an operations team. Our approach to service management is rooted in our belief that engineering work to create scalable and highly reliable systems is critical to the success of modern software."

— Site Reliability Engineering Book, Chapter 1

This statement establishes that building and maintaining scalable, reliable systems is the core mission of SRE. While concepts like reducing toil (option A), implementing SLOs (option B), and aligning with DevOps (option C) are vital components of the SRE practice, they support the overarching goal — which is option D.

Therefore, the correct answer is D: To create ultra-scalable and highly reliable distributed software systems.

Comprehensive and Detailed Explanation From Exact Extract:

“Toil” in SRE has a very specific meaning. According to the Site Reliability Engineering Book, Chapter “Eliminating Toil”:

“Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, has no enduring value, and scales linearly as the service grows.”

The key phrase is “no enduring value.” Toil does not produce lasting improvement, even though it may be necessary in the short term. It consumes engineering effort without making the system better over time.

Why the other options are incorrect:

B Work that has some enduring value cannot be classified as toil by definition.

C Engineering work that adds service features is explicitly non-toil, because SRE defines feature work as “project work,” not operational toil.

D Seems close but is misleading: engineering work without enduring value is poor engineering, not necessarily toil. Toil refers to operations workload specifically.

Thus, A is the correct and precise definition of toil.

Comprehensive and Detailed Explanation From Exact Extract:

Error budgets are a fundamental SRE mechanism for balancing reliability and innovation. The SRE book states: “The error budget directly governs the rate of change: as long as the service stays within budget, development velocity can remain high.” (SRE Book – Chapter: Service Level Objectives). This means teams can push changes aggressively as long as the allowed amount of unreliability has not been consumed.

The error budget acts as a safety threshold. When reliability dips and the error budget is consumed, SRE enforces a change freeze to restore stability. Google explains: “If the error budget is spent, releases are halted and efforts focus on improving reliability.” Feature velocity is not arbitrarily slowed—it is governed solely by the remaining error budget.

Option A best expresses this: when the error budget is high, teams can safely accelerate feature delivery.

Option D incorrectly suggests rushing, which contradicts controlled release practices.

Option B misinterprets error budgets as a percentage-based throttling system.

Option C incorrectly implies that innovation stops entirely only when empty.

Thus, A is the correct interpretation according to official SRE principles.

Comprehensive and Detailed Explanation From Exact Extract:

Kubernetes is described in SRE-aligned literature as an open-source container orchestration platform that automates deployment, scaling, failover, and lifecycle management of containerized applications. The Site Reliability Workbook references Kubernetes as: “a container management system that automatically handles service discovery, scaling, rollout management, and self-healing.” (SRE Workbook – Production Environment chapters). Kubernetes does not replace an OS, nor is it a CI/CD platform; it sits on top of an OS and orchestrates containers across clusters.

Option C is the most accurate: it captures container management, cloud deployment context, automated scaling, and failover—key capabilities of Kubernetes.

Options A and B incorrectly describe CI/CD platforms.

Option D incorrectly labels Kubernetes as an “operating system.”

Thus, C is correct.

Comprehensive and Detailed Explanation From Exact Extract:

SRE is built on transparency and broad information sharing. The SRE Book states: “High-quality operations require that information flows freely between product development, SRE, and associated teams.” (SRE Book – Chapter: Communication and Collaboration). Effective incident management also depends on complete data availability: “Centralized, shared information reduces cognitive load and improves incident resolution.” (SRE Workbook – Incident Management).

Option B aligns perfectly with SRE principles: data must flow freely, ensuring everyone has access to metrics, logs, architecture details, incident context, and SLOs.

Options A, C, and D promote restricted or fragmented data practices, which are directly contrary to SRE design. SRE teams avoid information silos.

Thus, B is correct.

Comprehensive and Detailed Explanation From Exact Extract:

All the listed reasons correctly describe why observability becomes essential in modern, user-focused, dynamically scaling architectures.

The SRE Workbook and Google Observability guidance both emphasize that traditional monitoring is insufficient in environments where:

Services are distributed

Traffic is unpredictable

Customer experience is a priority

Cloud-native, containerized, or microservice architectures are used

Key excerpts:

From Google’s Observability guidance:

“Monitoring relies on known failure modes; observability enables teams to explore unknown-unknowns and understand complex, dynamic systems.”

From the SRE Workbook:

“As systems scale and architectures shift toward microservices or containers, component-level monitoring provides an incomplete picture. Observability enables teams to understand user impact and system behavior holistically.”

Thus:

A Observability is critical for containerized and dynamic environments.

B Component monitoring alone cannot show customer experience or end-to-end reliability.

C Observability helps teams diagnose issues that could not be predicted in advance ("unknown unknowns").

All statements are correct, making D the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

Although Kaizen originates from Japanese lean culture, its mindset aligns strongly with SRE's continuous improvement philosophy. The SRE Book emphasizes a culture where teams identify problems, prioritize them, fix them, and share knowledge, stating that: “Incremental improvements and learning from failures lead to resilient systems, and teams must continuously refine processes and technology.” (SRE Book – Chapters: “Postmortem Culture,” “Eliminating Toil”). Option C captures all key Kaizen elements—problem recognition, prioritization, solution, and knowledge sharing—mirroring SRE’s blameless postmortem and iterative improvement practices.

Option A emphasizes learning but lacks problem ownership.

Option B focuses too narrowly on root cause analysis.

Option D emphasizes experimentation but misses prioritization and lesson-sharing.

Thus, C is the best match for a Kaizen mindset within the SRE framework.

Comprehensive and Detailed Explanation From Exact Extract:

Using verified and signed artifacts is essential for safe automation, ensuring that deployments are consistent and free of dependency or supply chain errors. This is a fundamental principle in Google’s release engineering and SRE practices.

The Site Reliability Engineering Book, chapter “Release Engineering,” states:

“Releases should be built once, tested, signed, and stored in a secure repository. Only signed and verified artifacts should be promoted to production to prevent configuration drift and dependency inconsistencies.”

The SRE Workbook echoes this:

“Automated promotions depend on the integrity and immutability of artifacts. Signed artifacts ensure consistency and prevent errors related to mismatched dependencies.”

Why the other options are incorrect:

A External visibility is irrelevant and may create security risks.

C Error budgets relate to reliability, not artifact promotion.

D SLOs do not define artifact signing; this is handled by release engineering processes.

Thus, the correct answer is B.

Comprehensive and Detailed Explanation From Exact Extract:

The term “wisdom of production” refers to the insights gained from real systems running under actual production conditions. Only production environments exhibit real user behavior, real workloads, true performance characteristics, and authentic failure modes. This concept is rooted in the SRE philosophy that production is the ultimate source of truth for understanding system behavior.

From the SRE Workbook, Chapter “Monitoring”:

“Only production provides the full truth about how a system behaves under real workloads. Production is the ultimate source of wisdom about the system.”

This makes clear that wisdom gained from production is indispensable. Testing and staging environments cannot reproduce all real-world variables, usage patterns, and failure pathways.

Why the other options are incorrect:

A describes engineering approaches but does not define “wisdom of production.”

C is incorrect because staging environments do not provide production wisdom.

D relates to automation strategy, not production insights.

Thus, the accurate meaning of the term is B — The wisdom gained from something running in production.

Comprehensive and Detailed Explanation From Exact Extract:

Application Performance Management (APM) refers to a set of tools and practices used to monitor and manage the performance, behavior, and availability of software applications. Although APM is not defined exclusively in the Google SRE Book, it is described within the broader context of monitoring and observability.

In the SRE Workbook, under Monitoring:

“Application monitoring tools provide insights into the performance, latency, availability, and behavior of applications to help engineering teams maintain reliability.”

Industry-standard APM frameworks (including Google Cloud Operations Suite, formerly Stackdriver) define APM as:

“The monitoring and management of application performance and availability.”

Why the other options are incorrect:

A describes telemetry, not APM.

C describes system monitoring (infrastructure), not application performance monitoring.

D refers to communication of metrics, not the monitoring of application performance.

Therefore, B is the correct definition.

Comprehensive and Detailed Explanation From Exact Extract:

The statement “Toil is not important work” is NOT an SRE principle. This is incorrect based on the official Google SRE documentation. In the Site Reliability Engineering Book, toil is treated as a critical concept, because identifying and reducing toil directly enables reliability improvements and more engineering-focused work. The SRE book emphasizes that toil must be taken seriously and systematically reduced, but never dismissed.

From the SRE Book, Chapter “Eliminating Toil”:

“Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, with no enduring value, and that scales linearly as a service grows.”

The SRE book further emphasizes:

“SRE teams should measure toil, track it, and make constant efforts to reduce it.”

This demonstrates that toil is significant and should not be ignored. Therefore, any suggestion that “toil is not important work” contradicts the documentation.

The other answer choices are actual SRE principles:

Operations is a software problem — From SRE Book Introduction:“SRE’s approach starts with the belief that operations is fundamentally a software engineering problem.”

Operations is a software problem — From SRE Book Introduction:“SRE’s approach starts with the belief that operations is fundamentally a software engineering problem.”

Automate what is currently done manually — Automation is a central SRE philosophy to reduce toil.

Reduce the cost of failure — Error budgets and controlled risk-taking are core SRE concepts designed to reduce the cost of failure.

Thus, the only option that is NOT an SRE principle is C.

Comprehensive and Detailed Explanation From Exact Extract:

Customer Reliability Engineering (CRE) is described in Google's SRE literature as an extension of SRE practices outward to customers who run workloads on cloud platforms. The SRE Book and the SRE Workbook state: “CRE is the practice of sharing SRE principles with customers, working closely with their operations teams, and establishing shared responsibility for reliability.” (SRE Workbook – Chapter: Customer Reliability Engineering). A CRE team collaborates directly with customer engineering and operations teams to identify reliability risks, review architectures, and co-manage SLOs, but does not redesign cloud services or build new features.

Option D matches the exact intention: CRE integrates with the customer’s operations team to share reliability responsibilities, applying SRE methods to customer systems and ensuring both customer and provider work jointly on reliability goals.

Option A is incorrect—CRE does not redesign cloud services.

Option B misinterprets CRE as improving the provider’s internal systems.

Option C incorrectly focuses on feature shipping; CRE is about reliability guidance, not feature delivery.

Thus, D is the correct and SRE-authentic answer.

Comprehensive and Detailed Explanation From Exact Extract:

Availability is the most widely tracked and commonly understood SLO across nearly all digital services. It measures whether users are able to successfully access and use the system. Because unavailability directly impacts user experience, revenue, trust, and reliability, it is the primary SLO used across industries.

The Site Reliability Engineering Book, Chapter “Service Level Objectives,” states:

“Availability is one of the most common and important SLOs since it reflects the basic ability of the service to function for users.”

The SRE Workbook also notes:

“Availability targets (e.g., 99.9%, 99.99%) are the most widely used form of SLOs and form the foundation of error budget policies.”

While performance SLOs are also common, availability SLOs are almost universal and foundational.

Thus, D. Availability is the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

SRE and modern DevOps best practices require that build artifacts—such as binaries, container images, and deployment packages—be stored in a secure, versioned artifact repository. These repositories ensure integrity, traceability, immutability, and security of deployment packages.

While the SRE Book does not use the ITIL term DML, it emphasizes:

“All production binaries should be stored in a secure, versioned repository to ensure consistent, repeatable, and trustworthy deployments.”

— Site Reliability Engineering Book, section on Release Engineering

The SRE Workbook expands on this principle by emphasizing signed and verified artifacts:

“To ensure safe rollout, artifacts must be built once, stored securely, signed, versioned, and deployed from a controlled artifact repository.”

Why the other options are incorrect:

A A CMS manages configuration, not deployment artifacts.

B Subversion is a source code repository, not an artifact repository.

C A DML is an ITIL concept, but SRE practice does not rely on it; instead, SRE uses modern artifact repositories (e.g., GCR, ACR, Artifactory).

Thus, the correct answer is D.

Comprehensive and Detailed Explanation From Exact Extract:

A Heritage Reliability Engineer (HRE) focuses on improving and stabilizing legacy systems, including batch processing systems and older architectures that need modernization. Google uses this concept when applying SRE principles to older platforms that cannot be easily migrated.

From Google’s reliability role expansions:

“Heritage Reliability Engineering applies SRE practices to legacy systems, improving batch processing, stability, and helping teams re-platform to modern architectures.”

This role is specifically aligned with:

Batch job optimization

Migration from legacy systems

Bringing older platforms closer to SRE standards

Thus, the correct answer is B.

Comprehensive and Detailed Explanation From Exact Extract:

Modern SRE-aligned organizations use small, cross-functional product teams capable of owning design, development, testing, and operational reliability. The SRE Book emphasizes: “Effective service ownership arises from small, autonomous teams with diverse skillsets and strong collaboration habits.” These teams share responsibility, encourage feedback, and maintain open communication to meet reliability goals.

Option A correctly identifies the two positive characteristics:

Small and collaborative

Cross-functional skillsets

Options 3 and 4 represent dysfunctional behaviors—SRE literature explicitly discourages responsibility silos and discouraging feedback, as these reduce reliability and slow incident learning.

Thus, A is the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

The SRE Book defines reliability as: “the probability that a system will perform its intended function correctly for a specified period of time.” (SRE Book – Introduction). Reliability focuses on correctness and consistent performance, not simply uptime. Availability (option A) refers to system uptime or accessibility. Durability (option C) refers to long-term data persistence. Throughput (option D) measures volume of work processed over time.

Because the definition explicitly mentions probability of meeting performance standards and correct output over time, it directly matches the SRE definition of reliability.

Thus, B is correct.