N10-009 networking concepts explained

Networking concepts is worth 23% of CompTIA Network+ N10-009 — around 21 of the 90 questions and the second largest domain. It is also the domain that underpins the other four: addressing, the OSI model and protocols appear throughout implementation, operations, security and troubleshooting.

Weakness here costs far more than 23%.

The OSI model

The framework the whole exam thinks in.

Its practical value is diagnostic. Given a symptom, ask which layer it points at: no link light is layer 1, a MAC or VLAN problem is layer 2, wrong subnet or no route is layer 3, a blocked port is layer 4, name resolution is layer 7.

Learn which device operates at which layer — hub at 1, switch at 2, router at 3 — because questions test that directly.

Addressing and subnetting

Subnetting is the single highest-value skill on this exam. It appears here and in implementation and troubleshooting.

What you need fluently:

• CIDR notation and the mask each prefix implies
• Network address, broadcast address, and usable host range for a given address and prefix
• How many subnets and hosts a given prefix yields
• Private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• APIPA (169.254.x.x) and what its appearance means — usually DHCP failure

Also: public versus private addressing, NAT, and IPv6 basics including address format and why it exists.

Ports and protocols

Memorisation, and worth doing properly because these recur everywhere:

Know the secure alternative to each insecure protocol: SSH over Telnet, HTTPS over HTTP, SFTP over FTP. That pairing appears in the security domain as well.

TCP versus UDP — connection-oriented and reliable versus connectionless and fast — and which services use which.

Topologies, network types and cabling

• Star, mesh, hybrid; LAN, WAN, WLAN, PAN, SAN.
• Cloud models and service models at a conceptual level.
• Copper and fibre: categories, distance limits, and when fibre is required.
• Connector types, and straight-through versus crossover.

Cabling questions are usually answerable from distance and speed limits, so learn those rather than every connector’s appearance.

Cloud service and deployment models

Objective 1.3 asks you to summarise cloud concepts, and the part that produces the most straightforward questions is the list of service models (SaaS, IaaS, PaaS) and deployment models (public, private, hybrid). Network+ tests them as definitions applied to a scenario, not as a vendor product list.

The service model is defined by how much of the stack the provider runs for you:

The rule that answers most questions: moving from IaaS towards SaaS, the provider takes over more layers, but your data, your identities and your configuration remain yours in every model. This split is the shared responsibility model. A virtual server you rent is IaaS, so patching its operating system is your job; a hosted email service is SaaS, so patching the mail software is the provider’s.

Deployment models describe who uses the infrastructure. Public cloud is shared by many customers (multitenancy) and run by a provider. Private cloud serves one organisation, on its premises or hosted. Hybrid combines the two, often joined by a site-to-site VPN or a dedicated Direct Connect-style link, which the same objective lists as cloud connectivity options. Objective 1.3 also pairs these with scalability (adding capacity) and elasticity (capacity that grows and shrinks automatically with demand).

Exam pitfall: assuming the provider is responsible for everything in SaaS. A breach caused by a weak user password, an over-shared file or a misconfigured setting in a SaaS application is still the customer’s responsibility. The cloud service models and shared responsibility guide has the full per-layer matrix.

Transmission media, transceivers and connectors

Objective 1.5 compares transmission media and transceivers, and objective 5.2 turns the same knowledge into troubleshooting: the wrong cable, signal degradation, bad terminations and transceiver faults. Learn the selection rule once and it serves both domains.

• Twisted-pair copper (RJ45) covers runs up to 100 metres. Higher categories support higher speeds and frequencies; shielded twisted pair (STP) suits places with electrical noise where unshielded (UTP) would pick up interference.
• Multimode fibre has a wider core and suits runs within a building or campus. Single-mode fibre has a narrow core and reaches kilometres. Fibre connectors are LC, SC, ST and the multi-fibre MPO.
• Coaxial cable uses F-type (cable TV and cable broadband) or BNC connectors. RJ11 is the telephone connector.
• Direct attach copper (DAC), a twinaxial cable with transceivers fixed to both ends, links devices a few metres apart, typically in the same rack.
• Transceivers come in form factors such as SFP and the larger, higher-capacity QSFP, and carry a protocol such as Ethernet or Fibre Channel.
• Plenum cable has a jacket for air-handling spaces such as the area above a drop ceiling, where fire codes require it; non-plenum cable is for everywhere else.

On the troubleshooting side, objective 5.2 lists crosstalk, interference and attenuation as signal degradation, improper termination, TX/RX transposed on fibre, PoE power budgets, and transceiver mismatch or low signal strength. A link that stays down with low received light points to a mismatch or a dirty connector; a link that is up with rising CRC errors points to degradation or termination.

Exam pitfall: the transceiver and the fibre must match at both ends. A single-mode SFP on multimode fibre, or optics from different standards on each end, produces a dead or error-ridden link even though every component works on its own. The cabling and connectors guide has the category and reach tables.

Zero trust architecture

Objective 1.8 lists zero trust architecture (ZTA) among the evolving use cases for modern networks and names three things it rests on: policy-based authentication, authorization and least privilege access. At Network+ level you need to recognise the idea and what it means for network design, not build a policy engine.

Zero trust reverses the traditional perimeter model. In a perimeter design, being inside the network — plugged into an office port, or connected over VPN — earns broad trust. Zero trust treats network location as granting nothing on its own. Every request to a resource is judged on its own merits: who the user is, which device they are on and what state it is in, what they are asking for, and the context of the request. NIST SP 800-207, the reference most vendors build on, describes a policy decision point that approves or denies each session and a policy enforcement point in the traffic path that carries the decision out.

What the three outline terms mean in practice:

• Policy-based authentication — identity is verified per session against a central policy, typically with MFA, rather than once at the edge of the network.
• Authorization — a verified identity still only reaches the specific resource the policy allows, and that decision is re-evaluated rather than granted for the whole day.
• Least privilege access — the default is no access, and each user, device and service gets the minimum it needs. On the network this pushes towards fine-grained segmentation, so that east-west traffic between internal systems is controlled and not only north-south traffic at the firewall.

Zero trust sits in the same objective as SASE/SSE because cloud-delivered security is a common way to enforce it for users who are not in the office.

Exam pitfall: a scenario says users are trusted because they are on the internal network, or offers placing a server behind the perimeter firewall as the zero trust answer. Both describe the perimeter model that zero trust replaces. The zero trust answer verifies each request and limits access to the minimum, wherever the user sits. And zero trust is an architecture, not a single product you install.

The zero trust guide covers the principles and the decision machinery in full.

Infrastructure as code

Objective 1.8 also covers infrastructure as code (IaC), split into automation and source control. Instead of configuring each switch, router or cloud network by hand through the CLI or GUI, you describe the configuration in files and let a tool apply it. The files become the record of how the network should look.

The automation terms in the outline:

• Playbooks, templates and reusable tasks. A playbook is an ordered set of tasks that a tool such as Ansible runs against devices. A template holds the standard configuration with variables — hostname, VLAN IDs, addresses — filled in per device. Reusable tasks are building blocks such as setting the NTP servers or creating the management VLAN, shared across playbooks instead of copied.
• Configuration drift and compliance. Drift is the gap that opens when someone changes a device by hand and the live configuration no longer matches the defined one. Because the desired state is written down, the tool can detect drift and either report it or put the device back. Compliance is the same check aimed at a standard: does every device still carry the required settings?
• Upgrades. Firmware and OS upgrades rolled out the same way across many devices, rather than box by box.
• Dynamic inventories. The list of devices the automation targets is pulled from a live source, such as a cloud provider API or an inventory system, instead of a hand-maintained file that goes out of date.

This ties into configuration management in the operations domain (objective 3.1): the baseline or golden configuration is exactly what an IaC template encodes.

Exam pitfall: a question describes a device whose configuration no longer matches the standard after an engineer made an emergency change at the console, and asks for the term. That is configuration drift — not a rollback, and not a baseline, which is the reference you compare against. If the question asks how to stop it recurring, the IaC answer is to make changes in the code and re-apply them, not by hand on the device.

For declarative versus imperative tools and how state works, see the IaC guide.

Source control and branching

The second half of the IaC bullet is source control: version control, a central repository, conflict identification and branching. Once the network configuration lives in files, it is managed the way software teams manage code, usually with Git.

• Version control records every change to the files as a commit with an author, a timestamp and a message. You can see who changed the ACL and why, compare any two versions, and revert to a known-good one.
• Central repository is the shared copy that engineers push to and the automation pulls from, so there is one authoritative source for the network’s intended state.
• Branching lets an engineer work on a change on a separate line of development without touching the main branch that production is built from. The change is tested on the branch, reviewed, and merged back once approved — which lines up neatly with the change management process in the operations domain.
• Conflict identification happens at merge time: if two engineers edited the same lines of the same file on different branches, the version control system flags a conflict and a person decides which change wins. It does not silently pick one.

Network+ does not ask you to compare branching models or recite Git commands. Expect conceptual questions: why keep configurations in a repository, what a branch is for, and what a merge conflict signals.

Exam pitfall: an option suggests editing the configuration directly on the main branch to save time, or claims the tool resolves conflicting edits automatically. Both miss the point. The main branch represents what production should be, so changes go through a branch and a review, and conflicts are detected by the tool but resolved by a person.

Named branching models such as trunk-based development and GitFlow are compared in the Git branching guide.

Sample questions

What to practise

Subnet ten addresses a day, out loud, without a calculator. Six weeks of that makes every subnetting question on the exam free.

Then build a flashcard deck of ports and protocols and run it daily. Between those two habits you cover most of what this domain can ask, and a good share of three other domains as well.