5 exercises — Master the language of the SLI/SLO/SLA hierarchy, error budget calculation, and reliability target communication.
0 / 16 completed
1 / 16
An SRE is explaining the reliability measurement system to a new team member. They say: "We measure availability using request success rate as our ___, we set a 99.9% target as our ___, and the contractual commitment with enterprise customers is the ___." Choose the correct order.
SLI → SLO → SLA is the correct hierarchy.
SLI (Service Level Indicator) is the measured metric — e.g., "99.95% of requests returned a 2xx response in the last 30 days."
SLO (Service Level Objective) is the internal target for that indicator — e.g., "We aim to keep the SLI above 99.9%."
SLA (Service Level Agreement) is the external contractual commitment — e.g., "Enterprise customers are guaranteed 99.5% availability with financial penalties for breach."
Key vocabulary:
• SLI — the actual measured value; always a ratio or percentage
• SLO — internal reliability target; slightly tighter than the SLA
• SLA — legal/commercial commitment to customers
• SLO tighter than SLA — intentional buffer so internal violations don't immediately breach the customer contract
2 / 16
A product team proposes a new API with this spec: "We'll measure availability as the percentage of requests where HTTP status code is not 5xx." An SRE reviewer says this SLI definition is incomplete. What critical element is missing?
A good SLI definition typically specifies both success criteria AND a latency boundary.
"Not 5xx" captures availability but ignores slow responses. A request that takes 60 seconds and returns 200 is technically "available" but functionally broken for users.
The Google SRE recommendation is to define a request-based SLI as: "the proportion of valid requests served successfully within a threshold latency."
Additionally, the measurement window must be explicit (rolling 28/30 days is standard).
Key vocabulary:
• Request-based SLI — measures individual requests rather than uptime checks
• Latency SLI — proportion of requests faster than a threshold (e.g., P99 < 500 ms)
• Availability SLI — proportion of requests returning non-error status
• Good event / bad event — binary framing: each request is either good or bad
3 / 16
During a weekly SRE stand-up, someone says: "We need to distinguish between our SLO and what we're telling customers. The internal target should be stricter." Which statement correctly explains why?
Setting the internal SLO tighter than the SLA provides an error budget buffer.
If the SLA promises 99.5% availability but the internal SLO targets 99.9%, the SRE team has roughly 3.6 hours/month of wiggle room. When the internal SLO starts burning fast, the team has time to respond before the SLA is breached.
This concept is sometimes called the "SLO gap" or "SLA buffer".
Key vocabulary:
• SLA buffer — gap between internal SLO and customer-facing SLA
• Tight SLO — internal target significantly above the SLA
• SLA breach — when actual reliability falls below the contractual guarantee
• Financial remedy — penalty paid to customers when SLA is breached (service credits, refunds)
4 / 16
An engineer is writing a runbook entry for a new SLI. They write: "SLI = (good_requests / valid_requests) × 100%." What does "valid requests" mean in this context, and why is it important?
"Valid requests" is the denominator — it filters out traffic that shouldn't count toward the SLI.
Common exclusions from the denominator:
• Synthetic load test traffic (would artificially inflate the bad-event count)
• Internal health-check probes (expected to succeed; skew the numerator up)
• Requests with malformed input that any API would reject (user error, not service error)
Carefully defining the denominator prevents "gaming" the SLI and ensures it reflects genuine user experience.
Key vocabulary:
• Valid request — request that a correct service should be able to serve
• Good event — valid request that was served successfully
• Denominator scope — which requests count toward the SLI calculation
• SLI denominator exclusions — traffic intentionally removed from the calculation
5 / 16
A new SRE reads the following in their team's documentation: "Our checkout API has an SLO of 99.95% availability over a rolling 30-day window." They need to calculate the error budget. Which calculation is correct?
Error budget = (1 − SLO) × window length.
For 99.95% availability over 30 days:
• 30 days × 24 h × 60 min = 43,200 minutes in a month
• Error budget = 0.05% × 43,200 = 21.6 minutes
This means the service can be "unavailable" (serving bad events) for only 21.6 minutes per month before the SLO is breached.
Option A confuses the percentage with minutes directly. Option D misunderstands the direction (the budget is for failures, not successes).
Key vocabulary:
• Error budget — the allowed amount of unreliability; (1 − SLO) × window
• Budget remaining — how much error budget has not yet been consumed
• Budget burn — consuming error budget through incidents or deployments
• SLO breach — when error budget is exhausted before the window ends
6 / 16
During a code review of a new service deployment script, Sarah (the SRE) comments to David: 'Let's ensure we track our Service Level Indicator (SLI) for successful API calls. We'll define it as the percentage of requests that return a 200 status code, and then set an SLO based on that, aiming for 99.9% uptime.' David replies with: 'Okay, but what if some requests fail because we're temporarily rate-limiting them? Should we still count those as successful?' Which of the following best represents Sarah's intended approach to defining the SLI and SLO?
Sarah's focus on 200 status codes correctly identifies a core SLI – successful responses. Transient failures (like rate limiting) are typically treated as *expected* deviations from the SLO, not errors that invalidate the metric. Option A highlights the need to address transient issues, which is crucial for accurate availability measurement; options C and D misunderstand the role of the SLI in measuring uptime.
7 / 16
The team's Slack channel shows a message from Alex (a developer): 'Just deployed the new payment gateway. We're tracking availability as the number of successful transactions divided by total transaction attempts – aiming for 99.5% SLO.' Another engineer, Ben, replies: 'That's good to see you're using an SLI, but are you considering potential skew in your data? What if we have a huge spike in requests during a promotional campaign?' Which statement best explains Ben's concern regarding Alex's proposed SLI definition?
Ben correctly identifies the risk of skewed data – a spike in requests during a promotion would disproportionately increase the number of 'successful' transactions, artificially inflating the SLI. Alex's initial definition relies solely on raw volume without accounting for external factors that could influence request rates and therefore distort the availability metric.
8 / 16
You're reviewing a pull request that updates the monitoring dashboard. The PR description reads: 'Added new metrics to track API latency. We'll use percentiles (95th and 99th) to measure response times, aiming for an SLO of 200ms average.' What key element is *missing* from this description regarding how these latency metrics will contribute to overall service availability?
While monitoring latency percentiles is useful, the description fails to explicitly link these metrics to a definition of 'availability'. Latency directly impacts user experience and can easily be used as an SLI. The PR needs to explain how these latency figures contribute to determining if the service meets its availability SLO.
9 / 16
During a daily stand-up, Maria (an SRE) says: 'We're targeting an SLO of 99.9% for our core service, but internally, we need to be more aggressive – perhaps aiming for 99.95%.' What is the *primary* reason Maria suggests this difference in target?
The key difference between an internal SLO and a customer-facing one lies in the error budget. A stricter internal target allows for more aggressive use of the error budget – the permissible amount of downtime before violating the SLA. This provides greater flexibility to address unexpected issues without immediately impacting service levels.
10 / 16
David, a developer, sends this Slack message: 'Okay team, we're aiming for 99.9% uptime on the new service. We'll track it with the number of successful requests. If anything goes wrong, it's an SLA breach!' Which statement best reflects David's understanding of SLOs?
David's statement demonstrates a basic understanding that an SLO is a target for reliability. However, it misses the crucial element that SLOs are defined by metrics (like successful requests) and represent a commitment to service levels. The correct option correctly defines SLO as the agreed-upon level of service reliability based on those metrics.
11 / 16
Sarah, an SRE, is reviewing a PR for a new microservice. The PR description states: 'We'll use the percent of successful API calls to define our SLO and aim for 95th percentile latency under normal load.' What is Sarah most likely concerned about regarding this definition?
Sarah's concern highlights the importance of considering context. While successful API calls are part of an SLO, simply focusing on the 95th percentile without acknowledging peak load or potential degradations provides a dangerously incomplete picture. A robust SLO should account for various operational conditions.
12 / 16
Mark is explaining SLOs to a new team member. He says: 'Our Service Level Indicator (SLI) for our user authentication service is the percentage of successful login attempts. We've set an SLO of 99.9% availability, meaning we aim to have the authentication service up and running 99.9% of the time over a rolling 30-day period. To manage this, we have an error budget which allows for occasional downtime.' Which statement best describes the *purpose* of the error budget in this scenario?
The error budget represents the permissible amount of downtime within an SLO. It's not a fixed time but rather the *variance* allowed around the target. This variance allows for unexpected issues or planned maintenance without immediately violating the SLO. Option A is too rigid; option C correctly captures the dynamic nature of the budget, and options B and D misinterpret its role.
13 / 16
During a Slack discussion about monitoring, Liam (a developer) writes: 'We're tracking API response times using percentiles. We've set an SLO of 99th percentile latency under normal load to be less than 200ms.' Which of the following best explains why Liam is focusing on the 99th percentile?
Using percentiles, particularly the 99th, is crucial because it measures the tail latency. This captures the worst-case scenario experienced by a significant portion of users – those who might be experiencing unusually slow responses. While average response time provides another metric, the 99th percentile offers a more robust measure of user experience and helps identify potential bottlenecks that could impact the majority of requests.
14 / 16
Sarah, an SRE, is reviewing a PR for a new feature. The PR description states: 'We'll define our SLI as the ratio of successful transactions to total attempted transactions. We're aiming for a 99.9% SLO.' Which statement accurately reflects Sarah's likely concern?
Sarah would likely be concerned about the lack of a defined time window. An SLI needs a specific period (e.g., 30 days) to accurately measure availability. Without this context, it's impossible to determine if the 99.9% SLO is being met consistently – the definition is incomplete and doesn't provide enough information for accurate monitoring.
15 / 16
During a standup meeting, David (a developer) says: 'We're tracking our service availability as the percentage of requests that return a successful HTTP 200 status code. We've set an SLO for 99.5%.' What does 'successful HTTP 200 status code' primarily indicate in this context?
A successful HTTP 200 status code is the standard response from a web server indicating that a request was received, understood, and accepted for processing without errors. It's a fundamental indicator of service health, confirming that the server successfully handled the request – other codes (like 5xx) indicate problems.
16 / 16
You're reviewing documentation for an API with an SLO of 99.8% availability over a rolling 7-day window. The documentation states: 'Error Budget = Total Window - Successful Window'. What does 'Successful Window' represent?
'Successful Window' represents the period during which the API met its SLO target (99.8% availability in this case). It's calculated by subtracting the total observation window (7 days) from the duration where the service operated within the specified availability threshold – This is the time available for errors or downtime, and therefore the error budget.
What will I learn from the "SLI, SLO & SLA Vocabulary — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for SLI/SLO/SLA hierarchy: how to define service level indicators, set objectives, distinguish from contractual agreements, and calculate error budgets.
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 16 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 16 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.