Domain 3.0 | Network Operations — 19% of exam
Learning Objectives
By the end of this lesson, you will be able to:
- Explain the purpose of a formal change management process and why unstructured changes are risky
- Describe the role of a change advisory board (CAB) in reviewing and approving changes
- Explain configuration baselines and configuration drift
- Describe the importance of configuration backups and version control for network devices
- Recognize common change and configuration management failures
Key Terms
| Term | Definition |
|---|---|
| Change Management | A formal process for proposing, reviewing, approving, and implementing changes to a network in a controlled way |
| Change Advisory Board (CAB) | A group responsible for reviewing and approving significant proposed changes before they’re implemented |
| Configuration Baseline | The known-good, documented configuration state of a device at a point in time |
| Configuration Drift | Gradual, undocumented deviation of a device’s actual configuration away from its established baseline |
| Rollback Plan | A predefined procedure for reverting a change if it causes unexpected problems |
Explanation
Documentation Feeds Change Management
The previous lesson covered documentation as a standalone practice. This lesson shows why that documentation actually matters day to day: every properly managed change should update the relevant documentation as part of the process, and every properly documented network makes it far easier to evaluate whether a proposed change is safe in the first place.Why Change Management Exists
A huge share of network outages aren’t caused by hardware failure or external attacks — they’re caused by a change someone made, without enough review, that had an unexpected side effect. Change management exists to reduce exactly this risk: instead of an administrator making a configuration change whenever they judge it necessary, changes go through a structured process of proposal, review, approval, scheduling, and implementation.
This isn’t about slowing everything down for its own sake. It’s about making sure that before a change touches a production network, someone has actually thought through what else that change might affect, whether the timing avoids disrupting critical business activity, and what the plan is if something goes wrong.
The Change Management Process
A typical formal change management process includes several distinct stages:
- Request submission — the proposed change is documented: what’s changing, why, and what systems it affects.
- Impact and risk assessment — someone evaluates what could go wrong and how severe the consequences would be if it did.
- Approval — a change advisory board (CAB) reviews significant changes, weighing the benefit against the risk before authorizing implementation.
- Scheduling — approved changes are typically implemented during a defined maintenance window, minimizing disruption to normal operations.
- Implementation with a rollback plan — the change is made, with a predefined plan ready in case it needs to be reversed quickly.
- Post-change review and documentation update — the outcome is verified, and relevant documentation is updated to reflect the new state.
Skipping any of these stages reintroduces exactly the risk the process exists to manage — an unreviewed change is essentially a bet that nothing unexpected will happen, made without the benefit of anyone else’s perspective on what might.
The Change Advisory Board (CAB)
The CAB is the group — often spanning multiple teams or departments — responsible for reviewing significant proposed changes before they’re approved. Its job is to catch problems a single engineer focused on their own piece of the system might miss: does this change conflict with another change planned for the same window, does it affect a system another team depends on, is the proposed timing genuinely low-risk for the business.
Not every change needs to go through the full CAB process — routine, well-understood, low-risk changes are often pre-approved under a standard change category. But genuinely urgent situations call for an emergency change process: a faster path for fixing an active, serious problem, typically with expedited or after-the-fact approval rather than the full standard review, precisely because waiting for a normal review cycle isn’t realistic when something is actively broken.
Configuration Baselines and Drift
A configuration baseline is the documented, known-good configuration state of a device — what it should look like when everything is working as intended. Over time, without discipline, real device configurations tend to quietly diverge from that baseline: someone makes a quick, undocumented tweak to fix an immediate problem, a temporary change never gets reverted, a setting gets adjusted during troubleshooting and forgotten. This gradual, undocumented deviation is called configuration drift.
Configuration drift is dangerous precisely because it’s invisible until something breaks — a device that’s drifted away from its documented baseline behaves differently than the documentation says it should, which can turn a routine troubleshooting effort into a much longer investigation, since the assumption that “the config matches the documentation” turns out to be false.
Configuration Backups and Version Control
Regularly backing up device configurations — and especially backing up immediately before and after any planned change — gives you a concrete point-in-time record to compare against and, if needed, restore. Version control for configurations takes this further: keeping a full history of configuration states over time, not just the most recent backup, so a specific prior state can be identified and restored even if several changes have happened since.
This is what actually makes a rollback plan realistic rather than theoretical: a rollback plan that says “revert to the previous configuration” only works if a genuine, verified backup of that previous configuration actually exists.
Recognition-Level Verification Concepts
A few patterns are worth recognizing on sight:
- A proposed change document listing scope, risk assessment, and a rollback plan, awaiting sign-off, is going through formal change management review.
- A device behaving differently than its documented baseline suggests, with no record of why, points to configuration drift.
- An urgent fix implemented immediately with approval sought afterward describes an emergency change process, not a bypass of change management entirely.
- A configuration backup taken immediately before a scheduled change is exactly what makes a rollback plan actionable rather than aspirational.
Common Exam Traps
- Change management isn’t about preventing change — it’s about controlling risk around change. A well-run process still allows changes to happen; it just ensures they’re reviewed and reversible first.
- An emergency change process is a faster path through change management, not an exemption from it. Approval still happens — often just after the fact rather than before.
- Configuration drift is dangerous specifically because it’s undocumented and gradual, not because any single change was necessarily wrong on its own.
- A rollback plan is only as good as the backup behind it. Having a stated intention to “roll back if needed” without an actual verified backup isn’t a real rollback plan.
- A configuration baseline is a reference point, not a one-time snapshot that’s assumed to stay accurate forever. Baselines need to be updated deliberately when a change is approved, or the baseline itself becomes stale.
Lesson 3.1.2 Practice Quiz — Change & Configuration Management
17 questions covering the change management process, CAB approval, emergency changes, configuration baselines, drift, and backups.
N10-009 · Domain 3.1Summary
Change management is a formal process — request, impact assessment, approval, scheduling, implementation, and review — that reduces the risk of unreviewed changes causing unexpected outages.
A change advisory board (CAB) reviews significant proposed changes, weighing risk against benefit before approval; an emergency change process provides a faster path for urgent fixes.
A configuration baseline documents a device's known-good state; configuration drift is the gradual, undocumented deviation from that baseline over time.
Regular configuration backups, especially before and after changes, combined with version control history, make rollback plans genuinely actionable rather than aspirational.
Skipping stages of change management — or letting configuration drift go unaddressed — reintroduces exactly the risk the process exists to prevent.
