I85PREP
⌘ K
SRE Practitioner study materials
SRE Practitioner study resources

SRE Practitioner practice questions

One question at a time. Build your SRE Practitioner understanding.

First 50 of 199 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1SRE culture, principles and antipatterns

In SRE practice, what is an error budget?

  1. The share of each quarter that a team reserves for reliability engineering work rather than features
  2. How much unreliability the SLO permits over its window Correct answer.
  3. The maximum number of incidents the on-call rotation may declare in a month before escalating to management
  4. The pool of cloud spend held back for failover capacity in the secondary region

Explanation

An error budget is the complement of the SLO: if a service targets 99.9% availability over 30 days, roughly 0.1% of that window may be spent on unavailability. It turns reliability from an abstract aspiration into a quantity the team can deliberately spend on releases and experiments. Once spent, the error budget policy governs what happens next.

Question 2SRE culture, principles and antipatterns

Which description best matches how SRE defines toil?

  1. Any operational task that has not yet been captured in a written runbook
  2. Manual, repetitive, automatable work that scales with the service Correct answer.
  3. Work that requires privileged production access and an approved change ticket
  4. Any work performed outside normal business hours by the on-call engineer on duty

Explanation

Toil is work that is manual, repetitive, automatable and tactical, grows linearly as the service grows, and produces no enduring value once completed. Because it scales with the system, it must be engineered away rather than absorbed by headcount. Work that is novel or leaves lasting improvements is not toil even if it happens in production.

Question 3SRE culture, principles and antipatterns

What is the primary purpose of a blameless postmortem?

  1. To assign a severity rating that determines how quickly the on-call engineer must respond
  2. To learn why the system allowed the failure and to drive actions that reduce recurrence Correct answer.
  3. To identify which engineer caused the outage so it can be noted in their performance review
  4. To produce a formal root-cause document that satisfies the annual compliance audit

Explanation

A postmortem exists so the organisation can learn: what happened, which conditions made it possible, and what changes will make recurrence less likely. Assuming good intent lets people describe their actions honestly, which is where the most useful evidence comes from. The output is owned, tracked action items rather than a verdict about a person.

Question 4SRE culture, principles and antipatterns

Which statement correctly distinguishes SLI, SLO and SLA?

  1. The three terms are effectively synonyms, and different organisations simply prefer to use one of them over the others
  2. An SLI is a measured indicator, an SLO is an internal target for it, and an SLA is a business contract Correct answer.
  3. An SLI is the customer-facing contract, an SLO is the measured value of that contract, and an SLA is the threshold that triggers alerts
  4. An SLA is the internal engineering target, an SLO is the external customer contract, and an SLI is the penalty clause attached to it

Explanation

An SLI is a quantitative measurement such as the proportion of successful requests. An SLO is the internal target range for that measurement over a window, and the error budget is derived from it. An SLA is a business agreement with customers that carries consequences when breached, and it is normally looser than the internal SLO.

Question 5SRE culture, principles and antipatterns

A service has burned its entire quarterly error budget. Under a conventional error budget policy, what happens next?

  1. All alerts for the service are silenced until the next measurement window begins
  2. Releases are frozen and effort moves to reliability until the budget recovers Correct answer.
  3. The on-call rotation is doubled for the following quarter to increase coverage
  4. The SLO target is automatically lowered so that the service is compliant again

Explanation

An error budget policy is agreed in advance and states that when the budget is exhausted, risky change stops and engineering focus shifts to fixing the sources of unreliability. This keeps reliability and feature velocity in an explicit, pre-negotiated trade-off instead of an argument during an outage. Releasing resumes once the service is back within budget.

Question 6SRE culture, principles and antipatterns

A product team proposes a 100% availability SLO for its service. What is the strongest SRE objection?

  1. SLOs must be set below 90% to remain valid for any production service
  2. Availability of 100% cannot be observed with current monitoring tooling
  3. The cost of each extra nine rises sharply and leaves no budget for change Correct answer.
  4. A 100% SLO is valid only for internal services with no external customers at all

Explanation

Reliability is a dial that trades against velocity, cost and feature scope, and each additional nine typically costs disproportionately more engineering and infrastructure. A 100% target leaves an error budget of zero, so any change becomes a policy violation and the service effectively stops evolving. SRE instead picks a target that satisfies users and leaves room to take risk.

Question 7SRE culture, principles and antipatterns

Why does SRE discourage routing every production change through a manual change-approval board?

  1. It should be replaced by a rule that requires two senior approvals for every production change
  2. It centralises decisions with reviewers who cannot judge each change; small batched changes work better Correct answer.
  3. Manual change approval is a mandatory SRE requirement for every production change
  4. It slows deployment down, so teams should remove all gates and deploy continuously without any checks

Explanation

A gate that reviews individual changes cannot meaningfully assess risk it has no context on, so it mostly adds delay and encourages larger, riskier batches. SRE instead reduces the cost of failure through small frequent changes, automated testing, canary analysis, progressive rollout and fast rollback. The goal is safe change, not fewer changes at any cost.

Question 8SRE culture, principles and antipatterns

An organisation relies on one or two engineers who always jump on critical incidents and know the systems best. Why is this hero culture an antipattern?

  1. It shortens recovery time because the heroes know the systems better than anyone else
  2. It is acceptable as long as the heroes are publicly recognised and rewarded for it
  3. It concentrates knowledge and masks systemic gaps, making reliability depend on individuals Correct answer.
  4. It is simply a form of toil that disappears once the team hires enough additional engineers and documents its runbooks

Explanation

Hero culture hides the systemic problems that make incidents hard to resolve, because the same people repeatedly compensate for missing tooling, documentation and automation. It also drives burnout and creates a single point of human failure, since reliability now depends on those individuals being available. The fix is engineering work that makes the response routine, not more heroes.

Question 9SRE culture, principles and antipatterns

Which statement reflects the common SRE guidance on how much of a team's time should be spent on toil?

  1. No more than roughly half of a team's time should go to toil Correct answer.
  2. Toil should never exceed ten percent of a team's working time in any given quarter
  3. Every identified piece of toil must be fully automated within the same quarter it was found
  4. Exactly half of every sprint must be dedicated to on-call shifts regardless of current toil levels

Explanation

SRE teams aim to cap operational toil at about 50% of their time, leaving the remainder for engineering work that reduces toil and improves reliability. The threshold matters because toil grows to fill available capacity if it is not bounded, leaving no room for the projects that would eliminate it. The figure is a guideline for planning, not a hard contractual quota.

Question 10SRE culture, principles and antipatterns

A service generates hundreds of alerts per shift, and the on-call engineer has started ignoring most of them. Which SRE principle is being violated?

  1. The error budget policy is missing, so nobody knows when to freeze the release pipeline
  2. Alerts are not actionable, so responders cannot tell what decision is needed Correct answer.
  3. Release engineering is immature, so deployments are not gated by progressive rollouts
  4. Capacity planning is being ignored, so the service will eventually run out of headroom entirely

Explanation

Every page should require a human decision and correspond to a symptom users can feel; anything that does not meet that bar belongs in a ticket, a dashboard or an automated remediation. Alert fatigue erodes trust in monitoring so that genuine pages get missed. The remedy is to delete, downgrade or automate non-actionable alerts and alert on symptoms rather than causes.

Question 11SRE culture, principles and antipatterns

A company plans a central team that handles all paging, all deploys and all capacity for every product team. Which antipattern does this recreate?

  1. Operations should own reliability because they are the ones who run the systems day to day
  2. Reliability ownership should sit with a central architecture review board that meets quarterly
  3. The team that builds a service should own its production reliability Correct answer.
  4. This is the recommended SRE engagement model for large organisations with many product teams

Explanation

A central group that absorbs all operational responsibility for everyone else is a siloed operations team under a new name. Ownership of production behaviour should stay with the team that builds the service, with SRE supplying practice, tooling and consultative support. Without that ownership, product teams have little incentive to design for operability.

Question 12SRE culture, principles and antipatterns

What most distinguishes SRE from a traditional system administration role?

  1. SRE teams only work on infrastructure that is written in a modern compiled language
  2. SRE applies software engineering to operations work rather than staffing it Correct answer.
  3. SRE is system administration rebranded, with the same tools and the same staffing model
  4. SREs deliberately avoid writing code so that they stay objective about production behaviour

Explanation

The defining idea is that operational problems should be solved with software: if a task must be done repeatedly, an SRE automates it away instead of growing the team to keep doing it by hand. This is why SRE teams cap toil and treat engineering time as the scarce resource. Writing code is central to the role, not something to avoid.

Question 13SRE culture, principles and antipatterns

Which practice produces the most useful postmortem action items?

  1. Actions should be specific, owned by a person, prioritised and tracked to completion Correct answer.
  2. Only actions that address the single identified root cause should be filed at all
  3. Actions should be recorded but left unassigned so that nobody feels blamed for the outage
  4. Actions should be limited to updating documentation and runbooks for the affected service

Explanation

A postmortem's value is realised only when its actions are concrete, assigned to an owner, prioritised against other work, and tracked until closed. Blamelessness concerns how people are treated during the analysis, not whether work gets an owner. Actions should address contributing factors and detection gaps, not just one narrative cause.

Question 14SRE culture, principles and antipatterns

Why does SRE favour small, frequent releases over large infrequent ones?

  1. Because shipping fewer deploys per year always results in fewer incidents per year
  2. Because very frequent releases remove the need for a team to maintain an error budget at all
  3. Because large releases reduce the total number of rollbacks required
  4. Because small batches limit blast radius, roll back cleanly and localise failure Correct answer.

Explanation

Change is the leading source of outages, so the goal is to make change safe rather than rare. Small batches mean a failure affects fewer users, is easier to attribute to a specific change, and can be reverted quickly. Frequent small releases also exercise the deployment path, so it stays well understood.

Question 15SRE culture, principles and antipatterns

Which alert condition best indicates that a service is consuming its error budget quickly?

  1. The amount of toil the on-call engineer performed while handling recent pages
  2. How fast the service is spending its error budget relative to the SLO window Correct answer.
  3. The number of deployments the team made during the last hour of production traffic
  4. The share of CPU the service consumes during the current measurement window

Explanation

Burn-rate alerting compares the current rate of bad events against the rate that would exactly exhaust the budget over the SLO window. A high burn rate signals that the budget will be gone long before the window ends, which is what should page a human. Resource saturation is a cause signal and only matters insofar as it affects user-facing success.

Question 16SRE culture, principles and antipatterns

An SRE manager proposes ranking engineers by the number of incidents they personally resolve. Why is this harmful?

  1. It is harmful only because incident counts are hard to compute accurately
  2. It encourages hoarding incident response and discourages automation and honest reporting Correct answer.
  3. It is harmful because mean time to repair is never a useful operational metric
  4. It is harmless as long as the resulting individual rankings are kept confidential within the team

Explanation

Rewarding incident handling per person makes it in an individual's interest to keep incidents to themselves and to avoid the automation that would remove them. It also pushes people to hide mistakes, which destroys the evidence blameless review depends on. Reliability metrics should describe the system and the team's overall ability to deliver, not rank individuals.

Question 17SRE culture, principles and antipatterns

Why do mature SRE organisations analyse near misses and 'lucky saves', not just incidents that harmed customers?

  1. Because near misses can be discussed informally, without the formality of a full postmortem
  2. Because near misses are cheaper to document than incidents that reached customers
  3. Because they expose the same latent weaknesses before customers are harmed Correct answer.
  4. Because near misses count against the error budget and must be reconciled each quarter

Explanation

A near miss is evidence that the system contained a hazard and only chance prevented harm, so the underlying weakness is identical to the one an outage would reveal. Learning from it lets the organisation fix conditions before they cost users. Restricting analysis to incidents that caused damage leaves the same failure waiting for a worse roll of the dice.

Question 18SRE culture, principles and antipatterns

What does the SRE principle of 'embracing risk' actually mean?

  1. Because reliability trades off against speed and cost, so a target level is chosen deliberately Correct answer.
  2. Because teams should take on riskier changes in order to learn faster from the results
  3. Because all risk in production should be transferred to the security and compliance teams
  4. Because outages are unavoidable in distributed systems, so teams should stop investigating their underlying causes

Explanation

SRE treats 100% reliability as the wrong goal because it makes the product unusable: no release can be safe if any failure is unacceptable. Instead, the team chooses a target reliability level that users are happy with and manages the permitted unreliability through the error budget. Risk is therefore quantified and spent, not denied or ignored.

Question 19SRE culture, principles and antipatterns

What is the purpose of a production readiness review?

  1. To approve the marketing launch date that the product team has already announced publicly
  2. To verify monitoring, SLOs, capacity, rollback and on-call exist before real traffic Correct answer.
  3. To audit the service source code for known security vulnerabilities before it is released
  4. To estimate the running cost of the service so finance can budget for it

Explanation

A readiness review is a structured check that a service has the operational fundamentals in place before it takes production traffic: SLOs and monitoring, capacity headroom, rollback and rollout mechanisms, an on-call rotation, runbooks and dependency awareness. Catching these gaps at launch is far cheaper than discovering them during the first incident. It is a collaborative gate, not a substitute for security review or budgeting.

Question 20SRE culture, principles and antipatterns

Which of these is a recognised SRE antipattern?

  1. Adding headcount to absorb growing manual operational work instead of automating it Correct answer.
  2. Automating repetitive operational tasks instead of hiring more people to perform them by hand
  3. Defining SLOs and error budgets before a service is exposed to real traffic
  4. Reviewing incidents with a blameless postmortem that produces owned action items

Explanation

Operational work that grows with the service must be engineered away; hiring to keep pace with it produces linear cost growth and eventually outruns any feasible team size. This is the staffing antipattern that SRE's toil cap and automation focus are designed to prevent. Defining SLOs early and holding blameless reviews are recommended practices, not antipatterns.

Question 21SRE culture, principles and antipatterns

In a postmortem, why is the search for a single 'root cause' often criticised?

  1. Root-cause analysis should be replaced entirely by counting incidents per severity tier
  2. Complex systems fail from many factors; single root causes hide systemic weakness Correct answer.
  3. Postmortems should list every conceivable cause, regardless of the evidence available
  4. A single root-cause analysis is the only reliable way to prevent a failure from recurring

Explanation

Failures in distributed systems typically emerge from a combination of technical and organisational contributing factors, none of which alone would have caused the incident. Declaring one root cause lets everyone stop at the first plausible answer and often slides into blaming the person closest to the change. Good postmortems map the contributing factors and address several of them.

Question 22SRE culture, principles and antipatterns

What does 'blameless' mean in a blameless postmortem culture?

  1. It means postmortems are written only for the most severe customer-facing incidents
  2. It means nobody is ever responsible for any action or outcome after an incident
  3. It means the write-up is kept private so that no team is embarrassed publicly
  4. It means people report mistakes safely while the organisation still fixes causes Correct answer.

Explanation

Blamelessness is an assumption about people, not an absence of accountability: engineers are treated as acting reasonably given the information they had, so they can describe events candidly. The organisation remains fully accountable for correcting the conditions that made the error possible. Confusing this with 'no consequences for anyone' is a common misreading.

Question 23SRE culture, principles and antipatterns

A team finishes the quarter having spent only a small fraction of its error budget. What does SRE practice suggest?

  1. Nothing; it suggests the SLO is too loose, so tighten it or take more risk Correct answer.
  2. The surplus should roll over automatically and double the next quarter's error budget allowance
  3. The team should stop all releases until the remaining budget has been consumed
  4. The team should reduce its SLO target toward zero to save engineering effort

Explanation

A persistently unspent budget usually means the reliability target is stricter than users need, so the team is paying for reliability it does not have to. The response is either to tighten the SLO so the budget is meaningful, or to use the headroom for faster releases and experiments. An error budget that is never at risk is not informing any decision.

Question 24SRE culture, principles and antipatterns

An SRE team is asked to own, operate and page for every service in the company. Which engagement model does SRE practice recommend instead?

  1. The team builds self-service platforms and embedded or consultative support that product teams adopt Correct answer.
  2. The team hires enough engineers to keep absorbing services until coverage is complete
  3. The team takes ownership only of the services that currently generate the most alerts
  4. The team delegates all production support to a vendor and retains only advisory duties

Explanation

SRE scales through leverage: reusable platforms, tooling, SLO guidance and embedded or consulting engagement that helps product teams run their own services well. Absorbing every service rebuilds a central operations silo whose capacity grows linearly with the estate. Ownership of production behaviour stays with the building team.

Question 25Organizational impact of adopting SRE

Which statement best defines an error budget?

  1. The unreliability a service may accrue within its SLO window before work shifts to reliability. Correct answer.
  2. The money reserved each quarter to pay for monitoring and incident tooling.
  3. The maximum number of production changes a team may ship per release.
  4. The number of engineers permitted to serve on call in a given week.

Explanation

An error budget is the complement of an SLO: if the target is 99.9% over 30 days, roughly 0.1% of requests may fail. It converts an abstract target into a concrete allowance that governs how much risk the team may spend on change.

Question 26Organizational impact of adopting SRE

Which best describes toil as SRE defines it?

  1. Manual, repetitive, automatable work that grows with the service and adds no lasting value. Correct answer.
  2. Work performed outside business hours by members of the rotation.
  3. Forward-looking work such as capacity modeling and SLO review.
  4. Deep investigation of a novel failure that engineers find engaging and that produces lasting knowledge.

Explanation

Toil is characterized by being manual, repetitive, automatable, tactical, devoid of enduring value, and scaling linearly with service growth. Tracking toil explicitly is what makes the case for automating it.

Question 27Organizational impact of adopting SRE

SRE is often described as a concrete implementation of DevOps principles because it:

  1. Requires a separate operations department reporting outside engineering.
  2. Eliminates the need for any on-call rotation.
  3. Uses engineering and error budgets to balance change velocity with stability. Correct answer.
  4. Replaces operations staff entirely by giving developers full production control.

Explanation

DevOps describes the cultural and organizational goal of shared ownership and fast flow; SRE supplies mechanisms such as SLOs, error budgets, and blameless postmortems that make the goal operational.

Question 28Organizational impact of adopting SRE

Why does SRE guidance cap operational work at roughly 50% of an SRE team's time?

  1. Because sustained overload consumes the capacity needed for automation and drives attrition. Correct answer.
  2. Because it guarantees SREs never need to join an on-call rotation.
  3. Because operations work is billed internally at a lower rate than project work.
  4. Because employment regulation limits after-hours work in most jurisdictions.

Explanation

If operational load keeps growing, the team spends all its time on tickets, cannot build the automation that would reduce load, and burns out. The cap forces a choice: fund the team to keep up, or stop taking on work that outpaces it.

Question 29Organizational impact of adopting SRE

A service exhausts its quarterly error budget two-thirds of the way through the quarter. Under a typical error budget policy, what should happen?

  1. Product managers join the on-call rotation for the remainder of the quarter.
  2. Non-essential releases pause and the team works on reliability until budget recovers. Correct answer.
  3. The service is deprecated and its users migrated to a vendor.
  4. The SLO target is lowered so that current performance counts as compliant.

Explanation

An error budget policy is a pre-agreed consequence that removes the negotiation from the moment of crisis. When the budget is spent, risky change is curtailed and reliability work takes priority until the service is back within target.

Question 30Organizational impact of adopting SRE

Which statement best reflects a mature blameless culture?

  1. Individuals are never held to any performance or process standard after an incident, because blame of any kind is prohibited.
  2. People own following agreed process and surfacing what they know, while incidents are analyzed systemically. Correct answer.
  3. Postmortems omit the names of everyone involved so that no one can be identified.
  4. Only managers are permitted to author postmortems and their action items.

Explanation

Blamelessness removes punishment for honest mistakes and information sharing; it does not remove accountability for agreed practice. Organizations separate the question of system causes from the question of whether people followed the process they committed to.

Question 31Organizational impact of adopting SRE

Why does psychological safety improve reliability outcomes?

  1. It lets people report near misses and own mistakes, so failure information surfaces and gets fixed. Correct answer.
  2. It allows on-call rotations to be staffed with fewer engineers.
  3. It removes the need for monitoring and alerting on production systems.
  4. It guarantees that a service will not experience repeated incidents.

Explanation

Reliability improves when problems are disclosed early and accurately; fear of punishment causes people to hide or soften failure information. Psychological safety is therefore an input to detection and learning, not a substitute for technical controls.

Question 32Organizational impact of adopting SRE

In an embedded SRE model, SREs typically:

  1. Join product teams to transfer reliability practices, often with a plan to hand off. Correct answer.
  2. Sit in a central team and never interact directly with product engineers.
  3. Handle only security incidents and compliance reviews.
  4. Own every line of production code written by the product team.

Explanation

Embedding places SREs alongside product engineers so reliability habits spread into the team that owns the service. The intent is usually to build capability in the product team rather than to create a permanent dependency.

Question 33Organizational impact of adopting SRE

What does the \"wall of confusion\" describe in an organization?

  1. A monitoring dashboard that fires far more alerts than the team can realistically act on during a shift.
  2. A split where development is rewarded for change and operations for stability, producing handoffs and blame. Correct answer.
  3. The gap between published SLO targets and measured production latency.
  4. A network partition between two data centers during a failover test.

Explanation

The wall of confusion arises from misaligned incentives: one group is measured on shipping change, the other on preventing it. Handoffs across that boundary create blame and slow recovery until ownership is shared.

Question 34Organizational impact of adopting SRE

How does assigning an incident commander during a major incident help an organization?

  1. It reduces responders to a single engineer who does all the work.
  2. It ensures the most senior executive makes all technical decisions.
  3. It replaces the postmortem with a live root-cause analysis.
  4. One person coordinates and decides, freeing others to investigate and communicate. Correct answer.

Explanation

A declared commander creates a single coordination point so responders are not simultaneously negotiating authority and debugging. Clear roles shorten incidents and reduce the confusion that worsens them.

Question 35Organizational impact of adopting SRE

A product team argues that SLOs are purely an SRE concern. What is the best organizational response?

  1. Move SLO definition to the finance team that funds the service.
  2. Drop SLOs and rely on infrastructure uptime monitoring instead.
  3. Make SLOs a shared agreement, with the service owner accountable for the target and its consequences. Correct answer.
  4. SREs set all SLOs unilaterally so targets stay objective.

Explanation

SLOs only change behavior when the team that ships changes owns the target and the error budget policy attached to it. SREs supply method and tooling, but accountability has to sit with the service owners.

Question 36Organizational impact of adopting SRE

An SRE team spends about 70% of its time on repetitive ticket handling. Which response best fits SRE practice?

  1. Hire enough people to absorb the tickets at the current ratio.
  2. Transfer the queue to another team and consider the toil resolved.
  3. Reserve capacity each cycle to automate the highest-volume toil and track the reduction. Correct answer.
  4. Lower the SLO targets so fewer tickets are generated.

Explanation

Toil is addressed by engineering it away and measuring the reduction, which requires protected capacity rather than hoping for spare time. Growing the team in proportion to toil preserves the problem instead of solving it.

Question 37Organizational impact of adopting SRE

Which set of indicators best shows organizational SRE adoption rather than team busyness?

  1. Number of dashboards built, alerts configured, and tools evaluated.
  2. SLO coverage that changes decisions, error budget enforcement, toil trend, and postmortem action closure. Correct answer.
  3. Count of SRE job titles, conference talks, and internal blog posts.
  4. Weekly page volume across all services and mean time to acknowledge.

Explanation

Adoption shows up in behavior: SLOs actually influence releases, budgets are enforced, toil falls, and postmortem actions are completed. Activity counts such as dashboards or job titles can rise without any change in how decisions are made.

Question 38Organizational impact of adopting SRE

Why is executive sponsorship so important when an organization adopts SRE?

  1. Monitoring and incident tooling can only be purchased at the executive level.
  2. Error budget policies trade delivery against stability, and that trade needs authority above individual team goals. Correct answer.
  3. Executives are the only employees qualified to author postmortems.
  4. Executives must personally participate in every on-call rotation.

Explanation

Error budgets and release freezes force explicit trade-offs between shipping and stability, which individual teams cannot make alone when their goals reward only delivery. Sponsorship at a level above those goals is what makes the policy stick.

Question 39Organizational impact of adopting SRE

A team proposes 99.999% availability for an internal tool used only during business hours. What is the soundest reasoning?

  1. Targets should follow user needs and cost, with each added nine justified against velocity and spend. Correct answer.
  2. Higher availability is always better, so the target should be raised.
  3. The monitoring vendor's recommended threshold should set the target.
  4. The industry default of 99.9% should be adopted without further discussion.

Explanation

Each additional nine typically multiplies cost and constrains change velocity, so a target should be derived from what users actually need and what the organization is willing to fund. Internal tools with limited usage windows usually need far less than five nines.

Question 40Organizational impact of adopting SRE

Postmortems repeatedly list action items that are never completed. Which organizational change addresses the cause?

  1. Stop recording action items and rely on engineers to remember.
  2. Track actions in the product backlog with named owners and dates, and review closure publicly. Correct answer.
  3. Hold the on-call engineer personally responsible for every action item.
  4. Require longer postmortems with more narrative detail.

Explanation

Action items stall when they live outside the planning system that allocates real capacity. Giving each item an owner, a date, and a visible place in the backlog turns learning into funded work.

Question 41Organizational impact of adopting SRE

Which profile best matches what organizations typically seek when hiring SREs?

  1. Software engineering ability plus systems depth and calm debugging under uncertainty. Correct answer.
  2. Marketing analytics experience with dashboarding tools and no production exposure.
  3. A project management certification and no exposure to running production systems.
  4. Helpdesk ticket triage experience only, with no software engineering or coding background at all.

Explanation

SRE work combines writing software with understanding distributed systems and diagnosing failures under pressure. Hiring purely for ticket triage or purely for project management leaves the team unable to automate or debug.

Question 42Organizational impact of adopting SRE

How do game days and controlled chaos experiments most affect an organization?

  1. They allow incident response processes to be retired.
  2. They build shared confidence and reveal gaps while blast radius is limited. Correct answer.
  3. They transfer reliability responsibility to an external vendor.
  4. They identify which engineer is at fault when systems break.

Explanation

Practicing failure in a bounded way gives teams evidence that detection and response actually work, and it exposes weaknesses while the cost of failure is small. The organizational benefit is trust and preparedness, not blame.

Question 43Organizational impact of adopting SRE

A 30-person startup cannot staff a dedicated SRE team. What is the most realistic adoption path?

  1. Adopt a minimal set of practices-SLOs for key journeys, light postmortems, toil tracking-owned by existing teams. Correct answer.
  2. Defer all reliability work until headcount justifies a dedicated SRE organization.
  3. Immediately hire ten SREs regardless of budget or workload.
  4. Outsource production ownership entirely and stop monitoring internal services.

Explanation

The practices matter more than the job title: a small organization can start with SLOs on critical user journeys, brief blameless postmortems, and explicit toil tracking inside existing teams. This builds the habits that a later dedicated function would otherwise have to install from scratch.

Question 44Organizational impact of adopting SRE

Which practice most directly reduces on-call burnout?

  1. Assign the rotation permanently to the two most experienced engineers.
  2. Increase page volume so engineers stay alert throughout the shift.
  3. Remove runbooks so responders reason from first principles.
  4. Page only on actionable symptoms, fix the cause of each page, and compensate on-call fairly. Correct answer.

Explanation

Burnout is driven by useless interruptions, unrewarded after-hours work, and pages that never get fixed. Making pages actionable, eliminating their causes, and paying for on-call time addresses all three drivers.

Question 45Organizational impact of adopting SRE

Which cultural shift is most central to adopting SRE?

  1. Measuring engineering success by ticket closure counts.
  2. Moving from 'ops owns production' to shared ownership with developers carrying pager duty. Correct answer.
  3. Freezing production changes until reliability is perfect.
  4. Treating operations as a separate cost center with its own budget.

Explanation

SRE depends on the people who write the software also being responsible for how it behaves in production. Shared ownership aligns incentives so reliability is designed in rather than inspected in afterwards.

Question 46SLIs, SLOs and error budgets in a distributed ecosystem

Which of the following best describes a service level indicator (SLI)?

  1. A contractual document that defines credits for missed targets
  2. A quantitative measure of service behavior seen by users Correct answer.
  3. A capacity forecast used to plan the next hardware refresh
  4. A deployment gate that blocks releases when tests fail

Explanation

An SLI is a measurement, such as the proportion of requests served under a latency threshold, computed from telemetry and expressed as good events over valid events. It is the raw input from which an SLO target is set.

Question 47SLIs, SLOs and error budgets in a distributed ecosystem

A service has a 30-day availability SLO of 99.9%. How much total unavailability does the error budget allow?

  1. 4.32 minutes
  2. 432 minutes
  3. 43.2 minutes Correct answer.
  4. 4.32 hours

Explanation

Thirty days is 43,200 minutes. A 99.9% target tolerates 0.1% unavailability, and 0.1% of 43,200 minutes is 43.2 minutes.

Question 48SLIs, SLOs and error budgets in a distributed ecosystem

Which statement correctly distinguishes an SLO from an SLA?

  1. An SLO is measured by users while an SLA is measured by operators
  2. An SLO covers only availability while an SLA covers latency and throughput
  3. An SLO is an internal target; an SLA is a contract with consequences Correct answer.
  4. An SLO is legally enforceable while an SLA is only an internal guideline

Explanation

An SLO is an internal reliability target derived from what users need and is typically stricter than any external commitment. An SLA is a commercial agreement that specifies what happens, usually credits, when commitments are missed.

Question 49SLIs, SLOs and error budgets in a distributed ecosystem

How is an error budget expressed for a service with an SLO target?

  1. SLO target times total valid events
  2. Valid events minus failed events
  3. Valid events divided by the sum of failed and retried events
  4. One minus the SLO target, applied to valid events Correct answer.

Explanation

The error budget is the complement of the SLO target: a 99.9% target permits 0.1% of valid events to be bad. Multiplying that fraction by the volume of valid events gives the number of failures the period allows.

Question 50SLIs, SLOs and error budgets in a distributed ecosystem

Under a typical error budget policy, what happens once a service has exhausted its error budget for the period?

  1. The SLO target is raised so that the budget is replenished
  2. Non-essential releases are frozen until reliability improves Correct answer.
  3. Monitoring is paused until the next measurement window starts
  4. The measurement window is shortened so the impact looks smaller

Explanation

An error budget policy converts a measurement into an agreed consequence: when the budget is spent, the team prioritizes reliability work and pauses risky changes. The freeze lifts when the budget recovers or an explicit exception is agreed.