A critical patch is scheduled for a database server shared by finance, HR, and sales applications. Before the change advisory board approves it, which step identifies the services, users, and risks affected by the change?
Select an answer to reveal the explanation.
Short Explanation
Before you knock down a wall, you'd want to know what's leaning on it. That's impact analysis. Backout plans and test results matter too, but they come after you understand who's going to feel the change.
Full Explanation
Impact analysis examines what a proposed change will affect: dependent applications, business units, users, availability requirements, security posture, and the risk of failure. For a shared database server, it would reveal that finance, HR, and sales depend on the system, identify their peak periods and downtime tolerance, and flag integrations that may break, giving the CAB the information it needs to approve, schedule, or reject the change. A backout plan describes how to reverse the change if it fails; it is essential, but it assumes the impact is already understood and does not itself identify who is affected. Test results show whether the patch functions correctly in a staging environment; they confirm technical behavior but do not enumerate the business services and stakeholders exposed to downtime. Updating the standard operating procedure records how patching should be performed in general; it is a documentation task rather than an assessment of this specific change. Exam caveat: impact analysis is the step that feeds the approval decision, and questions often place it alongside backout planning and testing to see whether you know which one answers who and what is affected. Operational check: confirm the change record lists every dependent application and owner, documents expected downtime, and rates the risk before submission to the CAB.