Soru

Zorluk: ZorConfiguration and Change Management

A network engineering team needs to upgrade the firmware and security policy configuration on a mission-critical, active/passive high-availability (HA) firewall pair. To adhere to enterprise change management best practices while ensuring minimal risk of unapproved downtime, in what sequence should the engineer execute these implementation steps?

  1. 1Submit a formal Request for Change (RFC) containing risk assessments, sandbox test results, maintenance window schedules, and explicit rollback triggers.
  2. 2Secure authorization from the Change Advisory Board (CAB) and notify affected business stakeholders of the scheduled maintenance window.
  3. 3Apply the updated firmware and policy configurations to the passive standby firewall within the maintenance window.
  4. 4Initiate a controlled failover to promote the updated unit to active status and validate network traffic against performance baselines.
  5. 5Update the secondary appliance, restore high-availability synchronization, and submit the final post-implementation review (PIR) for RFC closure.

Cevap

The correct sequence starts with submitting the Request for Change (RFC), followed by obtaining Change Advisory Board (CAB) approval, applying changes to the passive standby firewall unit first, executing a controlled failover for live traffic validation, and finally updating the secondary appliance while completing post-implementation documentation.
Standard enterprise change management mandates that planning and RFC submission occur first, followed by CAB evaluation and approval. During implementation on redundant systems, applying updates to the standby system minimizes operational risk. Once the standby unit is updated, initiating a controlled failover enables production traffic validation against baselines while retaining an un-upgraded fallback. Finally, updating the secondary device, verifying HA sync, and completing a post-implementation review finishes the change lifecycle.

Adım Adım Çözüm

1
Formulate and submit the Request for Change (RFC).
The proposed technical modification, rollback plan, sandbox test logs, and maintenance window are documented.
Enterprise policy requires all production changes to be fully planned and documented prior to review.
2
Obtain Change Advisory Board (CAB) authorization.
Formal business approval is granted and affected teams are scheduled for potential maintenance impacts.
Changes cannot be implemented in production without explicit organizational authorization.
3
Implement configuration changes on the passive appliance during the maintenance window.
The standby node receives the new firmware/policy without disrupting active production traffic.
Modifying the passive node first insulates active production sessions from potential update failures.
4
Perform a controlled HA failover and conduct baseline health verification.
Live traffic passes through the newly updated unit while the non-updated unit serves as an immediate, un-upgraded failback option.
Validation against performance baselines confirms system health under real operational loads.
5
Upgrade the second appliance, verify HA cluster state synchronization, and close the RFC with a Post-Implementation Review (PIR).
Both firewalls run identical baseline configurations with synchronized state tables, and change management documentation is complete.
Closing out the change management lifecycle ensures documentation remains accurate and baseline records reflect the new operational state.

Anahtar Kavram

High-Availability Network Change Management Lifecycle
Bu soruyu puanla