After a successful network change, diagrams and procedures are left stale, and later incident responders work from outdated maps. Which change-management requirement was neglected?
Select an answer to reveal the explanation.
Short Explanation
If the map still shows the old bridge, the next fire truck goes the wrong way — same for stale network diagrams after a change. Write down what you changed and version it, or responders inherit a fiction.
Full Explanation
Change management includes updating related documentation—network diagrams, procedures, and version-controlled runbooks—after successful changes so operations and incident response reflect reality. When diagrams and procedures stay stale after a network change and later responders work from outdated maps, the neglected requirement is that post-change documentation update. Wrong maps send firewalled troubleshooting, failovers, and containment down dead ends during civic incidents.
Immediate destruction of all prior diagrams to reduce classification clutter is reckless: history belongs in version control with appropriate handling, not mass deletion that erases rollback and audit context. Replacing documentation updates with a single unrecorded verbal briefing fails durability—shift workers and future IR teams cannot rely on hallway conversation. Deferring all documentation until the next annual audit guarantees prolonged drift between the living network and the binders responders trust.
Exam caveat: SY0-701 treats documentation updates as part of change closeout, alongside approval, impact analysis, and backout. Passing the technical cutover without updating artifacts is an incomplete change.
Operational check: make "docs updated" a mandatory closeout checkbox for municipal network changes; store diagrams in version control; note change ticket IDs on revisions; and spot-check that NOC/SOC packets match production before the next incident drills—so the next outage is fought with current maps, not last year's topology.