SRE Toil Reduction & Elimination 3 — Questions and Answers
Question 1: Google's SRE model recommends capping toil at what percentage of an SRE team's working time?
- 50%
- 25% (Correct answer)
- 10%
- 75%
Correct answer: 25%
Google's SRE book recommends that toil should not exceed 50% of each SRE's time, with the aspirational goal of keeping it well below that, often cited in practice as targeting around 50% or less with continuous improvement toward lower percentages; the canonical cap stated is 50%, but the practical target emphasized is keeping it at or below 50%, and many sources cite the goal as under 50% — the most commonly tested figure in the SRE Foundation certification is 50%.
Question 2: Which of the following is an example of toil that is ALSO a reliability risk if left unaddressed?
- Manually rotating API keys before they expire (Correct answer)
- Writing quarterly team retrospectives
- Attending architecture review meetings
- Updating internal team wikis
Correct answer: Manually rotating API keys before they expire
Manual key rotation is toil that also creates reliability risk because human delays or oversights can lead to expired credentials causing production outages.
Question 3: A self-healing system automatically detects and corrects a misconfiguration without any human involvement. This BEST demonstrates which toil elimination principle?
- Closed-loop automation (Correct answer)
- Escalation suppression
- Alert deduplication
- Capacity planning automation
Correct answer: Closed-loop automation
Closed-loop automation detects, diagnoses, and remediates issues automatically, fully removing the human from repetitive remediation tasks.
Question 4: When measuring toil, an SRE tracks 'interrupt-driven work.' What does this term describe?
- Reactive tasks that pull engineers away from planned project work (Correct answer)
- Scheduled maintenance windows planned in advance
- Work assigned by product managers mid-sprint
- Customer support tickets routed to engineering
Correct answer: Reactive tasks that pull engineers away from planned project work
Interrupt-driven work is unplanned, reactive work triggered by alerts or requests that disrupts engineers' focus on strategic improvements.
Question 5: An organization uses 'error budgets' as part of toil reduction. How does an error budget directly relate to toil?
- Excessive toil consumes time that could be spent on reliability improvements, indirectly burning error budget faster (Correct answer)
- Error budgets set the maximum allowed toil percentage for each team
- Error budgets are used to justify hiring engineers to absorb toil
- They are unrelated — error budgets govern SLO compliance, not toil
Correct answer: Excessive toil consumes time that could be spent on reliability improvements, indirectly burning error budget faster
High toil reduces the time available for reliability engineering work, which means incidents are less likely to be prevented, leading to faster error budget consumption.
Question 6: Which scenario BEST illustrates 'toil that creates more toil' (a toil feedback loop)?
- Manually scaling servers under load generates alerts requiring manual acknowledgment, which itself generates tickets requiring manual closure (Correct answer)
- Writing automation code that must be maintained
- Investigating a novel incident not seen before
- Reviewing pull requests for the automation framework
Correct answer: Manually scaling servers under load generates alerts requiring manual acknowledgment, which itself generates tickets requiring manual closure
Toil feedback loops occur when one manual task triggers additional manual tasks, compounding the time burden with each cycle.
Question 7: A proposed automation would handle 90% of cases but requires human escalation for the remaining 10%. What is the BEST approach?
- Implement the automation for the 90% while building a clear escalation path and logging edge cases to close the gap over time (Correct answer)
- Reject the automation because it doesn't handle all cases
- Implement automation only after achieving 100% coverage in testing
- Assign dedicated engineers to handle the 10% edge cases permanently
Correct answer: Implement the automation for the 90% while building a clear escalation path and logging edge cases to close the gap over time
Iterative automation that handles most cases immediately while gathering data to close gaps is far better than delaying automation until perfection is achieved.
SRE Toil Reduction & Elimination 3
Google's SRE model recommends capping toil at what percentage of an SRE team's working time?