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 .