Study guide
Change Management and Request Tracking
CompTIA Network+ N10-009
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
Current Exam Facts and Applied Networking Judgment Official Domain Weights and an 8-12 Week Study Plan How to Use Labs, Practice, and PBQ Workflow Missed-Question Notebook and Final Readiness Metrics
2 Domain 1: Networking Concepts (23%)
OSI and TCP/IP Models with Device and Protocol Mapping Networking Appliances and Where They Operate Ports and Protocol Decision Table Traffic Types and Encapsulation Flow
3 Domain 1: Media, Connectors, Transceivers, and Network Architectures
Copper, Fiber, Coax, and DAC Media Connector and Transceiver Selection Network Topologies and Design Patterns Cloud and Virtual Networking Concepts
4 Domain 1: IP Addressing and Subnetting Mastery
IPv4 Classes, Private/Public, APIPA, and Loopback CIDR, VLSM, and Subnet Math IPv6 Address Types and Notation Routing Basics and Longest Prefix Match
5 Domain 2: Network Implementation - Routing
Static vs Dynamic Routing and Route Selection OSPF, EIGRP, and BGP Basics at Network+ Depth NAT/PAT, VIP/FHRP, and Subinterfaces Routing PBQs and Troubleshooting Route Table Clues
6 Domain 2: Network Implementation - Switching
VLANs, Access Ports, Trunks, and Native VLAN STP/RSTP Loop Prevention and Bridge Roles Port Aggregation/LACP, MTU, Jumbo Frames, and Interface Settings Switch Implementation PBQs and Common Misconfigurations
7 Domain 2: Network Implementation - Wireless and Physical Implementation
Wi-Fi Standards, Bands, and Channels SSID Security, Guest Networks, and Authentication Antennas, Coverage, Roaming, Interference, and Site Surveys Physical Installation Implications
8 Domain 2: Network Implementation - Services Implementation
DNS Record Types and Troubleshooting Cues DHCP, DHCPv6, SLAAC, Scopes, Leases, and Relay NTP, PTP, NTS, and Time-Sensitive Networking Service Implementation PBQs: DNS, DHCP, VLANs, and Firewall Direction
9 Domain 3 Part A: Network Operations Documentation and Governance
Physical, Logical, Rack, Cable, Wireless Diagrams, and IPAM Asset Inventory, Baselines, SLAs, SOPs, and Runbooks Change Management and Request Tracking Lifecycle, EOL, EOS, Decommissioning, and Configuration Management
10 Domain 3 Part B: Monitoring, Remote Access, and Resilience
SNMP, Flow, Syslog, Packet Capture, Log Aggregation, APIs, and Port Mirroring Baselines and Performance Metrics Remote Access, Management Paths, and Secure Admin Habits DR and HA Concepts: RPO, RTO, MTTR, MTBF, Sites, Failover, and Testing
11 Domain 4: Logical Security and Secure Access (14%)
Encryption in Transit, Encryption at Rest, PKI, and Certificates IAM, MFA, SSO, Directory Services, and AAA Authorization, Least Privilege, RBAC, Geofencing, and Time-Based Access VPNs and Secure Management Design
12 Domain 4: Segmentation, Risk, and Network Attacks (14%)
Segmentation for Guest, BYOD, IoT, IIoT, SCADA, ICS, and OT Risk, Compliance, Audit, Data Locality, PCI, and GDPR Network Attacks and Scenario Cues Attack-to-Mitigation PBQ Tables
13 Domain 4: Security Controls and Hardening (14%)
Firewalls, IDS, IPS, Security Zones, and Screened Subnets ACLs, Filtering, NAC, Hardening, and Key Management Deception Technologies and Physical Security Zero Trust, SASE, and Trusted or Untrusted Zone Decisions
14 Domain 5: Troubleshooting Methodology and Tools (24%)
Official Troubleshooting Methodology and Evidence Handling Command-Line Tools: ping, traceroute, nslookup, dig, ipconfig, ifconfig, ip, arp, netstat, ss, and route Packet, Protocol, and Wi-Fi Analyzers Choosing the Right Tool by Symptom PBQs
15 Domain 5: Physical, Interface, and Wireless Troubleshooting (24%)
Cable Issues: Type, Attenuation, Crosstalk, Termination, and TX/RX Interface Issues: Errors, Discards, Duplex, Speed, Port Status, and PoE Transceiver, Fiber, and Signal Strength Troubleshooting Wireless Troubleshooting: Interference, Channels, Roaming, RSSI/SNR, Security, and Captive Portals
16 Domain 5: Network Services, Switching, Routing, and Performance Troubleshooting (24%)
DHCP, DNS, NTP, and IP Addressing Issues VLAN, STP, Trunk, Native VLAN, and ACL Issues Routing, Default Gateway, Route Table, and NAT Issues Congestion, Latency, Jitter, Packet Loss, and Application Performance Clues
17 Performance-Based Question Labs
Subnetting and VLSM Design Lab VLAN, Trunk, Router-on-a-Stick, and Firewall Rule Lab Wireless Deployment and Troubleshooting Lab Monitoring, Log Triage, and Route or Service Troubleshooting Lab
18 High-Yield Reference and Final Study Plan
High-Yield Ports and Protocols Table Wi-Fi, Cabling, Connectors, and Transceivers Quick Table Acronyms and Command-Line Tool Quick Table Final 7-Day Review Plan and Readiness Checklist
19 Final Synthesis: Strategy, Remediation, and Readiness
Mixed-Set Decision Strategy for Qualifiers and Close Answers Missed-Question Remediation Notebook by Error Type Exam-Day Time Management and PBQ Order 100-Question Readiness Simulation Blueprint Mapped to N10-009 Weights
Change Management and Request Tracking
Key Takeaways Explain This Topic AI
N10-009 objective 3.4 covers change management; the exam expects clear scope, risk/impact analysis, approval, scheduling, communication, a test plan, and a rollback (backout) plan.
Request tracking creates an audit trail: who requested the change, who approved it, what changed, when, and whether validation succeeded.
Standard (pre-approved, low-risk), normal (planned, reviewed), and emergency (urgent) changes carry different approval and timing requirements — but all are documented.
A maintenance window confines planned disruption to an approved time and leaves room to validate or roll back before users return.
Post-change review (validation, documentation/IPAM updates, lessons learned) closes the loop and updates baselines and runbooks.
Last updated: June 2026
Why Change Management Is on the Exam
Networks are shared systems. A single edit to a route, VLAN, firewall rule, wireless controller, or DHCP scope can affect hundreds of users. N10-009 objective 3.4 places change management squarely in Domain 3, and the exam routinely presents a planned change and asks which control was missing when something went wrong. Change management is the repeatable process that lowers risk and creates accountability.
What a Change Record Must Contain
- Field Purpose
- Requester Identifies who asked for the change
- Business reason Explains why it is needed
- Scope Devices, services, locations, users affected
- Risk and impact What could go wrong and who is affected
- Implementation plan The steps to make the change
- Test/validation plan How success will be verified
- Backout (rollback) plan How to restore the previous state
- Schedule The approved maintenance window
- Approver Confirms authorization (often a CAB)
- Communication plan Tells stakeholders what to expect
Good request tracking also captures timestamps, comments, attachments, approvals, related incidents, and the final outcome. A Change Advisory Board (CAB) typically reviews normal changes. The ticket itself becomes the evidence that the change was authorized and executed according to process — an auditor or post-incident review will look there first.
Change Types
- Change type Description Example
- Standard Low-risk, pre-approved, repeatable Add an access switchport using an approved template
- Normal Planned change requiring review and approval Replace a branch firewall
- Emergency Urgent work to restore service or reduce active risk Block an actively exploited inbound path
Emergency changes still get documented. Approval may be expedited (sometimes a single on-call manager), but the organization still needs a record of what happened, why, who approved it, and what follow-up review is required after the fire is out.
Risk and Impact Analysis
Risk analysis weighs probability against consequence; impact analysis identifies who or what is affected. A change to a core switch is higher risk than disabling one unused access port, and a firewall rule change for a payment application carries more business impact than a lab VLAN tweak.
- Question Why it matters
- What systems depend on this path? Reveals hidden impact
- What is the failure mode? Drives the backout plan
- Can the change be tested first? Reduces uncertainty
- Who must be notified? Prevents surprise outages
- What evidence proves success? Avoids vague completion criteria
- Maintenance Windows and Communication
A maintenance window is the approved time for planned work. It should align with business needs, support and vendor availability, and — critically — leave enough time to roll back if validation fails. Communication should state expected impact, start and end times, the contact path, and whether users must take any action. A useful pattern is the freeze window — periods (end of quarter, peak retail season, a major event) when only emergency changes are allowed. Knowing a freeze is in effect prevents a well-meaning normal change from landing at the worst possible time.
Authorization, Audit Trail, and Separation of Duties
Request tracking is where accountability lives. Each ticket records timestamps, the requester, the approver, comments, attached evidence (before/after configs, validation output), and any linked incidents. Two principles the exam rewards: separation of duties (the person who requests or implements a change should not be the sole approver of it) and a complete audit trail (every state transition is logged). When an outage is later investigated, the change ticket answers who authorized the work, what exactly changed, when it ran, and whether validation passed — turning a finger-pointing exercise into a fact-based review.
Post-Change Review
After a change, operators validate service health, update diagrams and IPAM, close the request with evidence, record any deviation from the plan, and capture lessons learned. If the change caused an incident, the review should pinpoint what failed in planning, testing, communication, or execution so the process improves.
Practical Scenario
A team migrates a branch from one ISP to another. A strong change request includes the new and old circuit details, affected users, routing changes, firewall and NAT updates, any DNS or DHCP changes, a test plan, provider escalation contacts, a communication plan, an approved maintenance window, and a backout plan to restore the original circuit if validation fails. If the cutover fails at 2 a.m., the rollback plan is what saves the morning.
Common Exam Traps
Trap Better exam reasoning
"Emergency changes need no documentation." They still need records and a follow-up review.
"Approval alone makes a change safe." Planning, testing, communication, and rollback are also required.
"Close the ticket once commands are pasted." Validate service health and attach evidence first.
"Change management only applies to outages." It governs standard, normal, and emergency work alike.
Quick Drill
Know who authorized a firewall change: request tracking / approval record .
Restore service if the new config fails: backout (rollback) plan .
Confine planned disruption to a set time: maintenance window .
Confirm the change achieved its intent: test/validation plan .
Capture what to improve next time: post-change review .