Network+ N10-009 Domain 3: Network Operations

Domain 3 accounts for 19% of N10-009. The topics look administrative at first, but the exam uses them to test whether you can operate a network without relying on memory, luck, or one person who knows where everything is hidden.

A switch fails after an unapproved overnight change. The replacement device is available, but the team cannot find a current configuration backup. Monitoring shows the device as reachable, yet the customer application is still unavailable. The timestamps in the firewall, server, and authentication logs disagree by several minutes. Each problem belongs to network operations because the network must be documented, monitored, recoverable, and managed as a service.

Use this guide to connect operational terms to evidence and decisions. A diagram should answer a specific question. A monitor should measure the thing users depend on. A recovery objective should control architecture and testing. A management method should remain available when the production path is unhealthy.

Domain 3 objective map

The objectives overlap during real work. IPAM supports DHCP planning. Time synchronization makes monitoring and incident timelines trustworthy. Configuration backups support disaster recovery. A jump host can centralize administrative access and session recording. Think in workflows rather than isolated vocabulary lists.

Use an operations cycle

Routine network operations can be organized into a repeating cycle:

1. Define the intended state. Keep diagrams, inventories, address plans, approved configurations, service expectations, and ownership current.
2. Observe the actual state. Collect availability, performance, traffic, configuration, and event evidence.
3. Compare and investigate. Decide whether the difference is expected growth, an approved change, a fault, or suspicious activity.
4. Change with control. Document the request, risk, implementation, validation, communication, and rollback plan.
5. Recover and improve. Restore service from tested copies and paths, then update documentation, monitoring, and procedures with what the event revealed.

Suppose an access switch suddenly reboots every morning. Availability monitoring confirms the outages. Logs show a power event. The rack diagram identifies the PDU and UPS path. Asset inventory provides the model, warranty status, and support owner. Change records show that another device was recently added to the same power circuit. The solution emerges from several operational records working together.

Choose documentation that answers the question

A document becomes useful when its scope is clear and someone is responsible for keeping it current. A diagram that tries to show every cable, VLAN, route, rack position, and service dependency on one page becomes wall art surprisingly quickly.

Inventory and IPAM have different jobs

An asset inventory tracks what the organization owns or operates. Useful fields include hardware model, serial number, location, owner, software version, license, warranty, support contract, purchase date, and lifecycle status.

IP address management (IPAM) tracks address space. It should show subnets, prefixes, VLAN or zone relationships, address assignments, reservations, exclusions, gateways, DHCP scopes, DNS names, ownership, and available capacity. A spreadsheet can work for a small environment, but it becomes risky when several teams allocate addresses independently.

Use the IPv4 Subnetting Reference or IPv4 Subnet Calculator when an address boundary must be verified before it is entered into IPAM or a DHCP scope.

SLAs define measurable service commitments

A service-level agreement (SLA) records expectations such as availability, response time, restoration targets, maintenance windows, escalation paths, measurement methods, reporting, and remedies. The metric needs a definition. “99.9% available” is incomplete until the agreement identifies the measured service, observation period, exclusions, and source of truth.

Operational teams also use internal service objectives and operating agreements. The exam clue is usually the same: choose the record that defines measurable service expectations and accountability.

Wireless surveys and heat maps

A wireless survey records real conditions in the intended environment. A predictive survey models expected coverage from floor plans and material assumptions. An active or passive onsite survey can measure signal strength, noise, channel use, interference, roaming behavior, and observed access points.

A heat map visualizes one selected measurement across the area. Read the legend before drawing a conclusion. A strong signal heat map does not prove low interference, sufficient capacity, or successful roaming.

Manage lifecycle and change before they become outages

End of life and end of support

End of life (EOL) usually indicates that a product is no longer sold or is being retired from the vendor's product lifecycle. End of support (EOS) identifies when normal vendor support, patches, replacements, or assistance end. Vendor terminology varies, so the published lifecycle notice controls the exact meaning.

Track both dates early enough to plan funding, compatibility testing, migration, and disposal. A device can continue forwarding traffic after support ends, but an unpatched defect, unavailable replacement, expired license, or unsupported software dependency can turn the next failure into a longer outage.

Software, OS, firmware, patches, and bug fixes

Network devices may have a base operating system, firmware for hardware components, boot software, feature packages, and management applications. Before updating:

• Confirm the affected models, current versions, target versions, dependencies, and supported upgrade path.
• Review release notes, fixed defects, known issues, required licenses, storage, and reboot behavior.
• Back up the current configuration and any required software image.
• Test on representative equipment when possible.
• Define success checks and rollback conditions before the maintenance window.
• Verify routing, switching, wireless, management, monitoring, and business services after the change.

The newest release is not automatically the safest choice for every production network. The selected version must meet support, security, stability, and feature requirements.

Decommissioning

Decommissioning closes operational records as well as removing hardware. Back up required configurations, erase credentials and sensitive data, revoke certificates and API tokens, release IP addresses, remove DNS and monitoring entries, update diagrams, recover licenses, end support contracts, and dispose of equipment through the approved process.

A powered-off device that remains in IPAM, DNS, monitoring, and diagrams creates false evidence for the next administrator.

Change management

A useful change record answers:

• What business or technical outcome is required?
• Which devices, users, services, and dependencies are affected?
• Who requested, reviewed, approved, implements, and validates the change?
• When will the work occur, and who must be notified?
• What is the implementation sequence?
• What evidence confirms success?
• What condition triggers rollback, and how is rollback performed?
• What actually happened, including unexpected results?

Request tracking or a service-request system creates an auditable path from need through closure. Emergency changes may use an accelerated process, but they still need ownership, documentation, validation, and later review.

Keep production, backup, and baseline configurations distinct

A recent backup can faithfully preserve a bad setting. A golden configuration can describe the approved standard without containing device-specific addresses or secrets needed for immediate restoration. Operations teams often need both.

Configuration monitoring compares actual device state with an approved or previously recorded state. Useful alerts identify what changed, when, on which device, and whether an approved request explains the change. Version control adds history, review, comparison, and conflict visibility for text-based configurations and infrastructure-as-code files.

Protect configuration copies. They may contain address plans, usernames, password hashes, shared secrets, SNMP strings, VPN settings, and security rules. Restrict access, encrypt sensitive storage, test restoration, and retain enough history to recover from changes discovered days later.

Select monitoring evidence by the question

No single monitoring method answers every question. Choose the least expensive source that can confirm or reject the current theory, then collect deeper evidence when needed. The Network Monitoring Evidence Quick Reference provides a compact comparison when SNMP, logs, flow data, captures, mirroring, taps, baselines, and alerts all appear plausible.

SNMP polling, traps, MIBs, and versions

An SNMP manager queries agents on managed devices. The management information base (MIB) defines objects and identifiers that the manager can request or interpret. Polling provides periodic values such as interface counters. A trap or notification allows the agent to report an event without waiting for the next poll.

Polling can show that an interface's error counter climbed for several minutes. A link-down trap can report the state change quickly. Using both provides periodic context and timely events.

SNMPv2c commonly uses community strings and does not provide the stronger authentication and privacy protections associated with SNMPv3. SNMPv3 supports authenticated messages and optional encryption when configured accordingly. The protocol version and security settings must match on the manager and agent.

Flow data, packet captures, and port mirroring

Start with the question:

• Who is using the link and how much? Flow data is a strong first choice.
• Why does one TCP session fail after the handshake begins? A packet capture may show the exact exchange.
• How can traffic from a switched server port reach the analyzer? Configure an appropriate mirror or monitoring session.

Capture placement matters. Traffic observed before a firewall, after NAT, on one side of a tunnel, or on the wrong VLAN can tell different stories. Encrypted traffic still reveals addresses, ports, sizes, timing, and setup behavior, but the application payload may remain unreadable.

Baselines and anomaly alerts

A baseline records normal behavior over meaningful periods. Useful baselines include bandwidth, packet rate, latency, jitter, loss, errors, CPU, memory, wireless utilization, client count, and service response time. Capture weekday peaks, overnight jobs, month-end work, maintenance, and seasonal changes when those patterns affect the environment.

An alert threshold without context can be noisy. A WAN link at 75% may be normal during backups and abnormal at noon. Anomaly alerting compares current behavior with expected ranges, trends, or peer behavior. The alert should identify the measured object, time window, threshold or deviation, and supporting evidence.

Log aggregation, Syslog, and SIEM

A Syslog collector centralizes messages from network devices and systems. Central storage improves retention, searching, correlation, and survival when the original device fails. Reliable time synchronization and consistent device identity are essential when several logs must be placed on one timeline.

A security information and event management (SIEM) platform can ingest logs and other security data, normalize fields, correlate events, apply detection logic, and support investigation workflows. A collector stores messages. A SIEM adds analysis and security use cases, although product features vary.

Review the Common Ports and Protocols Reference for SNMP, Syslog, NTP, DNS, DHCP, SSH, and other services used throughout operations.

Match the monitoring solution to the dependency

Monitor the service users depend on. A server can respond to ping while its web process is stopped, its certificate is expired, its DNS record is wrong, or a dependency is unavailable. A useful availability check performs enough of the expected transaction to represent the user experience.

Discovery can be ad hoc when investigating a suspected unknown device or scheduled when comparing the network with inventory. Control scan scope and timing. Aggressive discovery can affect fragile devices, alarms, or production links.

Translate disaster recovery metrics into design requirements

The four common metrics answer different questions:

RPO and RTO are objectives used to guide design and recovery planning. MTTR and MTBF are measured reliability or maintainability statistics. A system can have a strong MTBF and still miss its RTO if replacement parts, access, documentation, or restoration steps are poor.

A tighter RPO may require more frequent backups, replication, journaling, or continuous data protection. A tighter RTO may require prebuilt capacity, automated failover, current configurations, ready connectivity, trained staff, and tested procedures. The architecture should trace back to the stated business targets.

Compare recovery sites and availability models

Cold, warm, and hot sites

The labels describe readiness, not one universal product specification. Verify what equipment, connectivity, staffing, security, licensing, and data freshness are actually included.

Active-active and active-passive

In an active-active design, multiple systems or sites serve production work at the same time. Capacity planning must account for a failure while remaining nodes continue service. Data consistency, session handling, routing, health checks, and failure domains require careful design.

In an active-passive design, the passive system waits to take over when the active system fails or is removed for maintenance. The standby still needs current data, compatible configuration, health checks, and a tested failover mechanism. “Passive” should not mean “forgotten until the outage.”

Tabletop exercises and validation tests

A tabletop exercise walks participants through a simulated event. It tests roles, decisions, communications, dependencies, escalation, and gaps without performing a full production interruption.

A validation test confirms that technology and procedures perform as expected. Examples include restoring a configuration to spare hardware, recovering a service from backup, failing traffic to a standby path, validating remote access, or confirming that contact and escalation procedures work.

Testing should produce evidence, findings, owners, and deadlines. A successful meeting with no recorded actions is a pleasant conversation, not a mature recovery program.

Operate address, name, and time services as shared dependencies

DHCP, DNS, and time services affect nearly every user and device. Their failures often appear as unrelated application problems because clients depend on them before reaching the intended service.

For each service, know:

• Which clients and networks depend on it.
• How requests cross routed or security boundaries.
• Which configuration is authoritative.
• How redundancy, replication, or failover works.
• What logs and monitors prove that a complete transaction succeeded.
• How a change can be reversed.

Implement DHCP and SLAAC deliberately

DHCP scope components

A typical IPv4 DHCP exchange is Discover, Offer, Request, and Acknowledgment. The client initially broadcasts because it lacks complete network settings. A relay receives the local request and forwards it toward the configured server while providing information that helps the server select the correct scope.

When clients receive APIPA addresses, check whether the scope has capacity, the server is available, the relay points to the correct server, security rules permit the exchange, and the client is in the expected VLAN. Static addressing can temporarily hide a DHCP failure, so verify the service rather than stopping when one client reaches the gateway.

Plan the scope from the subnet

For 192.168.50.0/24, the traditional usable range is 192.168.50.1 through 192.168.50.254. The DHCP pool might use .50 through .199, while gateways, infrastructure, printers, or servers use addresses outside the pool or explicit exclusions and reservations. Record the decision in IPAM so another administrator does not create an overlapping pool.

SLAAC

IPv6 Stateless Address Autoconfiguration (SLAAC) allows a host to form an address using information advertised by a router. Router advertisements communicate the prefix and other network behavior. The host generates an interface identifier and performs the required checks before using the address.

SLAAC can provide addressing without a stateful server assigning each address. Depending on the design, clients may still obtain additional information through other mechanisms. The exam clue is the requirement for hosts to create their own IPv6 addresses from an advertised prefix.

Separate DNS records, zones, roles, and protections

Record types

Forward and reverse zones

A forward zone organizes name-based records such as A, AAAA, MX, TXT, and CNAME. A reverse zone organizes address-to-name mappings using PTR records. Forward and reverse data do not automatically prove each other correct. Maintain both when applications, diagnostics, or policy require consistent resolution.

Authoritative, recursive, primary, and secondary

These terms answer separate questions:

• An authoritative server answers from zone data for which it has authority.
• A non-authoritative answer commonly comes from cached or recursively obtained data rather than the server's own authoritative zone.
• A recursive resolver accepts a client query and performs or coordinates additional DNS queries to obtain the answer.
• A primary server holds the original writable zone source in a traditional primary-secondary design.
• A secondary server obtains a copy through zone transfer and can still answer authoritatively for that zone.

A secondary server is not the same as a recursive resolver. Primary and secondary describe how authoritative zone data is maintained. Recursive describes how a resolver obtains answers for clients.

DNSSEC, DoH, and DoT

DNS Security Extensions (DNSSEC) allow a validating resolver to verify the origin and integrity of signed DNS data through a chain of trust. DNSSEC does not encrypt the query or hide the requested name.

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS transport between participating endpoints. Encryption protects that leg from ordinary observation or alteration, but it does not make unsigned DNS data authoritative. Deployments must also consider resolver policy, logging, filtering, endpoint configuration, and failure behavior.

Hosts files

A hosts file provides local static name mappings. It can support testing or a narrow recovery need, but it does not scale well across many systems and can override expected DNS behavior. When one client resolves a name differently from every other client, inspect its local resolver settings, cache, and hosts file.

Choose time services by precision and trust requirements

Accurate time supports log correlation, certificate validation, authentication, monitoring, distributed applications, scheduled work, and incident response. A device can forward packets normally while its incorrect clock quietly damages every investigation.

Use multiple appropriate time sources and monitor offset, reachability, source selection, and unexpected changes. Pointing every device directly at unrelated internet servers creates inconsistent policy and makes troubleshooting harder. A controlled hierarchy can provide consistent sources while limiting external dependencies.

Compare access and management paths

VPN access patterns

The correct answer follows the access requirement. Two branch networks that should communicate without user action call for site-to-site connectivity. A contractor who needs one internal web application from a personal device may fit clientless access better than broad routed access.

SSH, GUI, API, and console

• SSH provides encrypted command-line access and supports interactive administration and automation.
• GUI management can make complex status and configuration easier to visualize, but access still requires strong authentication, protected transport, and restricted source networks.
• API access supports repeatable automation and integration. Use scoped credentials, secure secret storage, validation, rate handling, logging, and error controls.
• Console access reaches the device through a local or dedicated console interface and can remain useful when IP configuration, routing, or management services fail.

Disable insecure or unused management services. Restrict administrative source addresses, use centralized identity and multifactor authentication where supported, log sessions and changes, and keep a recovery path for broken network configuration.

Jump hosts

A jump host is a controlled intermediary used to reach restricted management networks. It can concentrate authentication, tools, session recording, source restrictions, and audit evidence. Harden it, limit installed software, patch it, monitor it, and prevent it from becoming a convenient path around normal controls.

A jump host does not automatically create out-of-band management. If it relies on the same production network and routing path as the managed devices, it remains part of the in-band path.

In-band and out-of-band management

In-band management uses the production network or the same forwarding infrastructure that carries ordinary traffic. A dedicated management VLAN can improve separation while still remaining in-band if it depends on the same switches, routes, and power path.

Out-of-band management uses an independent management path, such as dedicated management interfaces, console servers, separate switches, alternate circuits, or cellular access. It is designed to remain reachable when production routing or switching is broken.

Out-of-band access must be secured and tested. An emergency modem, console server, or management circuit that nobody can authenticate to during an outage adds confidence only on the diagram.

Work through operations scenarios

Scenario 1: An unapproved switch change

At 2:00 a.m., a switch configuration changes and several access ports stop passing traffic. No approved ticket covers the device.

Configuration monitoring should alert on the difference from the approved state. The team should preserve the changed configuration and logs, identify the actor or management source, compare the change with the production and golden configurations, and use the tested rollback procedure. After service returns, update the incident and change records rather than deleting the evidence.

Restoring the newest backup without reviewing it could reapply the same bad change if the backup was captured after 2:00 a.m.

Scenario 2: A WAN link is slow every afternoon

Users report poor application performance, and interface monitoring shows high utilization from 2:00 p.m. to 3:00 p.m.

Compare the period with the baseline. Flow data can identify top talkers, destinations, protocols, and traffic volume without collecting every payload. If one application still behaves unexpectedly after the heavy conversations are identified, capture selected traffic at an appropriate point to inspect retransmissions, loss, or protocol behavior.

A one-time packet capture may explain one session but will not show whether the afternoon pattern is normal across weeks.

Scenario 3: Clients in a new VLAN receive no leases

Clients on the DHCP server's local subnet work. Clients in VLAN 40 receive no lease, but a statically addressed test client can route to the server.

Check the VLAN 40 scope, available leases, exclusions, security rules, and DHCP relay on the routed interface for VLAN 40. The relay is a strong clue because the client's initial broadcast does not cross the routed boundary by ordinary forwarding.

Creating a reservation for every client does not fix the missing request path.

Scenario 4: Recovery targets conflict with the current design

A service has an RPO of 15 minutes and an RTO of one hour. Backups run once each night, replacement hardware must be ordered after a failure, and restoration has never been tested.

The current process cannot credibly meet either objective. The RPO calls for data protection at least frequent enough to limit expected loss. The RTO calls for ready capacity, current configurations, connectivity, access, and tested restoration or failover steps. Record the gap and redesign the recovery process around the targets.

Scenario 5: Production management is unreachable

A routing error blocks access to the device management subnets. The devices still have power, but SSH and GUI access through production paths fail.

Use the independent out-of-band path, such as a console server or dedicated management network, to inspect and reverse the routing change. A jump host located behind the failed production route would not solve this outage. Verify the out-of-band path during normal operations so credentials, circuits, and console mappings are known before an emergency.

Common Network+ Domain 3 traps

Choosing a physical diagram for a routing question

Physical documentation shows equipment and links. A logical or Layer 3 diagram is more useful for subnets, routes, gateways, and traffic boundaries.

Using inventory as IPAM

Inventory tracks assets, software, licenses, warranties, and ownership. IPAM tracks address space, subnets, assignments, scopes, and capacity. The systems can integrate, but their primary questions differ.

Confusing EOL and EOS

End of life and end of support can occur on different dates. Read the vendor's lifecycle notice and plan around the loss of patches, assistance, replacements, and compatibility.

Treating a backup as a golden configuration

A backup preserves a device state at a time. A golden configuration describes the approved standard. A recent backup can contain drift or a bad change.

Confusing SNMP polling and traps

Polling requests data on a schedule. A trap reports an event without waiting for the next scheduled request. Mature monitoring often uses both.

Using packet capture when flow data answers the question

Top talkers, conversation pairs, ports, and volume are flow questions. Packet capture is appropriate when exact packet behavior or protocol fields are required.

Monitoring host reachability instead of service availability

Ping can succeed while DNS, HTTPS, authentication, or the application transaction fails. Match the monitor to the service users need.

Reversing RPO and RTO

RPO concerns acceptable data loss measured in time. RTO concerns acceptable time to restore service.

Reversing MTTR and MTBF

Lower MTTR is generally better because repair or restoration is faster. Higher MTBF is generally better because failures are farther apart.

Assuming a hot site guarantees instant recovery

A hot site offers high readiness, but DNS, routes, data consistency, authentication, staffing, licenses, and procedures still need validation.

Calling every standby design active-passive

Active-passive requires a defined standby and takeover process. A spare device on a shelf without current software, configuration, connections, or a replacement procedure is inventory.

Confusing reservations and exclusions

A reservation maps a client to a consistent leased address. An exclusion prevents dynamic allocation. Excluding an address does not tell a client to use it.

Confusing authoritative and recursive DNS

Authoritative servers answer from zones they serve. Recursive resolvers obtain answers for clients. A secondary authoritative server can still be authoritative.

Using DNSSEC as query encryption

DNSSEC validates signed data. DoH and DoT encrypt DNS transport. The controls address different risks.

Treating split tunneling as automatically better or worse

Split tunneling reduces central traffic but allows non-VPN traffic to use the local path. Full tunneling centralizes routing and policy but increases VPN capacity and latency requirements. Choose from the stated requirement.

Calling a management VLAN out of band

A management VLAN on the production switching and routing infrastructure remains dependent on that infrastructure. Out-of-band management uses an independent path.

Rapid review checklist

You are ready to move beyond Domain 3 review when you can:

• Select physical, logical, rack, cable, Layer 1, Layer 2, or Layer 3 documentation for a stated question.
• Distinguish asset inventory, IPAM, SLA records, and wireless survey evidence.
• Explain EOL, EOS, patching, firmware, OS maintenance, and complete decommissioning.
• Build a change record with risk, approval, implementation, validation, communication, and rollback.
• Distinguish production, backup, and baseline or golden configurations.
• Explain SNMP polling, traps, MIBs, community strings, SNMPv2c, and SNMPv3.
• Choose flow data, packet capture, logs, API integration, or port mirroring from the evidence required.
• Explain how baselines make thresholds and anomaly alerts meaningful.
• Distinguish a Syslog collector from a SIEM use case.
• Match discovery, traffic, performance, availability, and configuration monitoring to the dependency.
• Interpret RPO, RTO, MTTR, and MTBF without reversing them.
• Compare cold, warm, and hot sites plus active-active and active-passive designs.
• Distinguish tabletop exercises from technical validation tests.
• Configure the logic of DHCP scopes, reservations, exclusions, leases, options, and relays.
• Explain when SLAAC fits an IPv6 requirement.
• Match A, AAAA, CNAME, MX, TXT, NS, and PTR records to their jobs.
• Distinguish forward and reverse zones, authoritative and recursive service, and primary and secondary servers.
• Explain the separate protections supplied by DNSSEC, DoH, and DoT.
• Compare NTP, PTP, and NTS by precision and security requirements.
• Select site-to-site, client-to-site, clientless, split-tunnel, or full-tunnel VPN access.
• Choose SSH, GUI, API, console, or jump-host access according to the administrative task.
• Explain why an independent out-of-band path matters during a production-network failure.

After reviewing, take a Network+ N10-009 practice test. For each missed operations question, identify the missing artifact or evidence. Did you need the correct diagram, a baseline, a configuration diff, a recovery metric, a DNS role, or an independent management path? That answer gives you a specific item to create or test in a small lab.

Official references

• CompTIA Network+ certification page
• CompTIA Network+ N10-009 exam objectives
• RFC 3411: Architecture for SNMP Management Frameworks
• RFC 5424: The Syslog Protocol
• RFC 2131: Dynamic Host Configuration Protocol
• RFC 4862: IPv6 Stateless Address Autoconfiguration
• RFC 1034: Domain Names, Concepts and Facilities
• RFC 4033: DNS Security Introduction and Requirements
• RFC 8915: Network Time Security for the Network Time Protocol