A change ticket to replace a load balancer certificate has no named owner, and the application team whose mobile app relies on certificate pinning was never notified. After the change, the mobile app stops connecting. Which change management elements were missing?
Select an answer to reveal the explanation.
Short Explanation
Every change needs a driver and a guest list. Nobody owned this one, and the people who'd get hurt by it never got the invite. Once you spot both of those gaps in the story, the other choices are just noise.
Full Explanation
Change management assigns an owner who is accountable for the change from request through validation, and it identifies stakeholders, meaning the people, teams, and systems affected by the change, so they can review, prepare, and test. The certificate replacement had no owner to drive impact discussions, and the mobile application team that pinned the old certificate was not consulted, so no one updated the app or planned a coordinated rollout. Version control and diagram updates support tracking and documentation; they would record what changed but would not have alerted the mobile team to a breaking dependency. A maintenance window and restart planning control timing and downtime, yet the failure would have occurred whenever the certificate changed because the pinned app was never prepared. Allow list updates and restricted activities concern technical constraints such as which applications or actions are permitted during the change, which do not address the missing communication. Exam caveat: ownership and stakeholders are business-process elements of change management, distinct from technical implications such as downtime, restarts, and dependencies, though good stakeholder identification often surfaces those dependencies. Operational check: require every change ticket to name an owner and list affected stakeholders before it reaches the CAB, and confirm stakeholder sign-off for changes touching certificates, authentication, or shared infrastructure.