Free 10-question sampler.

Start with the difference between a host, a network interface, a link, a frame, a packet, and an application conversation. Use the OSI and TCP/IP models as ways to organize where a problem might occur, not as labels to recite without context. A clear model helps explain why an Ethernet frame, an IP packet, and an application request are related but not interchangeable.

Then compare common network types, topologies, cloud and on-premises services, and bandwidth versus throughput. Use simple examples: a link can advertise a high rate while a test shows lower achieved throughput; latency is about delay, not capacity. For each protocol, know the task it supports and what symptoms might appear if it is unavailable.

For an IPv4 problem, identify the address, subnet mask or prefix, and whether the question asks about network membership, host range, or broadcast behavior. Distinguish private from public addressing and keep NAT as a separate translation concept. For IPv6, recognize the address’s notation and prefix rather than forcing it into IPv4 classes or dotted-decimal habits.

Work through short examples by hand, then verify them. Explain each step: convert or inspect the prefix, identify the relevant network boundary, and state what the result means for communication. If a question does not provide enough information to choose a route or subnet, say what is missing instead of guessing.

Compare twisted-pair copper, fiber, and coax at the level expected for entry-level support: common connector families, link indicators, interference considerations, and the types of endpoint or network device that may use them. Recognize that the physical medium, transceiver or port, cable, and device configuration all contribute to a link coming up.

Use a simple network diagram to trace a path between a client and a destination. Identify the endpoint, access switch, router or default gateway, and any wireless access point or service boundary. Review what link lights can tell you, what they cannot prove, and which observation or command would be a useful next check.

Begin by gathering the user’s exact symptom, the affected device, when it started, what changed, and whether the issue affects one user or many. Record facts and steps already tried. Avoid resetting equipment before you understand the impact or checking a tool without a specific question; the goal is to narrow the fault domain while preserving useful evidence.

Choose commands based on what you need to learn. Ping tests reachability at a particular layer and time; traceroute helps reveal path behavior; ipconfig or ip shows local address details; nslookup examines name resolution; and show commands reveal Cisco device state. Each result is limited evidence. A failed ping does not by itself prove which device or policy blocked traffic.

Become familiar with the purpose of basic show commands, device status lights, console and remote access methods, and management systems. Learn what output fields are useful for a first check, including interfaces, routes, neighbors, version or inventory data, and MAC address tables. The exam objective is foundational interpretation, not advanced configuration across every platform.

For security, explain the difference between identity verification, authorization, and accounting. Recognize why MFA, strong credentials, encryption, certificates, and firewall rules matter, and know that Wi-Fi security settings involve both a protocol version and a choice such as personal or enterprise authentication. Treat a security control as a deliberate policy rather than a fix-all for connectivity problems.