Key roles in incident response

WHAT THIS TESTS: Whether you understand that effective incident response separates coordination from execution, drawing on Incident Command System principles, so a major incident does not devolve into chaos.

A GOOD ANSWER COVERS: The Incident Commander (IC) is the single coordinator and decision-maker. They run the response, set priorities, delegate tasks, track the current state, and decide on actions like declaring severity or escalating; crucially, the IC does not do hands-on debugging, because their job is to keep the whole response organized and ensure nothing is dropped. The Communications Lead owns internal stakeholder updates and external or customer communication, freeing responders to focus. The Operations Lead and Subject Matter Experts (SMEs) are the hands-on responders who investigate, form hypotheses, and apply fixes; SMEs bring deep knowledge of specific systems. A Scribe maintains a timestamped record of events, decisions, and actions for the postmortem. For small incidents one person may wear several hats, but for major incidents the separation prevents the common failure where everyone debugs and no one coordinates or communicates.

COMMON WRONG ANSWERS: Making the IC the primary fixer, which leaves coordination unowned. Forgetting communications, so stakeholders flood responders with questions. Having no clear single decision-maker, leading to conflicting actions, or no scribe, so the postmortem timeline is guesswork.

LIKELY FOLLOW-UPS: When do you escalate from a single responder to a full command structure? How does the IC hand off during a long incident? What authority does the IC have over engineers from other teams?

ONE CONCRETE EXAMPLE: During a major outage, the IC declares SEV1, assigns an SME to investigate the database, asks the Operations Lead to prepare a rollback, has the Communications Lead post a status-page update, and the scribe logs every decision with timestamps. The IC never touches a terminal, keeping a clear view of the whole response.