3 exercises — practise the high-stakes verbal phrases used during live P1 incident calls.
0 / 12 completed
1 / 12
Your team has just joined the incident bridge call. The Incident Commander has not been declared yet. Which statement correctly assigns the role?
Option B establishes control clearly and immediately. An effective IC declaration:
• Announces the assumption of the IC role — no ambiguity about who is driving • Assigns the Comms Lead — one person owns external/internal status updates • Addresses SMEs — sets expectations without micromanaging • Manages the call — asks non-essential listeners to mute
Standard bridge roles: • IC (Incident Commander) — drives the call, makes decisions, is the single source of authority • Comms Lead — posts status updates (Slack, status page, email), talks to customers • SME (Subject Matter Expert) — database, infra, app layer experts who answer technical questions • Scribe — logs the timeline in real-time
Ambiguous starts waste critical minutes. The IC must be declared before any technical discussion begins.
2 / 12
During a bridge call, the database load is still climbing and nothing is working. Which statement correctly calls a rollback?
Option C is the professional standard for declaring a rollback on a bridge call. It contains every required element:
• "I'm calling a rollback" — explicit, unambiguous decision (not a suggestion, not a question) • Target build specified — "to build 2024.01.10a" — everyone knows the target state • ETA given — "8 minutes to stable" — sets expectations for the call and for the Comms Lead • Scribe instruction — timestamp the event for the incident timeline • Comms instruction — update the status page/Slack immediately
A rollback on a P1 bridge call is a high-stakes, time-sensitive decision. The IC calls it — not asks for consensus. Phrases like "maybe we should think about" or "what does everyone think" waste time and dilute authority. Saying "someone roll it back" without a target build or ETA creates confusion.
3 / 12
After 47 minutes of P1 incident work, all services are responding normally. Which message correctly declares resolution on the bridge call?
Option C is the complete all-clear. A proper resolution declaration on the bridge includes:
• Evidence of recovery — "monitoring is green, error rate back to baseline at 0.04%" — not just "looks good" • Explicit resolution declaration — "I am declaring this incident resolved" — unambiguous close • UTC timestamp — "at 16:19 UTC" — logged for MTTR calculation and the post-mortem • Comms Lead instruction — update the status page and Slack officially • Scribe instruction — close the incident timeline • Acknowledgement — thank the team (important for morale) • Post-mortem commitment — schedule it immediately while details are fresh
The incident is not "resolved" until the IC declares it resolved with evidence. Fuzzy language ("we're probably fine", "I think it's up") leaves the team in a grey zone and makes MTTR calculation and the post-mortem harder.
4 / 12
Sarah from the observability team just posted this Slack message: 'Looks like a spike in API calls to /users. Maybe it's a new feature rollout?' What is the most appropriate response for a developer on the backend team?
The Slack message indicates a potential issue with API calls. The best response acknowledges this and suggests further investigation – simply stating 'great catch' is passive. A DDoS attack needs immediate security notification, and reporting a frontend bug isn't directly relevant to the observed symptom. Investigating the root cause of the spike is key.
5 / 12
Mark, during a bridge call regarding a failing microservice, writes in his PR description: 'Fixed the issue. Code is now working.' This statement needs improvement. Which of the following options best describes what Mark should add to ensure clarity and accountability?
Mark's statement is too vague. While technically correct that the code *is* working, it doesn't provide context for the incident or outline how the problem was resolved. The best option provides details about the root cause and acknowledges potential ongoing issues – a crucial element of post-incident communication.
6 / 12
Sarah from the observability team just posted this Slack message: 'Looks like a spike in API calls to /users. Maybe it's a new feature rollout?' What is the most appropriate response for a developer on the backend team?
The Slack message indicates a potential issue with API calls. The best response acknowledges this and suggests further investigation – simply stating 'great catch' is passive. A DDoS attack needs immediate security notification, and reporting a frontend bug isn't directly relevant to the observed symptom. Investigating the root cause of the spike is key.
7 / 12
Mark, during a bridge call regarding a failing microservice, writes in his PR description: 'Fixed the issue. Code is now working.' This statement needs improvement. Which of the following options best describes what Mark should add to ensure clarity and accountability?
Mark's statement is too vague. While technically correct that the code *is* working, it doesn't provide context for the incident or outline how the problem was resolved. The best option provides details about the root cause and acknowledges potential ongoing issues – a crucial element of post-incident communication.
8 / 12
John from the support team is reporting a high error rate on the production deployment of the new payment service. During the initial bridge call, he says, 'The system's completely down! We need to roll it back!' Which action should David, the lead engineer, take FIRST?
The primary goal during an initial incident bridge call is to understand the scope. David should first ask for details – what's failing? Who's affected? This prevents wasted effort and ensures a targeted response. Rolling back immediately without understanding the root cause could mask underlying problems or lead to data loss. Option D is premature escalation.
9 / 12
Emily, an SRE, sends this Slack message during a prolonged outage: 'CPU usage on the database server has spiked to 98%. We're seeing increased query latency.' Which of the following responses is MOST appropriate for a developer investigating the issue?
The developer needs actionable information. Emily's message highlights a specific symptom – high CPU and query latency. Asking for the SQL queries is crucial to pinpointing the source of the problem. Option A is dismissive; option B is appropriate; options C and D are speculative and don't address the immediate issue.
10 / 12
Ben writes this comment on a code review for a fix to a failing API endpoint: 'This looks good. The endpoint is now returning 200 OK.' Which of the following revisions would be MOST beneficial to add to Ben's comment?
Ben's comment is technically correct but lacks sufficient detail. While verifying data fields and response times are important, the *most* crucial aspect is confirming that the fix addresses the underlying root cause of the error. Simply returning a 200 OK doesn't guarantee stability or prevent future issues. Options C and D are tangential.
11 / 12
Lisa, during a bridge call regarding a failing microservice, states: 'I've deployed the hotfix! Code is now working.' What additional information should she provide to ensure the incident is truly resolved?
While 'code is now working' suggests a resolution, it's insufficient. Lisa needs to demonstrate that the fix has been validated through testing. Automated tests provide objective evidence of functionality. Monitoring logs and rolling back are important follow-up steps, but not the initial confirmation of resolution.
12 / 12
Tom, a developer, is updating his PR description after resolving an issue with a third-party API integration: 'Fixed the intermittent connection errors. The API is now responding reliably.' Which of the following statements BEST describes what Tom should add to this description?
Tom's description is still incomplete. While confirming reliable responses is good, he needs to detail *how* the issue was fixed – specifically, the version upgrade of the API client library. This provides context for future troubleshooting and dependency management. Options B, C, and D add valuable details but aren't the primary focus in this situation.
What will I practise in "War Room & Bridge Call Language — Incident Response English Exercise"?
Practice the exact professional phrases used on incident bridge calls: declaring the IC role, calling a rollback, and announcing all-clear. 3 advanced exercises.
How many exercises are in this module?
This module has 12 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
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.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Incident Response exercises?
Browse the full Incident Response hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.