5 exercises — Practice the English for negotiating SLO targets with stakeholders, calibrating based on consequences, and bootstrapping first SLOs.
0 / 10 completed
1 / 10
A product team requests 99.99% availability for their new feature. The SRE lead responds: "Before we commit to that, let's talk about what that actually means and whether it's justified." Which statement correctly frames the conversation?
Setting reliability targets is a cost-benefit negotiation, not a technical exercise alone.
The downtime math makes the cost tangible:
• 99% = 3.65 days/year
• 99.9% = 8.76 hours/year
• 99.99% = 52.6 minutes/year
• 99.999% = 5.26 minutes/year
Each additional "nine" is exponentially more expensive to achieve — it requires more redundancy, more operational complexity, more testing.
The right question: "What are the actual consequences of downtime for this service?" A blog doesn't need 99.99%. A payment processor might.
Key vocabulary:
• Nines of availability — colloquial term for the number of 9s in the availability percentage
• Cost of reliability — engineering and infrastructure investment required to achieve a target
• Justified reliability — the highest SLO whose cost is warranted by business impact
• Single point of failure — a component whose failure brings down the whole service
2 / 10
During an SLO calibration session, the SRE team asks: "What's the consequence if availability drops to 99%? What about 99.5%? What about 98%?" What technique are they applying?
Consequence mapping identifies the "pain threshold" that should inform SLO target-setting.
The right SLO is one where:
• If you're above the SLO → users are happy, business is unaffected
• If you're below the SLO → users notice degradation, business impact begins
Examples of consequence mapping questions:
• "If the checkout API is 99% available, how many transactions fail per day?"
• "At what point do enterprise customers trigger SLA penalty clauses?"
• "What availability level generates significant support ticket volume?"
Key vocabulary:
• Consequence mapping — asking "what happens if we miss this target by X%?"
• Pain threshold — the reliability level below which users and business feel real impact
• User-facing SLO — target calibrated to actual user experience
• Business-justified target — reliability level justified by measurable business impact
3 / 10
A stakeholder says: "Let's just set the SLO at 99.99% — the highest we can reasonably achieve — to give maximum reliability buffer." An SRE objects. Which argument best supports the SRE's position?
An over-tight SLO starves the error budget, removing the team's ability to take calculated risks.
If the SLO is set at 99.99% and you're currently achieving 99.97%, you have about 1.7 minutes/month of error budget. A single routine deployment touching a database schema could burn that instantly.
A calibrated SLO should be:
• Tight enough to protect users and business
• Loose enough to leave error budget for engineering work
• Achievable at current operational maturity
The correct SLO is slightly above what you're reliably achieving today — it creates a stretch goal without eliminating the budget.
Key vocabulary:
• Aspirational SLO — target set above current capability; drains error budget constantly
• Achievable SLO — target consistent with current system reliability (+small buffer)
• Error budget starvation — what happens when the SLO is set too high
• Reliability investment — work done to improve the system to meet a higher SLO over time
4 / 10
An SRE presents to the VP of Engineering: "We recommend moving from a single availability SLO to a composite SLO with three components: availability, latency P99, and data freshness." What is the primary benefit of this approach?
Composite SLOs reflect the multiple dimensions of service quality that users experience.
A service returning 200 responses in 30 seconds is technically available but practically broken. A search API returning results from 24 hours ago is available but useless.
Common SLO dimensions for web services:
• Availability — proportion of requests served without errors
• Latency — proportion of requests served within a time threshold
• Freshness — (for data-serving systems) proportion of responses using data updated within X time
• Correctness — (for computation) proportion of responses with correct results
Key vocabulary:
• Composite SLO — SLO combining multiple SLI types into one agreement
• Multi-dimensional SLO — same concept; captures user experience holistically
• User-perceived quality — the combination of dimensions that define "is the service working?"
• SLI selection — the process of choosing which metrics best represent user experience
5 / 10
A new team asks: "How do we set our first SLO? We don't have historical reliability data yet." What is the recommended approach?
Data-driven SLO bootstrapping avoids aspirational targets that immediately breach.
The recommended process:
1. Instrument the service and start measuring SLIs (even if informal at first)
2. Observe actual reliability for at least 4 weeks — include a deployment cycle and some normal incidents
3. Set the initial SLO at roughly P95 of observed reliability (leave room below the worst observed value)
4. Review and tighten the SLO quarterly as reliability improves
A 95% SLO "just to be safe" is too relaxed — it normalizes poor reliability and fails to drive improvement.
Key vocabulary:
• Bootstrapping an SLO — establishing the first SLO for a new service
• Percentile-based SLO — setting the target based on observed performance distribution
• SLO ratcheting — progressively tightening the SLO as reliability improves
• Initial SLO — the first SLO, expected to be refined over time
6 / 10
Code Review Comment: 'This endpoint is returning 5xx errors intermittently. Can you investigate the error budget and see if we're hitting it?' Which of the following best explains what the reviewer is *really* asking about?
The reviewer isn't focused on the *how* (the code itself). Instead, they're probing whether the observed failures are within acceptable limits defined by the error budget. Understanding the error budget is critical for prioritizing and managing reliability targets. Options A, C, and D all represent specific technical actions that don't address the core question of budget adherence.
7 / 10
Slack Message: '@john.doe – Our new API is seeing a spike in 429 errors. The error budget is currently at 10%. Let's discuss how this impacts our users.' What does John need to consider when responding?
The Slack message highlights a key issue: exceeding the error budget. John needs to investigate *why* the 429 errors are occurring and whether they're linked to the budget constraints. Simply scaling servers without understanding the root cause won't solve the problem; it might just mask the underlying issue. Analyzing request patterns is crucial for identifying triggers and potential solutions aligned with the error budget.
8 / 10
PR Description: 'Implementing improved logging to track root cause of intermittent performance degradation. Targeting reduction in P95 latency to below 200ms.' What is the most important factor this PR should consider when evaluating its success?
While improved logging is valuable, the *ultimate* goal is to manage the error budget. The PR's success hinges on whether reducing latency actually contributes to staying within the defined limits – a reduction in P95 latency directly impacts the available space within the error budget for other potential failures. The other options are secondary considerations.
9 / 10
Standup Update: 'Yesterday, we observed a slight increase in request latency during peak hours. The error budget for availability remains at 99.9%.' What is the *primary* concern this update raises?
The update explicitly mentions a rise in latency and the existing availability SLO. This immediately signals a potential problem – if latency increases significantly, it could push the system closer to violating the 99.9% availability target. While performance optimization is desirable, the immediate concern is budget adherence.
10 / 10
API Response (Error): The API returned: `{"code": 503, "message": "Service Unavailable - Error Budget Exceeded"}`. What does this response *primarily* indicate?
The `503 Service Unavailable` status code combined with the 'Error Budget Exceeded' message clearly indicates that the system's error rate has exceeded its predefined limits. This is a deliberate mechanism to protect the service from overload and potential cascading failures – essentially, a controlled outage. The other options represent alternative failure scenarios.
What will I learn from the "Reliability Targets Discussion Language — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for setting and negotiating reliability targets: consequence mapping, composite SLOs, cost-benefit framing, and bootstrapping first SLOs.
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.