Soru

Zorluk: OrtaConfiguration and Change Management

A network engineering team needs to upgrade the operating system across core firewall pairs to patch a critical zero-day vulnerability. Place the standard change management stages in the correct chronological order from first to last.

  1. 1Draft and submit a formal Request for Change (RFC) detailing technical scope, risk evaluation, and rollback steps.
  2. 2Present the RFC to the Change Advisory Board (CAB) for impact assessment and formal authorization.
  3. 3Validate the update in a non-production sandbox environment and broadcast the approved maintenance window.
  4. 4Deploy the software update during the maintenance window and perform post-change verification testing.
  5. 5Conduct a post-implementation review (PIR), update configuration baselines, and close the change ticket.

Cevap

The correct chronological order for the change management lifecycle is: (1) Draft and submit a formal RFC, (2) Present the RFC to the CAB for review and approval, (3) Perform sandbox testing and broadcast the maintenance window, (4) Deploy updates during the maintenance window and conduct verification testing, and (5) Perform a post-implementation review, update baseline documentation, and close the ticket.
The standard network change management process follows a clear administrative and operational sequence: initial request documentation (RFC creation), administrative governance (CAB authorization), staging and scheduling (sandbox testing and maintenance window notification), active implementation (deployment and post-change testing), and final administrative closure (post-implementation review and baseline updating).

Adım Adım Çözüm

1
Identify the initial documentation stage.
The network team initiates the change process by creating an RFC with risk and rollback documentation.
Formal change control requires a documented RFC before stakeholder evaluation can begin.
2
Identify the authorization stage.
The RFC is submitted to the CAB for organizational review and approval.
CAB approval ensures that business and operational risks are acceptable before scheduling downtime.
3
Identify the staging and scheduling stage.
The change is pre-tested in a lab environment and stakeholders are informed of the maintenance window.
Technical validation and scheduling take place after authorization but prior to active deployment.
4
Identify the execution stage.
The change is implemented during the approved window and core functionality is verified.
Deployments must adhere strictly to scheduled windows to prevent unexpected outages.
5
Identify the post-change closure stage.
The post-implementation review is completed, baselines are updated, and the change ticket is closed.
Documenting final configuration states ensures audit compliance and maintains updated network baseline records.

Anahtar Kavram

Standard Network Change Management Lifecycle
Bu soruyu puanla