A rushed switch upgrade skips impact analysis and overnight permit systems go dark. What should impact analysis have provided before the change?

Impact analysis evaluates the operational and security consequences of a proposed change before implementation, including dependencies, downstream services, and potential blast radius. A rushed switch upgrade that skips impact analysis and then darkens overnight permit systems illustrates the failure: nobody mapped that permitting workloads depended on that switch path. Proper impact analysis should have surfaced those effects so the city could schedule differently, add redundancy, or stage the change with stakeholders notified.

Treating impact analysis as a final ransomware negotiation script for the mayor confuses pre-change assessment with incident crisis communications. Claiming it guarantees that no user would ever notice maintenance oversells the artifact—impact analysis informs risk and scheduling; it does not magically erase all user-visible effects. Equating it with automatic approval without a named change owner mixes distinct change-management elements: impact analysis informs decision-makers; approval and ownership remain separate controls.

Exam caveat: SY0-701 expects impact analysis as a forward-looking blast-radius and dependency review, not a synonym for approval, backout, or IR scripts. Municipal services (permits, utilities, public safety) make missed dependencies especially costly.

Operational check: before network upgrades, inventory VLANs, critical apps, batch windows, and public-facing services on the path; involve application owners; document worst-case outage scope; and only then schedule. After near-misses like dark permit systems, update dependency maps so the next impact analysis is evidence-based rather than tribal knowledge.