Cisco CCNA 200-301 v1.1 Study Plan

Current exam: v1.1 is available through February 2, 2027. Testing later? Use CCNA v2.0 .

Use this plan to turn the v1.1 blueprint into observable skills. The four-week sequence suits a revision cycle for someone with networking foundations. If subnetting, switching or IOS is new, give each stage additional weeks. Advance when you can complete its tasks, not simply when the calendar changes.

Establish your starting point

Before choosing a pace, attempt a small mixed diagnostic without notes and build a two-subnet lab. Record whether you can calculate the subnets, configure endpoint addressing, make the router forward between them and explain the return path. Separate three kinds of weakness:

A familiar practice score can conceal the third problem. Use changed addresses, interface names and faults rather than repeating an identical answer sequence.

Prepare a small reusable lab

Start with two switches, two routers and a few clients in a simulator or suitable virtual/physical lab. Add a second path when practising redundancy. Keep an addressing table and save a known-good baseline before introducing faults.

These are documentation networks for exercises. Adapt interface names and feature choices to your lab. Record features your simulator cannot implement accurately and use supported device documentation or another lab environment for those tasks. A missing simulator command is not evidence that the exam topic is irrelevant.

Week 1: addressing and the switched path

Spend the first sessions on subnet boundaries, host/gateway decisions and IPv6 address types. Calculate networks from host addresses as well as assigning prefixes from host requirements. Explain when a host resolves the destination’s MAC and when it resolves the gateway’s.

Then build VLANs across two switches. Verify an access port, an operational trunk and MAC learning. Add LACP and inspect the actual bundle rather than counting physical links. Draw the Rapid PVST+ root and port roles for the VLAN you are testing.

Fault exercises: use an incorrect host mask, omit one authorized VLAN from the trunk list, assign an endpoint to the wrong VLAN and set both LACP peers passive. Change only one condition per trial. Save the command output that distinguishes each fault.

Exit evidence: calculate a /27 without a lookup table, trace a frame across the VLAN, explain a normal blocked STP path and restore the broken case without rebuilding everything. If you cannot explain why VLAN 10 works while VLAN 20 fails, repeat the trunk exercise.

Week 2: routing and OSPFv2

Construct overlapping installed routes and predict the next hop for several destinations. Keep longest-prefix lookup separate from administrative distance and protocol metrics. Configure default, network, host and floating static routes; include IPv6 static routing in the lab rather than leaving IPv6 as vocabulary alone.

Configure single-area OSPFv2 on a two-router link. Inspect neighbors and learned routes separately. Where your topology supports it, compare point-to-point behavior with a broadcast segment’s DR/BDR roles. Explain what a router ID identifies and why process IDs need not match.

Fault exercises: remove a return route, put an OSPF-facing interface in passive mode, introduce an area mismatch and remove a LAN from OSPF participation. Predict which evidence changes before collecting it.

Exit evidence: identify the selected next hop, establish the expected adjacency and verify remote reachability from the client. Explain why an adjacency can work while a particular LAN route remains missing. Describe what an FHRP protects without turning v1.1 revision into an OSPFv3 configuration course.

Week 3: services, access controls, wireless and automation

Use the same topology to connect service configuration with actual traffic. Configure the DHCP client/relay and NAT tasks appropriate to the blueprint; inspect lease information and translations. Review NTP, DNS, syslog, SNMP and QoS by the question each service answers. For device access, verify SSH and the intended authentication behavior.

Create an ACL requirement with both an allowed flow and a prohibited flow. Inspect source, destination, protocol and direction before entering commands. Test that the approved service works while the restriction remains effective. Review DHCP snooping, DAI and port security through their trust boundaries and violation behavior.

For wireless, separate association, authentication, addressing and application access. Use a supported WLAN interface or lab to practise the stated configuration work. A client seeing an SSID is only an early checkpoint.

Reserve distinct sessions for APIs, JSON, controller-based networking and configuration-management capabilities. Read a small JSON response, identify data types and explain what a REST operation asks the system to do. Include AI/ML concepts already present in v1.1, while keeping the upcoming v2.0 operational additions on their own checklist.

Exit evidence: diagnose whether a failure belongs to DNS, DHCP, access control or forwarding; read an ACL in packet direction; distinguish a Boolean from a string in JSON; and explain why an AI suggestion needs validation against actual network facts.

Week 4: integrate and repair

Attempt the free practice set under consistent conditions and use fresh app questions where available. Treat the public set’s length and written formats as practice choices, not a prediction of Cisco’s item count or hands-on interface.

Group misses by the decision that failed: prefix calculation, output interpretation, command choice, security requirement or time management. Rebuild the corresponding lab and change its conditions. A wrong answer about ACL direction should produce another packet-path exercise, not just another reading of the same explanation.

Run a final small end-to-end scenario: client obtains addressing, reaches its gateway, resolves a service name and accesses the permitted application. Introduce one fault, explain it from evidence, repair it and verify a prohibited flow remains blocked. Use the worked scenario guide as a model for the reasoning structure.

A practical 60-minute session

This is an adjustable routine. When time is short, complete one reasoning-and-verification cycle rather than rushing through many unreviewed questions.

Readiness checks before booking

You should be able to explain an answer without its letter, complete core configuration tasks without copying and interpret output from a changed topology. Distinguish mistakes caused by missing knowledge from those caused by overlooking a constraint. A repeated high score on the same set is not a pass guarantee or sufficient proof of practical readiness.

Use the Cheat Sheet for final recall, the official resources for source verification and Cisco’s current appointment policies for booking. If your test date moves beyond February 2, 2027, switch to the v2.0 plan and assess its changed tasks explicitly.

Scope checked September 13, 2026 against Cisco’s v1.1 exam topics and Cisco’s version-transition announcement .