Examkin

Question

Difficulty: HardConfiguration and Change Management

A senior network infrastructure engineer is planning a major architectural revision to implement micro-segmentation policies across an enterprise data center core network. To maintain service availability and comply with IT service management best practices, the engineering team must follow a structured configuration and change management lifecycle. In what chronological order should the engineer execute the change management phases from first to last?

  1. 1Draft a formal Request for Change (RFC) detailing technical specifications, risk assessments, business impact analysis, and a comprehensive rollback plan.
  2. 2Submit the proposed configuration change to the Change Advisory Board (CAB) for formal technical evaluation, risk categorization, and approval.
  3. 3Deploy and test the micro-segmentation policy configurations within a non-production staging environment to validate expected behavior.
  4. 4Broadcast change notifications to impacted business stakeholders and schedule the change within an approved off-peak maintenance window.
  5. 5Apply the configuration changes to the production data center switches during the designated window and perform immediate validation testing.
  6. 6Conduct a Post-Implementation Review (PIR) and update authoritative network documentation and Configuration Management Databases (CMDB).

Answer

The correct chronological sequence begins with drafting the Request for Change (RFC), followed by Change Advisory Board (CAB) approval, staging environment testing, stakeholder notification and maintenance window scheduling, production execution with immediate testing, and concludes with a Post-Implementation Review (PIR) and baseline documentation updates.
A standard change management process begins with drafting a detailed RFC (including risk analysis and rollback plans). Next, the change undergoes formal CAB evaluation and authorization. Once approved, the change is tested in a sandbox or staging environment to ensure technical validity. Following successful testing, maintenance windows are scheduled and notifications sent to stakeholders. The change is then executed in production within the maintenance window, followed immediately by post-change testing. Finally, a PIR is held, and the CMDB and network baselines are updated to reflect the new state.

Step-by-Step Solution

1
Define the change requirements by preparing a detailed Request for Change (RFC).
Establishes technical scope, risk evaluation, and rollback parameters.
Governance requires complete technical documentation before requesting authorization.
2
Present the RFC to the Change Advisory Board (CAB).
Secures organizational authorization and ensures alignment with business risk management.
Unauthorized changes increase network vulnerability and violate IT compliance.
3
Perform sandbox and staging environment validation.
Confirms script syntax, protocol interoperation, and rollback execution under controlled conditions.
Testing mitigates risk before touching production network hardware.
4
Schedule the maintenance window and notify affected stakeholders.
Ensures business alignment and minimizes operational disruption.
Users and operations teams must prepare for planned downtime or potential latency.
5
Execute the change on production devices during the maintenance window.
Applies micro-segmentation configurations and verifies active traffic flow.
Production changes must strictly adhere to the approved execution window.
6
Perform Post-Implementation Review (PIR) and update CMDB baselines.
Finalizes the change record and eliminates configuration drift between physical state and documentation.
Accurate network baselines and logging are required for future troubleshooting and audits.

Key Concept

Standard ITIL-aligned Network Change Management Lifecycle
Rate this question

Topics

Configuration and Change Management

More questions from this topic