A security team disables TLS 1.0 on an internal web server. A legacy reporting application that connects to the server stops working because it supports only TLS 1.0. Which change management activity would MOST likely have caught this before the change?
Select an answer to reveal the explanation.
Short Explanation
Pulling a brick out of a wall is fine until you find out something was resting on it. Impact analysis is where you go looking for what's resting on it, especially those old legacy apps. Diagrams and version control only tell you what happened after the wall moved.
Full Explanation
Impact analysis evaluates what a change will affect before it is approved, including dependencies between systems and the limitations of legacy applications. Disabling an old protocol version is a sound hardening step, but any client that cannot negotiate a newer version will fail to connect. Inventorying which applications connect to the server and which protocol versions they support would have revealed the legacy reporting tool and allowed the team to upgrade it, isolate it, or document a temporary exception before enforcement. Updating the network diagram is a documentation step performed after a change; it does not reveal compatibility problems in advance. Version control records configuration history and enables rollback, which helps recovery but not discovery of the dependency. A maintenance window reduces the business impact of the change by timing it carefully, yet the application would still fail whenever the protocol was disabled. Exam caveat: legacy applications and dependencies are named technical implications of change management, and questions frequently pair them with protocol deprecation or patching scenarios. Operational check: before disabling a protocol version, review server connection logs for clients still negotiating it, contact the owners of those applications, and enforce the change only after each dependency is remediated or formally excepted.