Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

CCNA 200-301 v1.1: an evidence-led study strategy

Cisco's CCNA asks whether a learner can reason across the basic life of an enterprise network: connect devices, divide broadcast domains, route packets, provide supporting services, protect access, and understand how controllers and automation change operations. The active 200-301 v1.1 exam lasts 120 minutes and remains available through February 2, 2027. Cisco's announced v2.0 refresh begins the next day, so version discipline matters. This guide is for v1.1; future-topic lists are not a reason to abandon a current study plan.

Read the verbs as depth signals

The objective verb tells you how to study. Describe and explain call for a working mental model: you should be able to tell a short causal story, not only expand an acronym. Compare requires a requirement-based distinction. Interpret means evidence will be present and you must draw a conclusion. Configure and verify is the deepest pattern: know the intended state, the commands that create it, and independent evidence that it actually operates.

A configuration line is not proof. router ospf 1 does not prove adjacency, an access-list definition does not prove interface placement, and an SSH key does not prove VTY lines reject Telnet. Verification is a second skill.

Allocate time by published weight

The six domains carry 20, 20, 25, 10, 15, and 10 percent. IP Connectivity is the largest at 25 percent, but no domain is expendable. Network Fundamentals and Network Access together are 40 percent and supply the addressing and Layer 2 behavior that routing scenarios assume. Security contributes 15 percent and often appears inside otherwise ordinary management or access designs.

Use the weights to schedule practice, not to skip prerequisites. A learner who cannot determine a subnet boundary will struggle to interpret a connected route. Someone who cannot trace MAC learning will memorize spanning-tree roles without understanding what loop prevention protects.

Build packet-path narratives

Many topics become easier when you narrate one packet. Start at the host: does the destination appear local under its mask? If not, the host resolves the gateway's Layer 2 address and sends a frame to it. At the router, longest-prefix match selects a route. The next hop may require recursive resolution. At each Ethernet segment, the Layer 2 header changes while the routed packet normally retains its end addresses unless a service such as NAT translates them.

The same method explains DHCP relay, ACL direction, default gateways, first-hop redundancy, and troubleshooting. Write what each device knows, which table it consults, and what evidence would contradict your hypothesis.

Practice configuration as intent plus proof

For every configurable objective, keep a three-column notebook: requirement, minimal configuration, and verification. A VLAN requirement might map to VLAN creation, access-port assignment, trunk allowance, and inter-VLAN routing. Its proof might include VLAN membership, trunk state, interface status, MAC entries, and a carefully chosen ping. This prevents the common habit of collecting commands without knowing which failure each command detects.

Use safe labs. A simulator, an isolated virtual topology, or equipment you are authorized to change is appropriate. Production networks are not practice targets. Save a baseline, state the rollback, and change one variable at a time.

Treat output as structured evidence

Command output has fields with relationships. A routing entry has a prefix, source, distance, metric, next hop, and often an age or interface. Spanning-tree output links a VLAN to a root identity and port roles. Interface counters link an observed symptom to a layer. Do not scan for one memorized word; read the whole record and test whether the fields agree.

When output is missing, that absence can be evidence. No OSPF neighbor suggests prerequisites failed before route exchange. No DHCP snooping binding may explain why dynamic ARP inspection rejects a legitimate host. No MAC entry may mean the switch has not observed a source frame, the entry aged, or the VLAN is wrong.

Make automation concrete

The automation domain is not a programming contest. Understand why consistent, reviewed intent is safer than repetitive manual entry; how controllers expose northbound and southbound interfaces; what a REST request says; and how JSON represents nested operational data. AI-generated advice remains untrusted until validated against source configuration, platform support, policy, and observed state. A fluent response is not a change ticket or a rollback plan.

Use mistakes as routing information

Record the reason for a miss. Was the concept unknown, the evidence misread, a calculation rushed, or a qualifier overlooked? Different causes need different repairs. Re-reading helps an unknown concept. Reconstructing a packet path helps misapplied logic. Timed mixed sets address pacing only after the underlying skill is correct.

Review explanations for correct answers too. A lucky choice can hide a fragile model. Re-answer later without seeing the options and explain why each rejected choice solves a different problem.

Final readiness standard

Before scheduling, you should be able to calculate IPv4 ranges, read IPv6, trace Ethernet and routing decisions, build a basic switched and routed design, explain services and security controls, and read simple API data. You should also know where your certainty ends. CCNA rewards disciplined fundamentals: state the requirement, choose the smallest sufficient mechanism, verify the result, and avoid claiming more than the evidence proves.