This chapter covers change and configuration management, a critical domain in network operations that ensures network stability, security, and compliance. For the N10-009 exam, approximately 10-15% of questions touch on change management processes, configuration management tools, and related documentation. You will learn the formal change request lifecycle, configuration management databases (CMDB), rollback procedures, and best practices for maintaining network documentation. Mastery of this topic is essential not only for the exam but for real-world network administration, as unmanaged changes are a leading cause of network outages.
Jump to a section
Imagine an airline company operating hundreds of flights daily. Every flight requires a formal flight plan filed with air traffic control before departure. This plan specifies the route, altitude, fuel load, departure time, and backup airports. Once filed, the plan is reviewed, approved, and becomes the baseline for that flight. Any deviation—a change in altitude, a reroute due to weather, or a delay—requires a formal amendment that must be approved by dispatch and ATC. The original plan is never modified without documentation; instead, an amendment is created, logged, and communicated to all stakeholders (pilots, cabin crew, ground staff). After the flight, a post-flight review compares actual performance to the plan, identifying discrepancies for future improvement. This mirrors change management: a baseline configuration is documented, changes are proposed, reviewed, approved, tested, and implemented with a rollback plan. Without this process, flights (or networks) become chaotic—unapproved changes cause incidents, and nobody knows the current state. The analogy breaks down slightly because airlines have stricter regulatory oversight, but the core principle of controlled, documented changes preventing disaster is identical.
What is Change and Configuration Management?
Change and configuration management are two interrelated disciplines that govern how network devices and services are modified and tracked over time. Change management focuses on the process of proposing, reviewing, approving, implementing, and reviewing changes to the network infrastructure. Configuration management focuses on maintaining a known, consistent state of device configurations and network topology. Together, they form the backbone of network operations (N10-009 Objective 3.2).
Why It Exists
Networks are dynamic. Software updates, security patches, hardware replacements, policy changes, and capacity upgrades are constant. Without a formal process, changes can be made ad hoc, leading to misconfigurations, security vulnerabilities, and outages. The primary goals are: - Reduce outages caused by unauthorized or poorly tested changes. - Maintain compliance with regulations (e.g., PCI-DSS, HIPAA) that require documented change processes. - Enable troubleshooting by providing a clear history of what changed and when. - Support auditing by allowing review of who approved and implemented changes.
The Change Management Process (Step-by-Step)
Request for Change (RFC) – A formal request is submitted describing the proposed change, rationale, scope, risk assessment, and rollback plan. The RFC includes:
- Change identifier (unique number) - Description of change - Reason for change (problem, improvement, new requirement) - Risk level (low, medium, high) - Impact assessment (which devices, services, users) - Rollback plan (steps to revert) - Planned start and end time (change window)
Change Review – A Change Advisory Board (CAB) or designated authority reviews the RFC. The CAB evaluates:
- Technical feasibility - Risk vs. benefit - Resource availability - Scheduling conflicts with other changes - Compliance with policies
Approval – The change is approved, rejected, or returned for modifications. Approval may require sign-off from multiple stakeholders (e.g., security team for firewall changes).
Implementation – The change is executed during a planned change window (often a maintenance window outside business hours). The implementer follows the documented steps, and changes are logged.
Testing and Validation – After implementation, the change is tested to confirm it works as intended. This may include connectivity tests, performance monitoring, and security scans.
Post-Implementation Review (PIR) – After a predefined period (e.g., 24-72 hours), the change is reviewed to ensure no negative side effects. Lessons learned are documented.
Update Configuration Management Database (CMDB) – All changes are recorded in the CMDB, which tracks the desired state of each device and the history of changes.
Configuration Management Tools and Concepts
Configuration management ensures that network devices are configured consistently and that any deviations are detected and corrected. Key tools include:
Configuration Management Database (CMDB): A repository that stores information about all managed assets and their relationships. It includes device models, software versions, interface configurations, and change history.
Version Control Systems (e.g., Git, RANCID, Oxidized): These tools store device configurations in a version-controlled repository, allowing comparison of configurations over time and rollback to a previous version.
Automated Configuration Tools (e.g., Ansible, Puppet, Chef, SaltStack): These tools define desired configurations as code (Infrastructure as Code) and enforce them across devices. They can push changes, validate compliance, and remediate drift.
Configuration Backup: Regular automated backups of device configurations are essential. Backups should be stored securely and tested for restore ability.
Change Management Documentation
Documentation is a key exam topic. The following documents are commonly tested:
Network Diagram: Logical and physical topology diagrams showing devices, connections, IP addressing, and VLANs.
IP Address Management (IPAM): Spreadsheet or tool tracking IP address assignments, subnets, and DHCP scopes.
Wiring and Port Labels: Physical labeling of patch panels, cables, and switch ports.
Standard Operating Procedures (SOPs): Step-by-step instructions for common tasks like adding a VLAN or replacing a router.
Baseline Configuration: The known good configuration for each device type, used as a reference for compliance checks.
Rollback Procedures
Every change must have a rollback plan. Common rollback methods include:
Restore previous configuration: Reload the last known good configuration from backup.
Undo commands: For changes made via CLI, the reverse commands are executed (e.g., no commands in Cisco IOS).
Load firmware version: If a firmware upgrade fails, reload the previous version.
Hardware swap: If a hardware component is replaced and fails, reinstall the original component.
Interaction with Related Technologies
Change management interacts with: - Network Monitoring (NMS): Alerts from NMS may trigger changes. Post-change monitoring validates success. - Security Policies: Changes to firewalls, ACLs, and VPNs must be reviewed by security teams. - ITIL/ITSM Frameworks: Many organizations follow ITIL best practices for change management, including incident, problem, and change management integration.
Exam-Relevant Details
The CAB typically includes representatives from network, security, operations, and application teams.
Emergency changes can bypass normal review but require retroactive documentation and approval.
Standard changes are pre-approved, low-risk changes (e.g., adding a user VLAN) that follow a predefined procedure.
Normal changes require full review and approval.
Change windows are typically scheduled during low-traffic periods; common windows are Sunday 2:00 AM – 6:00 AM.
The CMDB should be updated after every change; failure to do so leads to configuration drift.
Configuration drift occurs when a device's running configuration differs from the intended baseline due to unapproved changes or failed automation.
Command Examples (Cisco IOS)
While the exam does not require memorizing specific commands for change management, understanding how configurations are saved and backed up is helpful:
! Save running config to startup config
copy running-config startup-config
! Backup config to TFTP server
copy running-config tftp://192.168.1.100/backup.cfg
! Restore config from backup
copy tftp://192.168.1.100/backup.cfg running-config
! Compare two configs (using show archive)
show archive config differencesFor version control, tools like RANCID or Oxidized automate the collection of configs into a Git repository, allowing git diff to show changes.
Summary of Key Numbers and Terms
RFC: Request for Change
CAB: Change Advisory Board
CMDB: Configuration Management Database
PIR: Post-Implementation Review
SOP: Standard Operating Procedure
IPAM: IP Address Management
Change types: Standard, Normal, Emergency
Risk levels: Low, Medium, High
Change window: Typically 4-hour maintenance window
Rollback: Must be defined before implementation
Configuration drift: Deviation from baseline
Initiate RFC Submission
The process begins when a stakeholder identifies a need for change (e.g., a security vulnerability patch). The requester fills out an RFC form, which includes a unique ID, description, justification, risk assessment, impact analysis, implementation plan, and rollback steps. The RFC is submitted to the change manager or directly to the CAB. At the packet level, this is purely a human-driven process, but in automated systems, an RFC may be generated via a ticket system (e.g., ServiceNow). A network engineer would observe the ticket creation and assignment.
CAB Review and Approval
The CAB meets (often weekly) to review all pending RFCs. Each change is evaluated for technical soundness, risk, resource availability, and scheduling conflicts. The CAB may approve, reject, or request modifications. For high-risk changes, additional approvals from security or compliance teams may be required. In the network, no traffic changes occur yet. The engineer monitors the ticket status for approval. If approved, a change window is assigned.
Implement Change During Window
During the scheduled change window, the assigned engineer executes the implementation plan. This may involve logging into devices via SSH, applying configuration commands, or running automation scripts. For example, adding a VLAN on a switch: `vlan 100`, `name Sales`, `exit`, then assigning interfaces. The engineer should capture before-and-after states (e.g., `show running-config`). At the protocol level, changes take effect immediately; spanning tree recalculation may occur if VLANs change. The engineer monitors logs for errors.
Test and Validate Change
After implementation, the engineer tests to confirm the change works as intended. This includes connectivity tests (ping, traceroute), service checks (e.g., web server reachability), and performance checks (latency, throughput). For a VLAN addition, test that devices in the new VLAN can communicate with their gateway. If tests fail, the rollback plan is executed. Validation may also include checking monitoring tools (e.g., SNMP traps, syslog) for alarms. The engineer documents test results in the ticket.
Post-Implementation Review
After a predefined period (e.g., 24 hours), the change is reviewed. The engineer checks for any negative impact: increased error rates, performance degradation, or security incidents. If no issues, the change is closed. The CMDB is updated to reflect the new configuration baseline. Lessons learned are documented. For exam purposes, remember that PIR is essential for continuous improvement. A network engineer would verify that the CMDB now shows the new VLAN and that backup configurations are current.
Enterprise Scenario 1: Firewall Rule Change in a Financial Institution
A bank needs to open a new port for a third-party payment processor. The change is classified as high risk because firewall misconfigurations could expose sensitive data. The RFC is submitted detailing the exact source/destination IPs, ports, and protocol. The CAB includes the network security team, who review the rule against the principle of least privilege. After approval, the change is implemented during a Sunday maintenance window. The engineer uses a script to add the rule and then tests connectivity from a test host. The monitoring team watches for unusual traffic patterns. Post-implementation, the rule is logged in the CMDB, and a backup of the firewall config is taken. A common issue: if the rule is placed too early in the ACL, it may inadvertently allow other traffic; thus, rule order is critical. The rollback plan is simply to remove the rule or reload the previous config.
Enterprise Scenario 2: Router Firmware Upgrade in a Service Provider
A service provider upgrades IOS on core routers to fix a BGP bug. The change is planned weeks in advance. The RFC includes the new firmware version, release notes, and a rollback plan to reload the old image. During the change window, the engineer downloads the new image to the router, sets the boot variable, and reloads. If the router fails to boot the new image, the engineer uses the ROMMON to boot from the old image. After successful boot, BGP sessions are verified. A common pitfall: the new image may have different default behaviors (e.g., changed timers), causing BGP flapping. The engineer must adjust configurations accordingly. The CMDB is updated with the new firmware version.
Scenario 3: Adding a New VLAN in a Campus Network
A university adds a new research VLAN. The change is standard (low risk) because it follows a pre-approved template. The engineer creates the VLAN on the distribution switch, configures the SVIs, and sets up DHCP relay. The change is implemented during a weekday maintenance window. Testing includes verifying that hosts in the new VLAN get IP addresses via DHCP and can reach the internet. The rollback plan is to delete the VLAN and SVI. Common issues: VLAN pruning on trunk ports may block the new VLAN; the engineer must ensure trunk allowed VLAN lists are updated. The CMDB is updated with the new VLAN ID and subnet information.
What N10-009 Tests (Objective 3.2)
The exam focuses on your understanding of the change management process, documentation types, and configuration management tools. Specific sub-objectives include:
Explain the purpose and components of change management.
Identify the steps in the change management lifecycle.
Distinguish between standard, normal, and emergency changes.
Recognize the role of the CAB.
Identify documentation types (network diagrams, IPAM, SOPs, CMDB).
Understand configuration backup and rollback procedures.
Common Wrong Answers and Why Candidates Choose Them
"Change management is only for major network upgrades." – Wrong. Change management applies to all changes, including minor ones like password changes, though low-risk changes may follow a streamlined process. Candidates confuse scope with formality.
"The CAB implements the change." – Wrong. The CAB reviews and approves; the actual implementation is done by the network team. Candidates assume the board does everything.
"Rollback is optional if the change is simple." – Wrong. Every change must have a rollback plan. Candidates think low-risk changes don't need rollback, but the exam emphasizes that rollback is always required.
"The CMDB is only used for inventory." – Wrong. The CMDB tracks configurations, relationships, and change history, not just asset inventory. Candidates confuse CMDB with a simple asset database.
Specific Numbers and Terms on the Exam
RFC: Request for Change – the formal document.
CAB: Change Advisory Board – approves changes.
CMDB: Configuration Management Database – stores configuration items (CIs) and their relationships.
PIR: Post-Implementation Review – conducted after a change.
SOP: Standard Operating Procedure – step-by-step instructions.
IPAM: IP Address Management – tracks IP assignments.
Change types: Standard (pre-approved), Normal (requires approval), Emergency (requires retroactive approval).
Risk levels: Low, Medium, High.
Change window: Typically 4 hours, often overnight or weekends.
Edge Cases and Exceptions
Emergency changes bypass normal CAB review but must be documented and approved retroactively. The exam may ask who can authorize an emergency change (e.g., network manager).
Standard changes are pre-approved but still require an RFC for tracking.
If a change fails, the rollback must be executed immediately; the change is then marked as failed and analyzed.
Configuration drift is a key concept: when the running config differs from the baseline. The exam may ask what tool detects drift (e.g., automated config compliance tool).
How to Eliminate Wrong Answers
If an answer says "change management is unnecessary for small networks," it's wrong because best practices apply to all networks.
If an answer says "the change manager approves all changes," it's wrong because the CAB (or delegated authority) approves.
If an answer says "rollback is not needed for standard changes," it's wrong because rollback is always needed.
Look for keywords: "approval," "documentation," "review," "rollback" – these are hallmarks of correct answers.
Change management reduces outages by ensuring all changes are reviewed, approved, and documented.
The five steps of change management: RFC, Review, Approval, Implementation, PIR.
Standard changes are pre-approved; normal changes require CAB approval; emergency changes bypass normal review but need retroactive approval.
A rollback plan is mandatory for every change.
The CMDB stores configuration items and their relationships; it must be updated after every change.
Configuration drift occurs when the running configuration differs from the baseline; automated tools can detect and correct drift.
Key documentation: network diagrams, IPAM, SOPs, wiring labels, and baseline configurations.
These come up on the exam all the time. Here's how to tell them apart.
Standard Change
Pre-approved, low-risk change
Follows a predefined procedure
Requires RFC for documentation
No need for urgent CAB meeting
Example: Adding a new user VLAN
Emergency Change
Requires immediate implementation
Bypasses normal CAB review
Must be documented retroactively
Requires approval from designated authority (e.g., network manager)
Example: Applying a critical security patch
Mistake
Change management is only for large enterprises.
Correct
Change management best practices apply to networks of any size. Even a small office benefits from documenting changes to avoid outages and speed troubleshooting. The N10-009 exam expects you to know that change management is a universal best practice.
Mistake
The CAB is responsible for implementing changes.
Correct
The CAB only reviews and approves changes. Implementation is performed by the network operations team. The exam tests this separation of duties.
Mistake
Standard changes do not require an RFC.
Correct
Standard changes still require an RFC for tracking, but they are pre-approved and follow a predefined procedure. The RFC is used for documentation and audit purposes.
Mistake
Rollback plans are only needed for high-risk changes.
Correct
Every change, regardless of risk level, must have a rollback plan. The exam emphasizes that rollback is a mandatory step in the change process.
Mistake
The CMDB is just a list of devices.
Correct
The CMDB stores configuration items (CIs) including devices, software, licenses, and their relationships. It also tracks change history and current configurations. It is far more than a simple inventory list.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Change management is the process of controlling changes to the network infrastructure, focusing on the lifecycle of a change (RFC, approval, implementation, review). Configuration management is the practice of maintaining a known, consistent state of device configurations and tracking configuration items in a CMDB. In short, change management handles 'how' changes are made, while configuration management handles 'what' the configurations are. Both are essential for network stability and are covered in N10-009 Objective 3.2.
The three types are: Standard (pre-approved, low-risk, follows a predefined procedure), Normal (requires full CAB approval and scheduling), and Emergency (urgent change that bypasses normal review but requires retroactive documentation and approval). On the N10-009 exam, you may be asked to identify which type applies to a given scenario. Remember: emergency changes are only for situations like security breaches or critical outages.
A CAB typically includes representatives from network operations, security, applications, IT management, and sometimes business stakeholders. The exact composition depends on the organization. The key is that the CAB has the authority to approve or reject changes. For the exam, know that the CAB does not implement changes; it only reviews and approves.
A rollback plan is a documented set of steps to revert a change back to its previous state if the change fails or causes issues. It is important because it minimizes downtime and risk. Every RFC must include a rollback plan. Common rollback methods include reloading a previous configuration, reverting firmware, or swapping hardware. The exam may ask what to do if a change fails: execute the rollback plan.
Configuration drift occurs when a device's running configuration deviates from its intended baseline due to unapproved manual changes, failed automation, or incomplete change processes. It is detected using configuration management tools that periodically compare the current config to the baseline and report differences. For example, RANCID or Ansible can flag drift. The exam may test that drift is a sign of poor change management.
Essential documentation includes: network diagrams (logical and physical), IP address management (IPAM) records, device configuration backups, standard operating procedures (SOPs), and a CMDB. These documents support change planning, implementation, and troubleshooting. The exam may ask which document is used to track IP assignments (IPAM) or which shows device relationships (CMDB).
A PIR is a review conducted after a change has been implemented and tested, typically within 24-72 hours. Its purpose is to confirm the change achieved its objectives without negative side effects, and to capture lessons learned. The PIR is a key step in the change management lifecycle. On the exam, remember that PIR helps improve future changes.
You've just covered Change and Configuration Management — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?