Chapter 26 — Cloud and container security: operational handoff
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Why handoff"]
N2["26.2 Runbooks"]
N3["26.3 Owners"]
N4["26.4 Alert routes"]
N5["26.6 Practice"]
N6["Knowledge transfer sessions"]
N7["Ownership agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Why handoff"]
N2["26.2 Runbooks"]
N3["26.3 Owners"]
N4["26.4 Alert routes"]
N5["26.6 Practice"]
N6["Knowledge transfer sessions"]
N7["Ownership agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Why handoff]
|
v
[26.2 Runbooks]
|
v
[26.3 Owners]
|
v
[26.4 Alert routes]
|
v
[26.6 Practice]
|
v
[Knowledge transfer sessions]
|
v
[Ownership agreement]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) prepare work for others to run; (2) write runbooks; (3) identify ownership after placement.
26.1 Why handoff
Priya's placement ends in two months. Her checks must keep running without her. Two months is less time than it sounds, because every check needs a runbook, an owner, an alert route and at least one practice run by someone else. If Priya leaves with the checks undocumented, the nightly inventory and daily baseline check will either stop when something breaks or keep running with nobody reading the results. Either outcome would eventually bring back something like the six-hour advisory search.
26.2 Runbooks
Each check has a runbook: what it does, how to run it, what to do with results, who to contact. Each runbook is short enough to follow during an incident. The inventory runbook, for example, says that the script reads workloads and images from every cluster each night, how to run it by hand, what to do when an unapproved image appears, and that the platform team owns it. Runbooks are stored next to the scripts in the repository, so they change together.
26.3 Owners
The platform team owns the checks; client account managers own client communication. The split of ownership follows who is able to act. The platform team can fix a failing check, rebuild an image or adjust a policy, while account managers already speak to clients and know their change windows. When a finding affects a client, the platform team investigates and the account manager tells the client, using the plain wording the team project developed for the summary page. Both owners are named teams in the handoff pack, not individual people.
26.4 Alert routes
Alerts go to the on-call channel with a link to the runbook. Routing every alert to the on-call channel means somebody is always responsible for reading it, including at night and on holidays. The link to the runbook means the person on call does not need to remember what a new cluster role binding alert requires. Priya checks that each of the alerts from her monitoring work has a runbook entry before handoff. She also sends one test alert to confirm that the channel actually receives it.
26.5 Known limits
The handoff states what the checks do not cover. The limits come from earlier work: the baseline check reads settings but cannot see whether workloads behave safely, the inventory is only as complete as the namespaces it reads, and none of the checks covers application code or client staff accounts. Stating them prevents a passing check from being read as a statement that a client is safe overall. Each limit is written as one plain sentence in the handoff pack, with the reason it exists. The same list later appears in the capstone kit's readme.
26.6 Practice
A colleague runs each check from the runbook alone while Priya watches. Watching without helping shows Priya where the runbooks assume knowledge only she has. When the colleague hesitates or asks a question, she notes the step and rewrites it afterwards, instead of explaining it on the spot and leaving the gap in place. The missing baseline file path in the worked example is one result of these practice runs. Every check is practised at least once by a colleague before the handoff pack is signed off.
Knowledge transfer sessions
Priya runs two short sessions for the platform team: one on the inventory and baseline, one on the pipeline rules and alerts. Each session includes a live run of the check and time for questions. She records the questions and adds answers to the runbooks.
The sessions reveal that some staff did not know the checks existed. A short note in the team channel now announces any new check with a link to its runbook.
Ownership agreement
The platform team lead signs off ownership in writing, so responsibilities are clear after Priya leaves.
Review date
Each runbook has a review date six months ahead.
Handoff timeline
The handoff starts six weeks before the placement ends, leaving time to fix gaps found in practice runs. Starting late is a common reason handoffs fail.
Contacts
The runbooks list Kwame as the escalation contact after Priya leaves, with a backup engineer named for holidays.
Leaving well
Priya's last week is kept free of new work.
Worked example
During practice, a colleague cannot find where the baseline file lives. Priya adds the path and a link to the runbook.
Synthetic case. Handoff is synthetic.
Errors and limits
Handoffs fail when knowledge stays in one person's head.
Exercises
- EX076 — Runbook contents. What does each runbook include? Rubric: 3 = what, how, results, contact; 2 = three; 1 = two; 0 = none.
- EX077 — Owners. Who owns the checks after placement? Rubric: 3 = platform team; 2 = partial; 1 = vague; 0 = none.
- EX078 — Practice gap. What did practice reveal? Rubric: 3 = baseline file path missing; 2 = partial; 1 = vague; 0 = none.
Synthesis
Hand off with runbooks, owners and practice.
Continue studying — chapter 26 of 30
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →