5 exercises — Practice the English for conducting SLO reviews, deciding when to tighten or relax targets, and using data as evidence for changes.
0 / 10 completed
1 / 10
An SRE lead opens the quarterly SLO review with: "Let's look at the data from the past three months and decide whether to tighten, relax, or maintain each SLO." Under what condition would it be appropriate to tighten an SLO?
The quarterly SLO review uses budget consumption as the primary signal for adjusting targets.
Decision framework:
• Budget mostly unused (>80% remaining) → the SLO may be too loose; consider tightening
• Budget partially consumed (20–70% used) → the SLO is well-calibrated; maintain
• Budget nearly exhausted (<20% remaining) → the SLO may be aspirational; investigate before relaxing
Tightening an SLO when you have headroom signals commitment to users and raises the bar — but should be done incrementally (e.g., 99.9% → 99.95%, not 99.9% → 99.99%).
Key vocabulary:
• SLO review — periodic (quarterly) assessment of whether SLO targets are still appropriate
• Tightening the SLO — raising the reliability target
• Relaxing the SLO — lowering the reliability target (requires stakeholder agreement)
• SLO ratchet — the pattern of incrementally tightening SLOs as reliability improves
2 / 10
The SRE team wants to relax the SLO for a legacy service from 99.9% to 99.5%. An engineer argues: "We should just lower it quietly — it's an internal tool anyway." An SRE lead disagrees. What is the most important reason to avoid silently relaxing an SLO?
SLO changes must be communicated because stakeholders make decisions based on reliability commitments.
Even for internal tools, service consumers plan around reliability expectations:
• Dependent teams build retry logic based on expected failure rates
• Capacity planning assumes certain availability levels
• Incident priority may be set based on the SLO tier
The correct process for relaxing an SLO:
1. Bring data to the SLO review (this is why we're considering it)
2. Get alignment from product and dependent teams
3. Update the SLO document and notify stakeholders
4. Adjust any dependent SLAs if applicable
Key vocabulary:
• SLO relaxation — reducing the reliability target; requires stakeholder agreement
• Reliability regression — actual or acknowledged reduction in service reliability
• SLO transparency — making SLO targets and their changes visible to stakeholders
• Stakeholder alignment — getting agreement from affected parties before changing targets
3 / 10
In a review meeting, an engineer says: "Our latency SLO for P99 is 500ms, but looking at the data, we're consistently at P99 = 320ms. Let me propose we update the evidence in the next review." What is "evidence" in this SLO review context?
In SLO reviews, evidence = data that supports the proposed change to the SLO target.
To support tightening the latency SLO from P99 500ms to P99 350ms, the evidence package would include:
• Time-series latency percentile charts for the review period
• P99 distribution showing consistent 300–340ms range
• Error budget consumption showing >90% remaining
• Traffic analysis showing no seasonal patterns that would skew the data
The evidence makes the SLO change data-driven rather than opinion-driven — critical when negotiating with stakeholders who might resist changes.
Key vocabulary:
• Evidence-based SLO review — using measurement data rather than intuition to adjust SLOs
• SLI time series — historical data showing how the measured metric has performed
• Review period — the time window analyzed (typically the last quarter)
• P99 latency — the 99th percentile of response time; the threshold below which 99% of requests fall
4 / 10
At the end of a quarterly review, the SRE lead documents: "After review, we're maintaining the current SLO at 99.9%. The service consumed 45% of its error budget, with three minor incidents. The SLO is well-calibrated." What does "well-calibrated" mean in this context?
"Well-calibrated" describes an SLO that correctly balances reliability with engineering freedom.
Signs an SLO is well-calibrated:
• Error budget is consumed meaningfully (not zero, not completely)
• The team can ship features without constantly hitting the policy threshold
• Users are satisfied at current reliability levels
• Incidents feel meaningfully caught — not covered up by a loose SLO
Signs of poor calibration:
• Budget always 100% remaining → SLO too loose
• Budget always depleted by mid-month → SLO too tight
• Team can never deploy without triggering the policy → SLO not matched to operational reality
Key vocabulary:
• Well-calibrated SLO — reliability target that correctly represents service quality expectations
• Healthy error budget consumption — budget used meaningfully but not exhausted
• SLO vs. reality gap — distance between the target and actual measured performance
• SLO maintenance — deciding not to change the target after reviewing data
5 / 10
An SRE is preparing for the quarterly SLO review and says: "Before we discuss the numbers, let's agree on our adjustment criteria first — what would make us tighten versus relax versus maintain each SLO?" Why is agreeing on criteria before looking at data important?
Agreeing on criteria before the data forces objective decisions rather than narrative-fitting.
Without pre-defined criteria:
• If the data looks bad → team might argue to maintain or relax "based on context"
• If the data looks good → team might argue to maintain "because it's working"
• The decision is influenced by who spoke last or most persuasively
With pre-defined criteria (e.g., "if budget remaining >80% for 2+ quarters, we tighten by one step"):
• The data drives the conclusion
• The team can defend the decision to leadership with clear logic
• Consistency across reviews builds trust in the SLO process
Key vocabulary:
• Pre-defined criteria — decision thresholds agreed before reviewing data
• Confirmation bias — tendency to interpret data to confirm existing beliefs
• Data-driven SLO review — decisions based on measurement, not opinion
• SLO governance — the process and rules for how SLOs are reviewed and changed
6 / 10
Sarah, a junior SRE, is drafting a pull request to update the error budget for a new feature. Her manager, David, comments: 'This looks good, but let's ensure we've clearly articulated why we're requesting this increased budget. What's the most crucial piece of information Sarah should include in her PR description regarding the error budget?',
Insufficient – the question focuses on justification. The core reason for requesting an increased error budget is a demonstrable increase in potential failures (high failure rate or unexpected spikes). Simply stating a technical detail isn't enough; it needs to connect to the risk associated with the feature. Option A lacks context, and options C & D are too vague.
7 / 10
During a Slack discussion about SLOs for their microservice, Alex asks: 'We're consistently hitting our 99.5% availability SLO. Should we consider relaxing it, or are there other factors we should investigate first?'. Which of the following is the MOST appropriate initial response from Ben, a senior SRE? '
Insufficient – Alex is asking for a proactive approach. Relaxing an SLO without investigation is premature and potentially dangerous. It ignores the underlying issues contributing to the violation. Ben's response emphasizes data-driven decision making – investigating root causes before adjusting targets is crucial for effective SLO management.
8 / 10
Mark, a developer, sends this message to the team channel: 'Just deployed the new version of the API. Latency is looking good, P95 around 10ms.' Which statement best describes how the SRE team should interpret and react to this message? '
Insufficient – Mark's message provides a single latency point. While positive, it doesn't confirm adherence to the broader SLO. The SRE team *must* verify this metric against the defined latency SLO to ensure alignment and identify potential issues before they escalate. Simply stating 'great performance' is insufficient.
9 / 10
Maria, an SRE, is preparing a presentation for the monthly SLO review meeting. She notes: 'We've consistently exceeded our 99.9% uptime SLO over the past quarter, and we've used 65% of our error budget. However, recent incident analysis reveals a correlation between this usage and increased complexity in new feature deployments.' What does Maria primarily demonstrate with this observation? '
Insufficient – The key takeaway here isn't about simply achieving uptime. It's highlighting the *relationship* between the error budget usage and a specific contributing factor (development complexity). This observation triggers a need to re-evaluate the SLO calibration and potentially adjust it based on observed trends, not just raw numbers.
10 / 10
During a standup meeting, David asks the team: 'How's the performance of the billing service looking? We're aiming for P99 latency under 200ms.' Sarah responds: 'We've been hitting around 350ms lately. I'm monitoring it closely and will investigate if necessary.' What is Sarah doing in this exchange, concerning her SLO? '
Insufficient – Sarah's response demonstrates proactive engagement. By stating she's 'monitoring it closely' and will 'investigate if necessary,' she acknowledges the potential SLO breach and signals intent to address it. This is a crucial step in responsible SLO management; simply reporting numbers isn't enough.
What will I learn from the "SLO Review & Adjustment Language — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for quarterly SLO reviews: tightening and relaxing targets, evidence-based decisions, calibration language, and stakeholder communication.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this SLO Engineering exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss slo engineering topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more SLO Engineering exercises?
See the full SLO Engineering exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.