Practice runbook vocabulary: prerequisites sections, numbered procedures, decision trees, review dates, and runbook accuracy testing.
0 / 26 completed
1 / 26
A runbook template starts with 'a prerequisites section.' What should this section contain?
The prerequisites section prevents the on-call engineer from getting halfway through a runbook and discovering they lack access or a required tool. It lists everything needed upfront: permissions, CLI tools, environment setup, and pre-conditions — saving critical time during incidents.
2 / 26
Your runbook uses 'numbered steps for the procedure.' Why is numbered formatting important?
During incidents, engineers are under pressure and may be handling multiple communications. Numbered steps provide clear position tracking ('done through step 5'), enable handoff between engineers ('pick up from step 8'), and reduce the cognitive load of tracking where you are in the procedure.
3 / 26
An advanced runbook includes 'a decision tree that guides the on-call engineer.' When is a decision tree more useful than a linear list of steps?
Decision trees shine when the procedure diverges based on observed conditions. A linear runbook handles this awkwardly with 'if/else' prose; a visual or structured decision tree makes the branching obvious, reduces errors, and is faster to follow under pressure.
4 / 26
A runbook header says 'Last reviewed: 2024-01-15.' Why does the review date matter?
Runbooks that are never reviewed become dangerous — systems change, services are renamed or retired, credentials expire, and procedures evolve. The review date helps the on-call engineer assess how much to trust the runbook and flags runbooks that need updating. Many teams require quarterly reviews.
5 / 26
Your team says 'The runbook test verifies the steps are accurate.' What does runbook testing involve?
Runbook testing (often done during game days or scheduled drills) involves actually executing the procedure to verify it works. This finds stale commands, missing environment setup, incorrect API endpoints, and confusing wording — ensuring the runbook is reliable before it's needed under pressure.
6 / 26
Sarah: "Hey team, I'm running this deployment for the new user authentication service. It's failing intermittently – I've checked the logs and nothing obvious stands out. Can someone review my runbook to see if I missed anything?"
Which of the following is the MOST appropriate follow-up question you should ask Sarah to ensure a thorough runbook review, focusing on potential issues *before* she continues deploying?
The correct answer focuses on understanding Sarah's process within the runbook. Asking about the steps she followed and monitored forces her to articulate *how* she applied the documented procedures, revealing potential deviations or omissions that might be causing the intermittent failures. The other options are either too prescriptive (immediately halting), dismissive of the runbook's role, or incorrectly frame the situation – a failure isn't necessarily due to a missed step but could stem from unexpected data or environment variations.
7 / 26
John: "I'm deploying a new feature to production. The runbook says to update the database schema version and restart the API service. I've done both, but the monitoring dashboard is showing high latency. Should I just roll it back?"
This scenario highlights the importance of proactive troubleshooting within a runbook. Simply rolling back immediately might mask an underlying problem and prevent learning from the deployment. The correct answer emphasizes the need to consult the runbook's troubleshooting guidance first – which often includes expected metrics and potential alerts – before resorting to a rollback. It's crucial to understand *why* the issue occurred, not just react to the symptom.
8 / 26
David: "I've drafted a PR description for this rollback. It says 'Rollback database schema to version 20231027 and restart the API service.' Seems straightforward enough."
The PR description needs to be more than just a list of actions. While stating 'Rollback database schema to version 20231027 and restart the API service' is a good start, it doesn't include critical checks like verifying latency or ensuring downstream services are unaffected after the rollback. A robust PR description should explicitly mention these validation steps to prevent further issues during the recovery process; this ensures that the rollback isn't just a technical action but a deliberate attempt to restore stability.
9 / 26
You're reviewing a runbook for a critical service outage. The runbook includes a section titled 'Rollback Actions'. Which of the following is the MOST crucial element to ensure a successful and safe rollback?
The most critical aspect of a rollback action is understanding its potential impact. Option B highlights the need to consider dependencies – failing to do so can lead to cascading failures or data inconsistencies. Options A and D are too simplistic and don't address the complexities of a real-world rollback scenario; option C focuses on communication, which is important but secondary to preventing further damage during the process.
10 / 26
Sarah: "Hey team, I'm running this deployment for the new user authentication service. It's failing intermittently – I've checked the logs and nothing obvious stands out. Can someone review my runbook to see if I missed anything?"
Which of the following is the MOST appropriate follow-up question you should ask Sarah to ensure a thorough runbook review, focusing on potential issues *before* she continues deploying?
The correct answer focuses on understanding Sarah's process within the runbook. Asking about the steps she followed and monitored forces her to articulate *how* she applied the documented procedures, revealing potential deviations or omissions that might be causing the intermittent failures. The other options are either too prescriptive (immediately halting), dismissive of the runbook's role, or incorrectly frame the situation – a failure isn't necessarily due to a missed step but could stem from unexpected data or environment variations.
11 / 26
John: "I'm deploying a new feature to production. The runbook says to update the database schema version and restart the API service. I've done both, but the monitoring dashboard is showing high latency. Should I just roll it back?"
This scenario highlights the importance of proactive troubleshooting within a runbook. Simply rolling back immediately might mask an underlying problem and prevent learning from the deployment. The correct answer emphasizes the need to consult the runbook's troubleshooting guidance first – which often includes expected metrics and potential alerts – before resorting to a rollback. It's crucial to understand *why* the issue occurred, not just react to the symptom.
12 / 26
David: "I've drafted a PR description for this rollback. It says 'Rollback database schema to version 20231027 and restart the API service.' Seems straightforward enough."
The PR description needs to be more than just a list of actions. While stating 'Rollback database schema to version 20231027 and restart the API service' is a good start, it doesn't include critical checks like verifying latency or ensuring downstream services are unaffected after the rollback. A robust PR description should explicitly mention these validation steps to prevent further issues during the recovery process; this ensures that the rollback isn't just a technical action but a deliberate attempt to restore stability.
13 / 26
You're reviewing a runbook for a critical service outage. The runbook includes a section titled 'Rollback Actions'. Which of the following is the MOST crucial element to ensure a successful and safe rollback?
The most critical aspect of a rollback action is understanding its potential impact. Option B highlights the need to consider dependencies – failing to do so can lead to cascading failures or data inconsistencies. Options A and D are too simplistic and don't address the complexities of a real-world rollback scenario; option C focuses on communication, which is important but secondary to preventing further damage during the process.
14 / 26
Sarah: "Hey team, I'm running this deployment for the new user authentication service. It's failing intermittently – I've checked the logs and nothing obvious stands out. Can someone review my runbook to see if I missed anything?"
Which of the following is the MOST appropriate follow-up question you should ask Sarah to ensure a thorough runbook review, focusing on potential issues *before* she continues deploying?
The correct answer focuses on understanding Sarah's process within the runbook. Asking about the steps she followed and monitored forces her to articulate *how* she applied the documented procedures, revealing potential deviations or omissions that might be causing the intermittent failures. The other options are either too prescriptive (immediately halting), dismissive of the runbook's role, or incorrectly frame the situation – a failure isn't necessarily due to a missed step but could stem from unexpected data or environment variations.
15 / 26
John: "I'm deploying a new feature to production. The runbook says to update the database schema version and restart the API service. I've done both, but the monitoring dashboard is showing high latency. Should I just roll it back?"
This scenario highlights the importance of proactive troubleshooting within a runbook. Simply rolling back immediately might mask an underlying problem and prevent learning from the deployment. The correct answer emphasizes the need to consult the runbook's troubleshooting guidance first – which often includes expected metrics and potential alerts – before resorting to a rollback. It's crucial to understand *why* the issue occurred, not just react to the symptom.
16 / 26
David: "I've drafted a PR description for this rollback. It says 'Rollback database schema to version 20231027 and restart the API service.' Seems straightforward enough."
The PR description needs to be more than just a list of actions. While stating 'Rollback database schema to version 20231027 and restart the API service' is a good start, it doesn't include critical checks like verifying latency or ensuring downstream services are unaffected after the rollback. A robust PR description should explicitly mention these validation steps to prevent further issues during the recovery process; this ensures that the rollback isn't just a technical action but a deliberate attempt to restore stability.
17 / 26
You're reviewing a runbook for a critical service outage. The runbook includes a section titled 'Rollback Actions'. Which of the following is the MOST crucial element to ensure a successful and safe rollback?
The most critical aspect of a rollback action is understanding its potential impact. Option B highlights the need to consider dependencies – failing to do so can lead to cascading failures or data inconsistencies. Options A and D are too simplistic and don't address the complexities of a real-world rollback scenario; option C focuses on communication, which is important but secondary to preventing further damage during the process.
18 / 26
Sarah: "Hey team, I'm running this deployment for the new user authentication service. It's failing intermittently – I've checked the logs and nothing obvious stands out. Can someone review my runbook to see if I missed anything?"
Which of the following is the MOST appropriate follow-up question you should ask Sarah to ensure a thorough runbook review, focusing on potential issues *before* she continues deploying?
The correct answer focuses on understanding Sarah's process within the runbook. Asking about the steps she followed and monitored forces her to articulate *how* she applied the documented procedures, revealing potential deviations or omissions that might be causing the intermittent failures. The other options are either too prescriptive (immediately halting), dismissive of the runbook's role, or incorrectly frame the situation – a failure isn't necessarily due to a missed step but could stem from unexpected data or environment variations.
19 / 26
John: "I'm deploying a new feature to production. The runbook says to update the database schema version and restart the API service. I've done both, but the monitoring dashboard is showing high latency. Should I just roll it back?"
This scenario highlights the importance of proactive troubleshooting within a runbook. Simply rolling back immediately might mask an underlying problem and prevent learning from the deployment. The correct answer emphasizes the need to consult the runbook's troubleshooting guidance first – which often includes expected metrics and potential alerts – before resorting to a rollback. It's crucial to understand *why* the issue occurred, not just react to the symptom.
20 / 26
David: "I've drafted a PR description for this rollback. It says 'Rollback database schema to version 20231027 and restart the API service.' Seems straightforward enough."
The PR description needs to be more than just a list of actions. While stating 'Rollback database schema to version 20231027 and restart the API service' is a good start, it doesn't include critical checks like verifying latency or ensuring downstream services are unaffected after the rollback. A robust PR description should explicitly mention these validation steps to prevent further issues during the recovery process; this ensures that the rollback isn't just a technical action but a deliberate attempt to restore stability.
21 / 26
You're reviewing a runbook for a critical service outage. The runbook includes a section titled 'Rollback Actions'. Which of the following is the MOST crucial element to ensure a successful and safe rollback?
The most critical aspect of a rollback action is understanding its potential impact. Option B highlights the need to consider dependencies – failing to do so can lead to cascading failures or data inconsistencies. Options A and D are too simplistic and don't address the complexities of a real-world rollback scenario; option C focuses on communication, which is important but secondary to preventing further damage during the process.
22 / 26
Maria is documenting a runbook for a disaster recovery scenario involving a database outage. The runbook specifies steps to restore from the latest backup and then apply configuration changes. During a code review, another developer comments: 'This section lacks clear rollback criteria. How should we define *when* this restoration process is considered successful?'
The core problem isn't just about restoration; it's about defining success. A robust runbook needs criteria for confirming that the recovery *actually* resolved the issue. Option B correctly identifies that documenting rollback steps alongside the recovery is essential for a complete plan. Options A and C misdirect the focus, while option D ignores the critical aspect of verification.
23 / 26
During a Slack conversation about troubleshooting a deployment failure, Ben says: 'I've followed the runbook exactly – updated the service version and restarted the container. The API is still returning 502 errors.' What's the MOST appropriate next step to discuss based on the runbook's guidance?
Runbooks often include specific troubleshooting steps. Checking the health check endpoint is a good practice but doesn't address the core issue of the API returning errors. Re-running from scratch (option 3) is appropriate as a next step to ensure no unintended changes were introduced. Escalating immediately or focusing solely on log analysis without considering the runbook's structured approach would be less efficient.
24 / 26
You're reviewing a PR description for a rollback action. The description reads: 'Rollback to previous version.' This is insufficient. What additional information should be included in the PR description to align with best practices outlined in the runbook?
A clear PR description must explicitly state *what* is being rolled back. Simply stating 'Rollback to previous version' is ambiguous and leaves room for error. Option 3 provides the necessary detail – the specific database schema version and any related configuration changes – which is crucial for a successful and verifiable rollback.
25 / 26
During a standup meeting, Alex reports: 'I deployed the new payment processing service. The runbook details a rollback procedure in case of issues, but it doesn't specify any automated monitoring or alerting.' What is the MOST important follow-up action to ensure the runbook's effectiveness?
Runbooks are most effective when combined with active monitoring. Adding automated monitoring (option 2) will allow for early detection of problems and prompt the triggering of the rollback procedure before significant impact occurs. Options A, C, and D address related concerns but don't directly improve the runbook's core functionality.
26 / 26
You're reviewing a runbook for a critical service. It includes a section on 'Failover Actions'. A key element of this section is the need to 'Validate Data Integrity Post-Failover.' What does this primarily mean in the context of the runbook?
'Validate Data Integrity' focuses on confirming that the restoration process hasn't introduced any data corruption. This involves running checks to ensure the restored service is functioning correctly and that the data it's handling matches expectations. Option A describes redirection, while C and D represent other aspects of failover management.
What does the "Runbook Vocabulary" exercise cover?
Practice runbook vocabulary: prerequisites sections, numbered procedures, decision trees, review dates, and runbook accuracy testing.
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 Vocabulary"?
This exercise has 26 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.