5 exercises — trigger conditions, exact commands, verification steps, rollback procedures, and runbook maintenance. Write runbooks people can follow at 3am.
0 / 22 completed
1 / 22
An SRE is writing a runbook step for restarting the payments service. Which version is best for use at 3am during an incident?
The best runbook step has five elements that allow a stressed engineer to follow it at 3am:
1. Exact command: No ambiguity about what to run. Copy-pasteable. 2. Expected outcome: "Pod restarts within 60 seconds" — the engineer knows what success looks like. 3. Verification step: A command to confirm the action worked. 4. Time expectation: "after 2 minutes" — so the engineer knows when to stop waiting. 5. Escalation path: Who to call if this step fails, and how to reach them.
Runbook writing principles: • Write for someone who has never seen this service before • Use active, imperative verbs: Run, Verify, Check, Escalate — not "you might want to" • Never say "if appropriate" or "as needed" — these are decisions the runbook should make for the reader • Include rollback steps • Include links to dashboards and relevant logs
Anti-patterns to avoid: ❌ "Fix the memory issue" (not actionable) ❌ "Check if there are problems" (too vague) ❌ "As per standard procedure" (circular reference to nothing)
2 / 22
A runbook begins: "This runbook covers restarting the auth service." A senior SRE says it's incomplete. The critical missing element in the runbook's opening is _____.
A runbook without a clear trigger condition is dangerous: engineers either use it when they shouldn't, or don't use it when they should.
A complete runbook opening includes:
Purpose: "This runbook describes how to restart the auth service." When to use: "Use when: (1) PagerDuty alert 'auth-service-high-latency' fires AND p99 latency > 500ms for 5+ minutes, OR (2) auth service Pods are in CrashLoopBackOff." Prerequisites: "Requires access to: production namespace, Datadog, #incidents-channel." Estimated duration: "~5 minutes if Pods restart normally; escalate if >15 minutes." Last tested: "2026-03-15 by Alice Chen"
Why the trigger condition matters most: Engineers arriving at an incident are stressed. They need to know immediately: "Is this the right runbook for my situation?" Without explicit trigger conditions, they either apply the wrong runbook (causing additional damage) or waste time reading through to find out if it applies.
Runbook metadata vocabulary: "This runbook applies when…" "Trigger conditions: …" "Do NOT use this runbook if…" "Prerequisites: the following access / tools are required: …"
3 / 22
A runbook step says: "Scale up the consumer service." A new engineer is confused. Which rewritten step is clearest?
Good runbook steps always answer: exactly what action, with what value, how to verify success.
Breaking down the correct answer: • Exact command: `kubectl scale deployment/consumer-service --replicas=10 -n production` — no guessing what "scale up" means • Context: "increases from the current replica count to 10" — the engineer knows what's changing • Verification: specific metric (consumer lag), specific threshold (50,000), specific tool (Datadog) with a link, specific timeframe (3 minutes)
Why vague runbook steps cause incidents: "Scale up" → how many? 5? 20? 100? "If needed" → who decides when it's needed? During an incident, this becomes a debate "Handle the load" → not measurable — how do you know it's working?
Runbook action verb vocabulary: • "Run:" — for commands • "Navigate to:" — for UI steps • "Verify that:" — for checks • "If [condition], then:" — for conditional steps • "Wait until:" — for waiting with a success criterion • "Escalate to [team] via [channel] if:" — for escalation triggers
4 / 22
A runbook includes a section titled "Rollback Procedure." When should this section be used — and why is it essential?
A rollback procedure answers: "If following this runbook makes things worse, how do we undo what we just did?"
Why rollback sections are essential: • Runbook actions sometimes have unexpected side effects • A configuration change applied under pressure might have been the wrong one • An engineer needs to know they can safely undo actions without escalating
What a good rollback section looks like: "If after scaling to 10 replicas the consumer lag increases or error rate rises above 5%, roll back: kubectl scale deployment/consumer-service --replicas=3 -n production and notify #incidents with the current metrics."
Key rollback vocabulary: "Revert this change by:" "To restore to the previous state:" "Undo [step N] by running:" "Check the previous replica count in Datadog before scaling down" "Tag this incident with [label] so the post-mortem covers the rollback"
Rollback anti-patterns: ❌ "Undo the changes" (not actionable) ❌ No rollback section at all ❌ "Ask someone" (by 3am, "someone" may not be available) ❌ Rollback that requires the same expertise as the original fix
5 / 22
After an engineer successfully follows a runbook to resolve an incident, they notice one of the steps was outdated and no longer matched the current Kubernetes namespace. What is the correct action regarding the runbook?
A runbook that isn't maintained becomes more dangerous over time than having no runbook at all — because it creates false confidence.
Runbook maintenance vocabulary: "Update the runbook to reflect the current namespace/configuration." "Add a note: 'Updated 2026-04-07 — namespace changed from `legacy` to `production` (Alex T.).'" "Notify the team: 'Updated the auth restart runbook — step 3 namespace was wrong. Fixed.'"
When to update runbooks: • After any incident where a step was wrong, unclear, or missing • After infrastructure changes (new namespace, new tool, changed service name) • After any "first use" — the person using a runbook for the first time always finds inaccuracies • On a regular review schedule (quarterly at minimum for critical runbooks)
Runbook update best practices: • Add "Last tested by" and "Last updated" fields • Use version history or Git blame so teams can see what changed • Include who to contact if a step is unclear • Run fire drills: have a new team member follow the runbook and identify gaps
The "blameless maintainer" principle: updating a runbook after finding an error is a contribution, not an admission of fault.
6 / 22
Sarah is reviewing a pull request for a new feature that integrates with the Order Processing Service. The PR description includes the following step: 'Update the API endpoint to reflect the latest schema.' A senior developer asks her to add more detail about the expected response format after the update. Which of the following additions would be most appropriate to include in the PR description, aligning with best practices for runbook documentation?
The original description is insufficient because runbooks need *actionable* steps. While stating the endpoint change is technically correct, it doesn't provide the developer with what to do next or how to verify success. Option 2 directly addresses the senior developer's request for more detail by outlining a crucial testing step. It emphasizes validating the response against the updated schema – a standard practice in API documentation and runbook creation to ensure functionality after changes.
7 / 22
Alex is drafting a runbook step for rolling back a deployment of the User Profile Service. He writes: 'Rollback to previous stable version.' During a post-incident review, another engineer points out that this lacks crucial context. Which statement best explains why Alex's step needs further refinement in a production runbook?
Option A: It's perfectly clear and doesn't need any additional detail. Option B: The rollback should only be initiated by the SRE team, not developers. Option C: It fails to specify *how* the rollback is triggered – critical information for a rapid response. Option D: Including 'previous stable version' automatically ensures a successful rollback.
Runbooks are designed for quick action during incidents. Alex's step is too vague; it doesn't explain *how* the rollback actually happens – which command to execute, or what parameters to use. A good runbook step needs to provide specific instructions and trigger mechanisms, not just a general description. The goal is rapid, repeatable execution under pressure.
8 / 22
Mark, a DevOps engineer, is creating a runbook for diagnosing intermittent failures in the Inventory Service. He's drafted this step: 'Check CPU utilization on all pods.' During a Slack discussion with a junior developer, Sarah asks, 'What metrics should I be looking at *besides* CPU to understand potential bottlenecks?' Mark responds with:
Option A: 'Just CPU – it's the most important metric for performance issues.'
Option B: 'Check network latency between pods and the database. High latency often indicates a bottleneck.'
Option C: 'Review pod logs for errors or unusual patterns. Logs can provide valuable clues.'
Option D: 'The documentation covers all relevant metrics; don't worry about it.'
This question tests understanding of runbook completeness and the importance of considering multiple data points when troubleshooting. Focusing solely on CPU utilization is insufficient – a bottleneck could be elsewhere in the system. The correct answer emphasizes that a good runbook should cover a range of metrics to provide a holistic view, highlighting network latency as a key consideration. Options A and D are incorrect because they present overly simplistic or dismissive approaches.
9 / 22
Sarah is reviewing a pull request for a new feature that integrates with the Order Processing Service. The PR description includes the following step: 'Update the API endpoint to reflect the latest schema.' A senior developer asks her to add more detail about the expected response format after the update. Which of the following additions would be most appropriate to include in the PR description, aligning with best practices for runbook documentation?
The original description is insufficient because runbooks need *actionable* steps. While stating the endpoint change is technically correct, it doesn't provide the developer with what to do next or how to verify success. Option 2 directly addresses the senior developer's request for more detail by outlining a crucial testing step. It emphasizes validating the response against the updated schema – a standard practice in API documentation and runbook creation to ensure functionality after changes.
10 / 22
Alex is drafting a runbook step for rolling back a deployment of the User Profile Service. He writes: 'Rollback to previous stable version.' During a post-incident review, another engineer points out that this lacks crucial context. Which statement best explains why Alex's step needs further refinement in a production runbook?
Option A: It's perfectly clear and doesn't need any additional detail. Option B: The rollback should only be initiated by the SRE team, not developers. Option C: It fails to specify *how* the rollback is triggered – critical information for a rapid response. Option D: Including 'previous stable version' automatically ensures a successful rollback.
Runbooks are designed for quick action during incidents. Alex's step is too vague; it doesn't explain *how* the rollback actually happens – which command to execute, or what parameters to use. A good runbook step needs to provide specific instructions and trigger mechanisms, not just a general description. The goal is rapid, repeatable execution under pressure.
11 / 22
Mark, a DevOps engineer, is creating a runbook for diagnosing intermittent failures in the Inventory Service. He's drafted this step: 'Check CPU utilization on all pods.' During a Slack discussion with a junior developer, Sarah asks, 'What metrics should I be looking at *besides* CPU to understand potential bottlenecks?' Mark responds with:
Option A: 'Just CPU – it's the most important metric for performance issues.'
Option B: 'Check network latency between pods and the database. High latency often indicates a bottleneck.'
Option C: 'Review pod logs for errors or unusual patterns. Logs can provide valuable clues.'
Option D: 'The documentation covers all relevant metrics; don't worry about it.'
This question tests understanding of runbook completeness and the importance of considering multiple data points when troubleshooting. Focusing solely on CPU utilization is insufficient – a bottleneck could be elsewhere in the system. The correct answer emphasizes that a good runbook should cover a range of metrics to provide a holistic view, highlighting network latency as a key consideration. Options A and D are incorrect because they present overly simplistic or dismissive approaches.
12 / 22
Sarah is reviewing a pull request for a new feature that integrates with the Order Processing Service. The PR description includes the following step: 'Update the API endpoint to reflect the latest schema.' A senior developer asks her to add more detail about the expected response format after the update. Which of the following additions would be most appropriate to include in the PR description, aligning with best practices for runbook documentation?
The original description is insufficient because runbooks need *actionable* steps. While stating the endpoint change is technically correct, it doesn't provide the developer with what to do next or how to verify success. Option 2 directly addresses the senior developer's request for more detail by outlining a crucial testing step. It emphasizes validating the response against the updated schema – a standard practice in API documentation and runbook creation to ensure functionality after changes.
13 / 22
Alex is drafting a runbook step for rolling back a deployment of the User Profile Service. He writes: 'Rollback to previous stable version.' During a post-incident review, another engineer points out that this lacks crucial context. Which statement best explains why Alex's step needs further refinement in a production runbook?
Option A: It's perfectly clear and doesn't need any additional detail. Option B: The rollback should only be initiated by the SRE team, not developers. Option C: It fails to specify *how* the rollback is triggered – critical information for a rapid response. Option D: Including 'previous stable version' automatically ensures a successful rollback.
Runbooks are designed for quick action during incidents. Alex's step is too vague; it doesn't explain *how* the rollback actually happens – which command to execute, or what parameters to use. A good runbook step needs to provide specific instructions and trigger mechanisms, not just a general description. The goal is rapid, repeatable execution under pressure.
14 / 22
Mark, a DevOps engineer, is creating a runbook for diagnosing intermittent failures in the Inventory Service. He's drafted this step: 'Check CPU utilization on all pods.' During a Slack discussion with a junior developer, Sarah asks, 'What metrics should I be looking at *besides* CPU to understand potential bottlenecks?' Mark responds with:
Option A: 'Just CPU – it's the most important metric for performance issues.'
Option B: 'Check network latency between pods and the database. High latency often indicates a bottleneck.'
Option C: 'Review pod logs for errors or unusual patterns. Logs can provide valuable clues.'
Option D: 'The documentation covers all relevant metrics; don't worry about it.'
This question tests understanding of runbook completeness and the importance of considering multiple data points when troubleshooting. Focusing solely on CPU utilization is insufficient – a bottleneck could be elsewhere in the system. The correct answer emphasizes that a good runbook should cover a range of metrics to provide a holistic view, highlighting network latency as a key consideration. Options A and D are incorrect because they present overly simplistic or dismissive approaches.
15 / 22
Sarah is reviewing a pull request for a new feature that integrates with the Order Processing Service. The PR description includes the following step: 'Update the API endpoint to reflect the latest schema.' A senior developer asks her to add more detail about the expected response format after the update. Which of the following additions would be most appropriate to include in the PR description, aligning with best practices for runbook documentation?
The original description is insufficient because runbooks need *actionable* steps. While stating the endpoint change is technically correct, it doesn't provide the developer with what to do next or how to verify success. Option 2 directly addresses the senior developer's request for more detail by outlining a crucial testing step. It emphasizes validating the response against the updated schema – a standard practice in API documentation and runbook creation to ensure functionality after changes.
16 / 22
Alex is drafting a runbook step for rolling back a deployment of the User Profile Service. He writes: 'Rollback to previous stable version.' During a post-incident review, another engineer points out that this lacks crucial context. Which statement best explains why Alex's step needs further refinement in a production runbook?
Option A: It's perfectly clear and doesn't need any additional detail. Option B: The rollback should only be initiated by the SRE team, not developers. Option C: It fails to specify *how* the rollback is triggered – critical information for a rapid response. Option D: Including 'previous stable version' automatically ensures a successful rollback.
Runbooks are designed for quick action during incidents. Alex's step is too vague; it doesn't explain *how* the rollback actually happens – which command to execute, or what parameters to use. A good runbook step needs to provide specific instructions and trigger mechanisms, not just a general description. The goal is rapid, repeatable execution under pressure.
17 / 22
Mark, a DevOps engineer, is creating a runbook for diagnosing intermittent failures in the Inventory Service. He's drafted this step: 'Check CPU utilization on all pods.' During a Slack discussion with a junior developer, Sarah asks, 'What metrics should I be looking at *besides* CPU to understand potential bottlenecks?' Mark responds with:
Option A: 'Just CPU – it's the most important metric for performance issues.'
Option B: 'Check network latency between pods and the database. High latency often indicates a bottleneck.'
Option C: 'Review pod logs for errors or unusual patterns. Logs can provide valuable clues.'
Option D: 'The documentation covers all relevant metrics; don't worry about it.'
This question tests understanding of runbook completeness and the importance of considering multiple data points when troubleshooting. Focusing solely on CPU utilization is insufficient – a bottleneck could be elsewhere in the system. The correct answer emphasizes that a good runbook should cover a range of metrics to provide a holistic view, highlighting network latency as a key consideration. Options A and D are incorrect because they present overly simplistic or dismissive approaches.
18 / 22
Mark, a DevOps engineer, is drafting a Slack message to escalate an ongoing incident involving the Payment Processing Service. The current message reads: 'Something's not right with the service.' Which of the following options provides the clearest and most actionable information for his team?
The original message is overly ambiguous. Adding a brief description of the symptoms (e.g., 'intermittent errors') immediately helps the team understand the scope and severity of the problem. While 'Excellent' suggests clarity, it doesn't offer actionable details for investigation. 'Insufficient' correctly identifies the core issue – lack of information – and 'Poor' rightly points out the vagueness.
19 / 22
During a code review, you see a comment on a pull request that says: 'This API call doesn't handle potential network errors gracefully. Add error handling and logging.' What is the primary purpose of this feedback in relation to runbook documentation?
Runbook documentation isn't about prescribing specific code; it's about outlining *processes* and expected behavior. This comment emphasizes the importance of error handling—a crucial aspect documented in runbooks to ensure consistent responses to failures and maintain service stability. The other options misrepresent the role of the comment.
20 / 22
A senior engineer is writing a PR description for a change that updates the schema of an API endpoint. They include the following sentence: 'This update ensures compatibility with the latest version of the Order Processing Service.' What does this statement primarily communicate regarding runbook documentation?
Runbook documentation is about maintaining consistency across systems. This statement highlights that any changes to an API endpoint (like updating a schema) require corresponding updates in related runbooks and procedures to maintain operational coherence. The other options represent tangential considerations or misinterpretations of the update's impact.
21 / 22
Alex is creating a step in a runbook for rolling back a deployment. He writes: 'Restore from latest backup.' What potential issue does this simple instruction *not* address regarding the broader operational context?
While ensuring a valid backup is essential, simply stating 'Restore from latest backup' doesn't address the critical operational considerations of a rollback. A robust runbook should detail verification steps, alignment with disaster recovery plans, and impact analysis on dependent systems—all of which are missing in this instruction.
22 / 22
During a standup update, a developer explains they followed the runbook to restart a failing microservice. The runbook step was: 'Restart the service.' The team asks for more detail. What additional information should be included in the explanation to demonstrate effective runbook usage?
The core purpose of a runbook step is to provide a concise action. A successful runbook update includes demonstrable evidence that the action achieved its intended outcome – in this case, a functioning service. Simply stating 'Restart the service' without confirming it's working doesn't fulfill the runbook's function and leaves room for further investigation.
What does the "Runbook & Operational Procedures — Documentation Types Exercises" exercise cover?
Practice writing clear, actionable runbooks for SRE and DevOps teams: trigger conditions, exact commands, verification steps, rollback procedures, and runbook maintenance. 5 exercises.
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.
How many questions are in "Runbook & Operational Procedures — Documentation Types Exercises"?
This exercise has 22 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Documentation Types exercises?
Browse the full Documentation Types hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.