I85PREP
⌘ K
SRE Foundation study materials
SRE Foundation study resources

SRE Foundation practice questions

One question at a time. Build your SRE Foundation 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 Principles and Practices

In SRE, what is a service level indicator (SLI)?

  1. A step-by-step procedure an on-call engineer follows when a paging alert fires
  2. A quantitative measure of an aspect of service behavior, such as latency or error rate Correct answer.
  3. A contractual commitment to customers that specifies penalties when availability targets are missed
  4. A quarterly target that defines how much unreliability the team is allowed to spend

Explanation

An SLI is the measurement itself, ideally expressed as a ratio of good events to valid events (for example, successful requests divided by all requests). Targets placed on that measurement are SLOs, and contractual versions of those targets are SLAs.

Question 2SRE Principles and Practices

What does an error budget represent for a service with a defined SLO?

  1. The amount of unreliability a service may have within its SLO window Correct answer.
  2. Spare capacity kept idle so that traffic spikes do not degrade reliability
  3. The maximum number of incidents a team may declare in a quarter
  4. The sum of refunds paid to customers after a service disruption

Explanation

The error budget is simply 100% minus the SLO target, expressed over the SLO window; a 99.9% monthly SLO leaves 0.1% of the month's valid events available for failure. It converts an abstract reliability target into a quantity teams can spend, track, and run down.

Question 3SRE Principles and Practices

Which task is the clearest example of toil?

  1. Manually running the same three recovery commands every morning Correct answer.
  2. Reviewing a colleague's change to a set of alerting thresholds
  3. Writing a postmortem for an outage that no existing runbook covered
  4. Designing a capacity model for next year's expected traffic growth

Explanation

Toil is work that is manual, repetitive, automatable, tactical, and does not permanently improve the service. Running the same recovery commands each day meets all of those criteria, so the right response is automation rather than disciplined repetition.

Question 4SRE Principles and Practices

What is the primary purpose of a blameless postmortem?

  1. To satisfy audit requirements that every production incident be formally documented
  2. To identify which engineer made the mistake so it can be noted in their performance review
  3. To understand how the system allowed the failure and prevent recurrence Correct answer.
  4. To negotiate a revised SLA with the affected customer after an outage

Explanation

Blameless postmortems assume people act reasonably given the information they had, and focus on the technical and organizational conditions that let an error become an outage. The output is a set of systemic fixes and shared learning, not individual accountability.

Question 5SRE Principles and Practices

Which set of signals is commonly recommended as the four golden signals for monitoring a user-facing service?

  1. Requests, responses, retries, and timeouts
  2. Latency, traffic, errors, and saturation Correct answer.
  3. CPU, memory, disk, and network utilization
  4. Availability, durability, cost, and throughput

Explanation

The four golden signals describe how users experience a service: how long requests take, how many arrive, how many fail, and how close the service is to its capacity limits. They are preferred over raw resource counters because they map directly to user-visible behavior.

Question 6SRE Principles and Practices

How is site reliability engineering commonly described in relation to DevOps?

  1. A concrete implementation of DevOps principles using software engineering practices Correct answer.
  2. A replacement for DevOps that drops its emphasis on automation
  3. A separate discipline that applies only to companies operating public clouds
  4. A customer support function that handles escalations from the operations team

Explanation

SRE shares DevOps goals such as reducing silos, automating delivery, and measuring outcomes, and supplies specific mechanisms, notably SLOs, error budgets, and toil limits. It is often characterized as a prescriptive way to practice DevOps rather than a competing philosophy.

Question 7SRE Principles and Practices

Why do SRE teams generally treat 100% availability as the wrong target?

  1. Because past a point, extra reliability costs more than users can perceive or value Correct answer.
  2. Because service level objectives are conventionally capped at three nines
  3. Because monitoring tools cannot reliably measure availability above 99.99%
  4. Because customers always prefer lower cost over higher reliability

Explanation

Reliability beyond what users can distinguish and what the product needs consumes engineering effort that would otherwise fund features, and it can slow change delivery. Choosing a target slightly below the theoretical maximum keeps releases flowing while still protecting users.

Question 8SRE Principles and Practices

SRE guidance commonly suggests that operational work, including toil and on-call interrupts, be capped at what share of an SRE team's time?

  1. 75%
  2. 25%
  3. 10%
  4. 50% Correct answer.

Explanation

The widely used guideline is that SREs should spend no more than half their time on operational work, leaving the rest for engineering that improves reliability and reduces future operational load. Exceeding the cap signals that either toil must be automated away or some operational work should be returned to the owning development team.

Question 9SRE Principles and Practices

A service has a 99.9% monthly availability SLO. In the first week of the month the team has already spent 90% of the error budget. Under a typical error budget policy, what should happen?

  1. Nothing changes, because the budget is only assessed at the end of the window
  2. The SLO is relaxed to 99% so that the remaining budget is larger
  3. Feature releases are frozen until the service is back within budget Correct answer.
  4. The on-call rotation is doubled so problems are caught faster

Explanation

An error budget policy pre-agrees what happens when the budget is nearly or fully spent, and the usual consequence is to halt feature releases and redirect effort to reliability. The policy is written in advance precisely so it is not renegotiated during a stressful period.

Question 10SRE Principles and Practices

An alert fires when a service burns its 30-day error budget at many times the sustainable rate over a short window, while a companion longer window catches slower degradation. What does this multiwindow, multi-burn-rate alerting approach provide?

  1. Fast detection of severe outages alongside detection of slow burns Correct answer.
  2. An automatic reduction of the error budget to zero when the alert fires
  3. A guarantee that the SLO will be met regardless of traffic volume
  4. Elimination of the need for dashboards and structured logs

Explanation

Burn rate expresses how fast the budget is being consumed relative to the rate that would exactly exhaust it over the SLO window. Pairing a short, high-threshold window with a longer, lower-threshold window gives both rapid paging for severe incidents and coverage of gradual drift, while reducing noise.

Question 11SRE Principles and Practices

Which statement best distinguishes monitoring from observability?

  1. Observability replaces monitoring once distributed tracing has been deployed
  2. Monitoring is for infrastructure while observability applies only to applications
  3. Monitoring gathers metrics while observability gathers logs and traces exclusively
  4. Monitoring answers known questions; observability supports asking new ones Correct answer.

Explanation

Monitoring tracks predefined conditions that teams already expect to matter, such as a threshold on error rate. Observability is the property of a system whose rich, high-cardinality telemetry lets engineers interrogate novel failure modes they did not anticipate.

Question 12SRE Principles and Practices

In a progressive rollout, what is the role of a canary release?

  1. To freeze all further changes until the change is fully documented
  2. To run the new version against production-like data in a staging environment
  3. To expose a small slice of traffic to the change and compare its SLIs to baseline Correct answer.
  4. To deploy the change to a random half of users and leave it there

Explanation

A canary limits the blast radius of a change by sending a small fraction of real traffic to the new version while its health indicators are compared against the stable version. If the canary's SLIs degrade, the rollout is aborted before most users are affected.

Question 13SRE Principles and Practices

During a large incident, why does SRE practice separate the incident commander role from the hands-on debugging role?

  1. So postmortem assignments can be issued before the incident is resolved
  2. So one person keeps the overall picture, coordinates responders, and communicates Correct answer.
  3. So the responder who finds the root cause is not named in the record
  4. So the commander can approve budget spend for the remediation work

Explanation

Incident command separates coordination from investigation so that someone maintains situational awareness, assigns work, and keeps stakeholders informed while others focus deeply on diagnosis. Mixing both duties in one person typically degrades both communication and technical progress.

Question 14SRE Principles and Practices

A team reduces mean time to repair while leaving the failure frequency unchanged. What is the direct effect on availability, computed as uptime divided by total time?

  1. Availability is unchanged because the number of failures stays the same
  2. Availability improves because each failure removes less service time Correct answer.
  3. Availability depends only on failure frequency, not on repair duration
  4. Availability gets worse because repairs are performed under time pressure

Explanation

Availability is a function of both how often the service fails and how long each failure lasts. Shortening the repair phase reduces total downtime accumulated across the same number of incidents, so availability rises.

Question 15SRE Principles and Practices

Which postmortem action item is most likely to actually reduce recurrence of the incident?

  1. Remind the team to be more careful when running database migrations
  2. Make the migration tool block when replication lag is high Correct answer.
  3. Add a description of the outage to the team's onboarding wiki
  4. Schedule a recurring meeting to discuss migration safety

Explanation

Effective action items change the system so the dangerous path is blocked or detected automatically, rather than relying on memory or intention. A guardrail in the tooling removes the dependence on human vigilance at the moment of risk.

Question 16SRE Principles and Practices

A service runs across three zones and is designed to keep serving if one zone is lost. What does this typically require of the remaining zones?

  1. Nothing extra, because the load balancer redistributes traffic automatically
  2. That each zone normally run at 100% utilization to avoid waste
  3. That the two surviving zones together absorb the full regional load Correct answer.
  4. That the region keep a fourth zone powered off but ready to start

Explanation

Surviving a zone loss means the remaining capacity must carry the whole workload, so each zone is normally run well below full utilization. This headroom is the practical expression of N+1 provisioning within the failure domain.

Question 17SRE Principles and Practices

What is the purpose of a production readiness review before launching a new service?

  1. To confirm the service meets agreed reliability and operability standards Correct answer.
  2. To approve the marketing launch date and pricing for the new service
  3. To assign a dedicated on-call engineer for the service's first year
  4. To verify that the service's source code passes the security scanner

Explanation

A production readiness review checks a service against an agreed checklist covering SLOs, monitoring, alerting, capacity, runbooks, and ownership before real users depend on it. The goal is to surface operability gaps while they are still cheap to fix.

Question 18SRE Principles and Practices

Which paging alert best fits SRE alerting philosophy?

  1. A disk has reported a predictive failure warning in its health log
  2. The share of successful requests has dropped below the SLO burn threshold Correct answer.
  3. CPU utilization on any node has exceeded 80% for five minutes
  4. The deployment pipeline queue has grown beyond ten pending jobs

Explanation

SRE alerting favors symptoms that users actually experience, because those are what the SLO protects and what require human intervention. Cause-based signals are better used for dashboards or tickets unless they reliably predict imminent user impact.

Question 19SRE Principles and Practices

A team spends several hours each week manually approving certificate renewals. Which response best fits SRE discipline?

  1. Add the task to the on-call runbook so it is performed consistently
  2. Rotate the approval duty among team members so the load is shared
  3. Automate the renewal and approval so the task disappears Correct answer.
  4. Record the hours in a spreadsheet and report them monthly to management

Explanation

Repetitive manual work that can be automated is toil, and the SRE response is to engineer it away rather than distribute or document it. Removing the task permanently frees capacity for reliability engineering and eliminates a source of human error.

Question 20SRE Principles and Practices

Why does SRE practice favor many small, frequent releases over a few large ones?

  1. Small changes limit blast radius and are easier to diagnose and roll back Correct answer.
  2. Large releases cannot be reviewed for security issues in any practical way
  3. Frequent releases remove the need for monitoring immediately after deployment
  4. Small releases are cheaper because they need less testing before deployment

Explanation

Batching changes increases the number of possible interactions and makes attributing a regression to a specific change difficult. Smaller, more frequent changes keep the set of candidate causes narrow, reduce the impact if something is wrong, and make reverting straightforward.

Question 21SRE Principles and Practices

A service's 30-day error budget is completely consumed in 2.5 days. What burn rate does this represent?

  1. 12x Correct answer.
  2. 0.08x
  3. 30x
  4. 2.5x

Explanation

Burn rate is the ratio of the observed consumption rate to the rate that would exhaust the budget exactly over the SLO window. Consuming the full budget in 2.5 days out of a 30-day window is 30 divided by 2.5, which equals 12 times the sustainable rate.

Question 22SRE Principles and Practices

Which SLI definition is best practice for a request-driven service?

  1. The median server-side latency, sampled once per minute
  2. The proportion of valid requests served faster than 300 ms Correct answer.
  3. The count of 5xx responses the service returns each hour
  4. The average latency of all requests, measured at the client

Explanation

Good SLIs are ratios of good events to valid events with an explicit threshold, measured as close to the user as practical. Expressing latency as the fraction of requests under a bound yields a number that maps directly to an SLO and is not distorted by a long tail.

Question 23SRE Principles and Practices

A service is given a 99.99% SLO even though users cannot tell it apart from 99.9%. What is the most likely consequence?

  1. Engineers will spend effort on reliability that users do not perceive Correct answer.
  2. The error budget will grow because the target has been raised
  3. Users will migrate to a competitor that publishes a stricter target
  4. The service will require fewer on-call engineers to operate

Explanation

Reliability targets should be set from what users need and can notice, because each additional nine typically costs progressively more engineering effort. Overshooting that point diverts capacity from features and slows delivery without any perceptible benefit.

Question 24SRE Principles and Practices

Why do SREs often prefer tail latency percentiles over mean latency when defining a latency SLI?

  1. Percentiles are cheaper to compute than averages at high request volume
  2. Averages are more sensitive to clock skew between servers
  3. A mean hides the slow requests that a meaningful share of users experience Correct answer.
  4. Percentiles remove the need to define any latency threshold

Explanation

A single slow request class can be invisible in the mean while disproportionately affecting real sessions, since a user page may require many calls and any one of them can be slow. Tail percentiles, or better a thresholded good-events ratio, expose that experience directly.

Question 25SRE Principles and Practices

What should be established before running a chaos experiment against production?

  1. A complete copy of production traffic replayed into a staging cluster
  2. A rollback that removes the chaos tooling from the deployment pipeline
  3. A measurable steady-state definition of normal behavior and a way to abort Correct answer.
  4. Written sign-off from every team that owns a downstream dependency

Explanation

Chaos engineering is a controlled experiment: it starts from a hypothesis about a measurable steady state, injects a realistic fault with a bounded blast radius, and compares the outcome against that baseline. A pre-arranged abort condition limits damage if the system behaves worse than expected.

Question 26Service Level Objectives and Error Budgets

Which statement best describes a service level indicator (SLI)?

  1. A dashboard that plots latency and error graphs
  2. A contractual commitment to customers with penalties attached
  3. The maximum number of errors allowed in a calendar year
  4. A quantitative measure of the level of service delivered Correct answer.

Explanation

An SLI is a carefully defined quantitative measure of some aspect of the level of service, such as the proportion of requests served successfully or within a latency threshold. It is the raw measurement, and targets, contracts and visualisations are all built on top of it.

Question 27Service Level Objectives and Error Budgets

An SLO is best described as which of the following?

  1. A legally binding promise of uptime made to paying customers
  2. A logging strategy used to detect outages automatically
  3. A record of the service configuration at deploy time
  4. A target value or range for an SLI over a time window Correct answer.

Explanation

An SLO states the target level for an SLI, for example 99.9 percent of valid requests succeeding over a rolling 28-day window. The target and the window together make the objective measurable and comparable against actual performance.

Question 28Service Level Objectives and Error Budgets

How does a service level agreement (SLA) relate to service level objectives?

  1. They are two names for the same internal engineering target
  2. A contract with consequences if service levels are missed Correct answer.
  3. An SLA is computed from the error budget, an SLO is not
  4. An SLA is always stricter than any SLO and set at 100 percent

Explanation

An SLA is a business contract, usually with customers, that specifies what happens when service levels are missed, such as refunds or penalties. SLOs are internal targets and are normally set stricter than anything promised externally so the SLA is rarely breached.

Question 29Service Level Objectives and Error Budgets

For an availability SLO of 99.9 percent, what is the error budget?

  1. The spare capacity remaining before the service must scale
  2. The share of the window during which alerts are suppressed
  3. The number of nines expressed as a percentage
  4. The 0.1 percent of events allowed to fail in the window Correct answer.

Explanation

The error budget is the complement of the SLO: 100 percent minus 99.9 percent leaves 0.1 percent of valid events that may fail within the measurement window. That allowance is what the team is permitted to spend on risk.

Question 30Service Level Objectives and Error Budgets

An SLO of 99.9 percent availability applies over a 30-day window. Roughly how much unavailability does the error budget allow?

  1. About 43 minutes Correct answer.
  2. About 432 minutes
  3. About 4 minutes
  4. About 7 hours

Explanation

Thirty days is 43,200 minutes, and 0.1 percent of that is 43.2 minutes. The error budget therefore permits roughly three quarters of an hour of unavailability across the month.

Question 31Service Level Objectives and Error Budgets

Why do SRE teams generally avoid setting an SLO of 100 percent?

  1. Because monitors cannot measure availability above 99 percent
  2. Because its cost outweighs the benefit to users Correct answer.
  3. Because error budgets cannot be defined for that target
  4. Because 100 percent targets are prohibited in service contracts

Explanation

Each additional nine typically demands far more engineering effort than users can perceive as improvement, so the last fraction of reliability is a poor investment. Leaving some headroom also allows safe releases and tolerates occasional failures in dependent infrastructure.

Question 32Service Level Objectives and Error Budgets

A request-based availability SLI is normally computed as which ratio?

  1. Failed requests minus successful requests
  2. Good events divided by valid events Correct answer.
  3. The mean latency of the slowest one percent
  4. Total requests divided by failed requests

Explanation

SLIs are expressed as a proportion of good events to valid events, for example successful requests divided by all legitimate requests. The ratio produces a value between zero and one that can be compared directly with the SLO target.

Question 33Service Level Objectives and Error Budgets

In day-to-day practice, what does the error budget give a product team?

  1. A guarantee that customers will never notice an outage
  2. A ceiling on the number of features that may launch each quarter
  3. A replacement for writing postmortems after incidents
  4. A quantified allowance of unreliability to spend on risk Correct answer.

Explanation

The budget converts the SLO into an amount of failure the team may spend, for example on deployments, experiments or infrastructure changes. It lets reliability trade-offs be settled with numbers rather than opinions.

Question 34Service Level Objectives and Error Budgets

Which description matches the error budget burn rate?

  1. The ratio of successful requests to total valid requests
  2. How fast the budget is spent relative to the SLO window Correct answer.
  3. The number of incidents opened against the service each week
  4. The percentage of requests that fail during the current hour

Explanation

Burn rate normalises budget consumption: a burn rate of 1 spends the budget at exactly the pace that exhausts it at the end of the SLO window. A rate of 2 would exhaust the budget in half the window.

Question 35Service Level Objectives and Error Budgets

Why do teams often alert on burn rate instead of on a fixed instantaneous error rate?

  1. Because error rates cannot be computed over short windows
  2. Because it reflects how soon the budget will be exhausted Correct answer.
  3. Because burn rate removes the need for any alert thresholds
  4. Because burn rate alerts do not require an SLO to be defined in advance

Explanation

Burn rate ties alerting urgency to the SLO: a high rate means the budget will run out soon, whether the cause is a fast outage or a slow persistent fault. A fixed error-rate threshold either misses the slow burn or fires noisily on harmless spikes.

Question 36Service Level Objectives and Error Budgets

Which statement about a rolling SLO window is accurate?

  1. It is fixed at exactly 28 days for every service
  2. It always covers the entire lifetime of the service
  3. Older data continuously drops out of the measured period Correct answer.
  4. It resets the error budget on the first day of each month

Explanation

A rolling window moves with time, so each new measurement enters the window while the oldest measurements leave it. This gives continuous feedback and avoids the abrupt budget resets that a calendar window produces.

Question 37Service Level Objectives and Error Budgets

Why is a percentile latency SLI usually preferred over mean latency?

  1. Percentiles are always cheaper to compute than averages
  2. Means are meaningful only for availability, never for latency
  3. Percentiles deliberately discard the slowest requests
  4. A mean hides the slow requests users actually notice Correct answer.

Explanation

Averages are pulled down by the many fast requests, so a small population of very slow responses can vanish from the mean while still annoying real users. A high percentile such as the 99th captures the tail those users experience.

Question 38Service Level Objectives and Error Budgets

A service is burning its error budget at a burn rate of 2. What follows if that rate continues?

  1. The service is comfortably within budget
  2. Two percent of the budget has been spent so far
  3. The budget would run out in half the SLO window Correct answer.
  4. The SLO target doubles automatically

Explanation

A burn rate of 1 exhausts the budget exactly at the end of the window, so a rate of 2 exhausts it in half that time. Burn rate describes the pace of consumption and says nothing about how much has already been spent.

Question 39Service Level Objectives and Error Budgets

You want one availability figure for two services that serve very different traffic volumes. What is the sound approach?

  1. Take the higher of the two SLI percentages as the combined value
  2. Pool good and valid event counts across both services Correct answer.
  3. Multiply the two SLI percentages together
  4. Average their two SLI percentages and round to one decimal

Explanation

Pooling the underlying event counts weights each service by its real traffic, which is what a user-weighted view of reliability requires. Averaging percentages treats a tiny service as equal to a large one and distorts the result.

Question 40Service Level Objectives and Error Budgets

Under a typical error budget policy, what happens when a service exhausts its budget for the quarter?

  1. The service is immediately decommissioned and replaced
  2. Monitoring continues but every alert is muted until next quarter
  3. The SLO target is lowered until the budget is positive again
  4. Feature releases pause until reliability work restores it Correct answer.

Explanation

An error budget policy is agreed in advance and normally freezes risky changes, such as feature launches, once the budget is gone, shifting engineering effort to reliability until the service is back within budget. Lowering the target or muting alerts would defeat its purpose.

Question 41Service Level Objectives and Error Budgets

Which item is an SLI specification rather than an SLI implementation?

  1. How quickly a page loads for a typical user Correct answer.
  2. Log-based counting of HTTP 500 responses per minute
  3. A dashboard panel plotting request latency percentiles
  4. A ratio produced by a Prometheus recording rule

Explanation

The specification states the user-focused property to be measured, such as how quickly a page loads for a typical user. Implementations are the concrete queries, logs or metrics that realise that specification, and several may be needed to approximate it well.

Question 42Service Level Objectives and Error Budgets

How does a healthy error budget affect release strategy?

  1. It removes the need for canarying new releases
  2. It shows the team can safely take on more risk Correct answer.
  3. It lets the team skip capacity planning permanently
  4. It freezes all releases until the budget is fully spent

Explanation

A budget with room left indicates the service has been more reliable than required, so the team can spend that margin on riskier changes. It is a signal to move faster, not a licence to abandon safe delivery practices.

Question 43Service Level Objectives and Error Budgets

An SLO-based alerting philosophy favours alerting on which signal?

  1. CPU saturation on the primary database host
  2. The rate at which the error budget is being spent Correct answer.
  3. Disk queue length on the storage nodes
  4. The number of deployments performed today

Explanation

Alerting on budget spend keeps alerts tied to user-visible reliability rather than to internal causes that may or may not affect users. Cause-based signals remain valuable for diagnosis once an SLO alert has fired.

Question 44Service Level Objectives and Error Budgets

What is the main trade-off when a team chooses a longer SLO measurement window?

  1. They smooth noise but respond slowly to new problems Correct answer.
  2. Longer windows remove the need for percentile metrics
  3. Longer windows remove the need for burn-rate alerts
  4. Longer windows make the SLI impossible to compute

Explanation

A long window averages over more history, so random variation is less likely to make the target look missed, but a real regression takes longer to become visible. Teams often pair a long SLO window with short-window burn-rate alerts for fast detection.

Question 45Service Level Objectives and Error Budgets

When defining the denominator of a request-based SLI, which requests should be left out of valid events?

  1. Requests that returned a successful status code
  2. Malformed or unauthorised requests that were never valid Correct answer.
  3. Requests made by internal staff only
  4. Requests that exceeded the latency threshold in the SLO

Explanation

Valid events are the requests the SLO is meant to govern, so traffic that never had a chance to succeed, such as bad-client or unauthenticated requests, is filtered out. Slow or successful requests stay in the denominator and are classified as good or bad.

Question 46Service Level Objectives and Error Budgets

In a multiwindow, multi-burn-rate alert, what is the role of the short window?

  1. It makes the alert stop firing soon after the burn ends Correct answer.
  2. It replaces the long window once the incident is over
  3. It reduces the number of alert rules the team must maintain
  4. It guarantees the alert never fires for slow-burning incidents

Explanation

The long window provides precision so brief spikes do not page anyone, while the short window provides fast reset: once the burn stops, the short window falls below threshold and the alert clears quickly. Both windows must be above threshold for the alert to fire.

Question 47Service Level Objectives and Error Budgets

A service is consuming its 30-day error budget at 2 percent of the budget per hour. What burn rate does that represent?

  1. About 2.0
  2. About 7.2
  3. About 14.4 Correct answer.
  4. About 1.4

Explanation

A burn rate of 1 spends the whole budget over the 720 hours of a 30-day window. Spending 2 percent per hour empties the budget in 50 hours, and 720 divided by 50 gives a burn rate of about 14.4.

Question 48Service Level Objectives and Error Budgets

Service A carries 90 percent of traffic at 99.9 percent success; service B carries 10 percent of traffic at 99.0 percent success. What is the pooled success rate?

  1. 99.45 percent
  2. 99.81 percent Correct answer.
  3. 99.00 percent
  4. 99.90 percent

Explanation

Pooling events weights each service by its share of traffic: 0.9 multiplied by 0.999 plus 0.1 multiplied by 0.99 equals 0.9981, or 99.81 percent. An unweighted average would let the small service distort the result.

Question 49Service Level Objectives and Error Budgets

A team tightens an availability SLO from 99.9 percent to 99.95 percent over the same 30-day window. What is the direct effect?

  1. The SLI must be redefined from ratios to averages
  2. The error budget is halved Correct answer.
  3. The measurement window must shrink to 15 days
  4. The error budget doubles in size

Explanation

Allowed failure is 100 percent minus the target, so the budget falls from 0.1 percent to 0.05 percent of events: half the previous allowance over the same window. Nothing else about the indicator needs to change.

Question 50Service Level Objectives and Error Budgets

A service meets its availability SLO every month, yet users complain about frequent failures. What is the most likely explanation?

  1. The budget is being calculated in the wrong time zone
  2. Latency percentiles are being summed instead of averaged
  3. Failures are concentrated in a journey the SLI does not cover Correct answer.
  4. The SLO target sits above 100 percent and is ignored

Explanation

An aggregate SLI can look healthy while one specific user journey, such as checkout, fails far more often than the average suggests. The remedy is to define SLIs around the journeys users care about rather than only around server-wide totals.