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

Comprehensive and Detailed Explanation From Exact Extract:

Anti-fragility focuses on an organization’s ability to respond, adapt, learn, and recover from incidents. The most useful metrics relate to incident detection, response, reliability, and recovery. Deployment frequency, while important in DevOps and DORA metrics, does not directly measure anti-fragility.

From the SRE Workbook, Incident Response section:

“Improving antifragility requires better detection, better recovery mechanisms, and clear reliability goals.”

Key metrics relevant to anti-fragility:

MTTD (Mean Time To Detect) — quicker detection improves resilience

MTTR/RPO — recoverability measures

SLOs — define acceptable reliability thresholds and guide learning

Deployment frequency primarily measures delivery velocity, not resilience.

The Site Reliability Engineering Book emphasizes:

“Antifragility is improved by learning from incidents and strengthening recovery mechanisms rather than by increasing release cadence.”

Why other options are correct for anti-fragility:

A. Mean Time To Detect — critical for detecting failures quickly

B. SLOs — define boundaries for reliability and failure tolerance

D. Recovery Point Objective — measures potential loss during failures

Thus, C is the least useful metric for improving antifragility.

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:

In the Full SRE model, reliability becomes a first-class citizen because SREs own the complete operational responsibility for the service and apply SRE principles end-to-end. The Google SRE Book describes several adoption models (Consulting, Embedded, and Full), and only the Full SRE model has SREs fully accountable for reliability outcomes.

From the Site Reliability Engineering Book, Chapter “SRE Engagement Models”:

“In the Full SRE model, the SRE team is responsible for end-to-end reliability. Reliability becomes a first-class objective, supported through SLOs, error budgets, and systematic reduction of toil.”

The Full model includes:

Full ownership of reliability

Enforcement of SLOs

Error budget policies

Engineering-driven improvement

Other models:

Consulting → SRE gives guidance but doesn’t own reliability

Embedded → temporary embedding to train teams, not full ownership

Platform → focuses on shared tooling, not service ownership

Thus, D. Full is correct.

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:

Traditional IT escalation paths—before modern SRE practices—were generally based on hierarchical or functional structures. The SRE Workbook explains that SRE aims to “replace rigid hierarchical escalation paths with structured incident roles and clear authority during incidents.” (SRE Workbook – Incident Management). These older models include:

Hierarchical escalation: issues are escalated to higher managerial or senior technical tiers.

Functional escalation: issues are escalated across functional lines depending on expertise (network team, DBAs, sysadmins, etc.).

Both models are referenced throughout reliability engineering literature as “traditional escalation paths,” which SRE incident management explicitly avoids by instead using role-based escalation (IC, Communications Lead, Ops Lead, etc.).

Options 3 and 4 (Cyclical and Logical) are not recognized escalation patterns in ITSM or SRE literature.

Thus, the answer is A (1 and 2).

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:

Service Level Objectives (SLOs) are directly tied to user experience, and this connection is central to the SRE philosophy. The purpose of an SLO is to define how well a service must perform to keep users satisfied, without exceeding what is necessary or economically practical.

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

“The most important directive when defining SLOs is that they must reflect the expectations and needs of the users of the service.”

Similarly, the SRE Workbook, Chapter “Implementing SLOs,” highlights:

“SLOs are a tool to measure and control the reliability as experienced by the user.”

This makes it clear that SLOs are fundamentally user-centric. They are not based on internal engineering preferences, management goals, or operational convenience.

Why the other options are incorrect:

B. Management approval — SLOs are not driven by management goals but by user needs.

C. Change success rate — While related to reliability practices, change success is not the basis of SLO creation.

D. Toil reduction — Toil is unrelated to defining service-level targets.

Therefore, the correct answer is A.

Comprehensive and Detailed Explanation From Exact Extract:

Traditional monitoring works well when systems are static and predictable. However, cloud-native, distributed, and microservice-based architectures create highly dynamic environments. In these cases, observability becomes more effective because it provides visibility across entire systems, rather than focusing on individual components.

From Google’s Observability guidance:

“Traditional monitoring relies on predefined dashboards and known failure modes. In modern cloud systems, component-level monitoring becomes insufficient because failures occur in ways that cannot always be predicted.”

Further, in the SRE Workbook:

“Monitoring individual components does not provide adequate visibility into complex distributed systems. Observability enables teams to understand system-wide behavior and user impact.”

Why options are incorrect:

A Observability is not inherently cheaper.

C While true, it is not the best reason; observability's benefit is broader than scale alone.

D Traditional monitoring can support containers but often becomes noisy and ineffective.

Thus, the best answer is B.

Comprehensive and Detailed Explanation From Exact Extract:

A Service Level Indicator (SLI) is a measurement of some aspect of reliability (e.g., latency, availability, quality). One of its defining characteristics is that it must be measured over a specific time window. Without a time horizon, the SLI has no actionable meaning.

From the Site Reliability Engineering Book, Chapter “Service Level Indicators”:

“An SLI is a quantitative measure of some aspect of the level of service that is provided. SLIs are evaluated over a specific period of time in order to understand reliability as experienced by the user.”

The SRE Workbook further states:

“Every SLI must define a measurement window. Without a time horizon, the indicator cannot be used to calculate SLO compliance.”

Why the other options are incorrect:

A SLIs do not need to appear in an SLA; SLAs are external contracts, SLOs/SLIs are internal engineering tools.

B SLIs may include client-side, server-side, or network metrics depending on what reflects user experience.

D SLI agreement is not defined by SRE vs. Agile teams; it is defined by business and user need.

Thus, the correct answer is C.

Comprehensive and Detailed Explanation From Exact Extract:

The Slice-and-Dice model is an SRE adoption pattern where the SRE team owns specific portions of a service—typically the most critical, complex, or high-risk components—while development teams own the rest.

From the SRE Workbook, Organizational Models section:

“In the slice-and-dice model, SREs take responsibility for particular portions of a service or system rather than owning the entire thing. This works well when parts of the system require stronger reliability engineering than others.”

This model is used when:

Services are large or complex

Only certain components need SRE-level reliability

Full SRE ownership is not feasible

Why the other options are incorrect:

A Consultant → SREs advise; they do not own components

B Full → SRE fully owns the entire service

D Platform → SRE builds shared reliability tooling, not owning service slices

Thus, C. Slice and dice is the correct answer.

Comprehensive and Detailed Explanation From Exact Extract:

Error budgets represent the allowable amount of unreliability in a system. Google defines the purpose of error budgets as: “balancing the pace of innovation with the need for reliability.” (SRE Book – Service Level Objectives). When the error budget is healthy, product teams can release features quickly; when it is exhausted, reliability work takes priority. This balance prevents over-investment in reliability and enables safe innovation.

Option B—innovation and reliability—is the exact phrasing used in Google’s SRE literature.

Options A, C, and D do not reflect the core purpose of error budgets.

Thus, B 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:

SRE defines toil as “manual, repetitive, automatable, tactical work tied to running a service” (SRE Book – Eliminating Toil). Repetitive outages are specifically noted as a form of operational toil. The SRE Book and SRE Workbook emphasize adopting automation, intelligent tooling, and machine-learning–assisted systems to reduce toil and decrease Mean Time to Repair (MTTR) and Mean Time to Restore Service (MTRS). The books state: “Reducing MTTR directly increases system reliability more effectively than attempting to eliminate all failures.” (SRE Book – Chapter: Managing Incidents).

AI and advanced automation help detect issues faster, classify patterns, trigger automated remediation, and reduce human intervention—delivering reliability gains through faster repair rather than perfect uptime.

Option A is the only option aligned with SRE’s reliability philosophy.

Options B and C incorrectly suggest increasing MTTR/MTRS.

Option D refers to “perfect MTRS,” which is impossible and contradicts SRE’s acceptance of failure.

Thus, A is correct.

Comprehensive and Detailed Explanation From Exact Extract:

The SRE Book provides a precise definition: “SLIs are the carefully defined quantitative measures of some aspect of the level of service provided. SLOs are the target values or ranges for these indicators.” (SRE Book – Chapter: Service Level Objectives). This establishes a clear hierarchical relationship: SLIs are the measurements, while SLOs define the acceptable target levels for those measurements.

Therefore, option A is correct: SLIs measure things like latency, availability, throughput, and error rate.

SLOs then define the goal such as “99.9% availability over 30 days.”

Option B reverses the relationship.

Option C incorrectly says SLOs measure SLIs, which is backwards.

Option D confuses metrics and targets.

Thus, A is the only choice that aligns with Google’s official SRE definitions.

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:

The SRE Book defines the Four Golden Signals of monitoring as Latency, Traffic, Errors, and Saturation. Specifically, it describes “Errors” as: “the rate of requests that fail, whether explicitly, implicitly, or by policy.” (SRE Book – Chapter: Monitoring Distributed Systems). This includes HTTP 5xx responses, timeouts, and requests served but not meeting success criteria.

This definition matches option B exactly.

Option A describes latency, not errors.

Option C describes traffic.

Option D describes saturation (resource usage).

Therefore, B is the correct and SRE-accurate description of the golden signal for errors.

Comprehensive and Detailed Explanation From Exact Extract:

Simplicity is a core SRE design principle. Google states: “Small, frequent, automated changes reduce risk and improve system stability.” (SRE Book – Release Engineering). Automating continuous, small deployments creates a simple and repeatable pipeline that increases agility while maintaining reliability. This approach aligns with both DevOps and SRE practices: reducing deployment complexity, lowering blast radius, and supporting rapid iteration.

Option B best reflects this philosophy: automated, continuous small deployments provide simplicity, stability, and agility simultaneously.

Option A improves process clarity but does not directly affect agility.

Option C is beneficial but broader and not specific to simplicity.

Option D focuses on control rather than agility.

Thus, B is correct.

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:

In the context of SRE tooling and automation, configuration management platforms like Puppet support large-scale infrastructure reliability by enabling consistency, repeatability, and automation. Puppet’s Discovery capability allows engineers to automatically locate, identify, classify, and group cloud nodes or infrastructure resources. Although not directly from Google’s SRE Book, Discovery aligns with SRE principles of reducing toil and enabling scalable automation. SRE emphasizes “automating away the manual work of locating and managing infrastructure at scale.” (SRE Book – Chapter: Eliminating Toil). Puppet Discovery does precisely this by automatically scanning environments, detecting nodes, and providing metadata to group or manage them.

Option A (Provisioning) refers to creating infrastructure, not identifying it.

Option B (Delivery) relates to CI/CD processes.

Option D (Insight) relates to analytics and reporting, not node identification.

Therefore, C. Discovery is correct as it directly represents the capability described.

Comprehensive and Detailed Explanation From Exact Extract:

Defense-in-Depth (DiD) is a layered security strategy referenced in SRE’s discussions of secure infrastructure and resilience. The perimeter layer is responsible for controlling and monitoring traffic flowing into and out of the network from external sources, such as the public Internet. This includes firewalls, intrusion detection systems, load balancers, and boundary network controls.

While SRE focuses primarily on reliability, the SRE Book stresses the importance of resilient system boundaries: “Perimeter protections are critical where external traffic enters the system.” (SRE Book – Security and Infrastructure considerations).

Option C correctly identifies the Perimeter Layer as the network boundary where data flows in/out from other networks—including the Internet.

Option A (Host layer) secures individual machines.

Option B (Physical layer) refers to hardware, power, racks, etc.

Option D (Data layer) protects stored data, not ingress/egress traffic.

Thus, C is correct.

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:

“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:

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:

SRE emphasizes organizational alignment and collaboration, warning against siloed thinking. The SRE Book highlights: “Local optimizations at the expense of the broader system lead to inefficiency, misalignment, and reduced reliability.” When individuals or teams focus only on their own “parts” instead of shared goals (“the whole”), it results in decreased cross-team communication, isolation, operational friction, and reduced efficiency.

Option B captures this SRE-documented outcome: increased introversion (siloing) and decreased efficiency.

Option A and D describe positive outcomes that contradict SRE principles of collaboration.

Option C implies healthy sharing, which does not result from silo-first behavior.

Thus, B is correct.