Domain 3 of 5 · Chapter 3 of 8

Change Management

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing CompTIA Network+ premium course — no separate purchase.

Included in this chapter:

  • The change lifecycle: request to closure
  • Change types and who approves them
  • Scheduling, back-out plans, and validation
  • Exam-pattern recognition

Change types: how risk sets the approval path

AttributeStandard changeNormal changeEmergency change
Risk levelLow, well understoodVariable; must be assessedUrgent; outage or active threat
ApprovalPre-approved (no fresh sign-off)Change advisory board (CAB)Emergency CAB (ECAB), expedited
Timing of approvalOnce, when the procedure was vettedBefore schedulingOften during or after the fix
SchedulingAs neededBooked maintenance windowImmediate
ExampleReplace identical failed patch cableFirmware upgrade on a core switchRoll back a change that took the WAN down

Decision tree

Procedure alreadypre-approved?Standard changeno fresh sign-off neededYesActive outage orurgent threat?NoEmergency changeECAB approves; docs afterYesAssess risk + impact,then approve?NoNormal changeCAB approves before scheduling
Cheat sheet

Cheat sheet

  • Every production change rides one fixed lifecycle: request, assess, approve, schedule, implement, validate, document
  • A change is any add, modify, or remove that could affect production
  • An RFC is the ticket that formally requests and records a change
  • A standard change is low-risk and pre-approved, so it needs no fresh sign-off
  • A normal change is assessed and approved by the CAB before it is scheduled
  • An emergency change fixes an active outage now and is documented afterward
  • The CAB reviews and authorizes changes, it does not implement them
  • The ECAB is the on-call subset of the CAB that approves emergencies fast
  • Higher risk demands heavier approval: standard, normal, emergency
  • Implement approved changes in a scheduled maintenance window
  • Write the back-out plan before you implement, and execute it when a change fails
  • Smaller, reversible changes are safer because rollback is fast
  • Peer-review a complex change before it ships
  • Validate after implementing, then document and close the RFC
  • The RFC and approval record are the audit trail that proves who authorized a change
  • Change management governs the process; configuration management governs the artifacts
  • A change's risk assessment weighs service impact and a rollback plan
  • A standard operating procedure gives repeatable step-by-step instructions

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. AWS Well-Architected Framework — OPS05-BP09 Make frequent, small, reversible changes Well-Architected