Cisco CCNA 200-301 v2.0 Study Plan

Upcoming exam: v2.0 testing starts February 3, 2027. Testing earlier? Use CCNA v1.1 .

This plan prepares for CCNA v2.0 testing from February 3, 2027. Use the six stages as an adjustable revision schedule, not a promise that every candidate needs six weeks. New learners should spend longer on addressing, switching and routing; candidates with recent v1.1 study can retain demonstrated skills and concentrate on the changes.

The blueprint maps the five domains. Here, the goal is to produce lab evidence: what you predicted, what the device showed and what confirmed recovery.

Start with a transition diagnostic

Test yourself on a host-to-server path with two VLANs and a routed link. Can you distinguish an addressing fault, a trunk fault and a missing return route? Then attempt one IPv6 routing task and one operational-output review. Use the results to choose where to spend time.

The table is an editorial study bridge. Use Cisco’s exact topic verbs for the authoritative scope, and do not assume that every familiar topic requires no further practice.

Build a lab and an evidence notebook

Use a supported simulator, virtual environment or physical equipment with two switches, two routers and client/server endpoints. Add a redundant gateway pair for FHRP status exercises. Confirm your chosen images support the required OSPFv3 and Layer 2 protection tasks; use documented alternatives when a simulator omits a feature.

Keep a device inventory, interface map, addressing plan and known-good baseline. Use documentation networks such as 192.0.2.0/24, 198.51.100.0/24 and 2001:db8::/32 for written examples. Store credentials separately from any shareable transcript.

For each trial, keep four items: the requirement, a prediction, the relevant output and a recovery test. Record unobserved devices or failed collection attempts explicitly. This habit also prevents an AI summary from making incomplete evidence look complete.

Stage 1: physical, client and DHCP troubleshooting

Start with link state, counters and the host’s address, mask, gateway and resolver. Calculate subnet boundaries from the actual configuration. Compare an incorrect mask with a missing gateway; they can produce different packet behavior even when both cause remote access failure.

Build a local DHCP-server exercise, then place the server across a routed boundary and add a relay. Inspect the client’s options as well as whether it obtained a lease. Review RF/channel interference separately from wireless authentication and IP-service faults.

Controlled faults: wrong host mask, wrong DNS option, absent relay, exhausted pool and an interface issue supported by observable counters. Avoid introducing several faults at once until you can distinguish each individually.

Checkpoint: identify the first failing boundary and justify a test that could change your diagnosis. Explain why a successful static-host ping does not prove that the DHCP broadcast/relay path works.

Stage 2: access switching and topology evidence

Configure VLANs, trunks, SVIs and a supported LACP bundle. Compare CDP/LLDP results with the topology drawing; deliberately move a cable and update the evidence. For endpoint connectivity, include a case involving an AP, phone or virtualized host so you must consider port attributes rather than applying one desktop recipe everywhere.

Configure Rapid PVST+ behavior in a redundant topology and identify the actual root/port roles. Examine BPDU guard, root guard and loop guard according to the boundary each protects. Include PoE state and budget in a powered-endpoint case.

Controlled faults: remove one VLAN from a trunk’s allowed list, make both LACP peers passive and introduce an unexpected switch on a protected edge in an isolated lab.

Checkpoint: distinguish an intentional protection action from the original cause. Explain why disabling STP or a guard feature can restore a symptom while creating a larger problem. Verify both the repaired VLAN and an unaffected VLAN after a change.

Stage 3: routing, OSPFv3 and gateway resilience

Predict next hops using overlapping installed routes. Practise IPv4 and IPv6 static routes, including host/default/floating routes and return paths. Inspect the routing and forwarding evidence supported by your platform.

Build single-area OSPFv2 and OSPFv3 separately before combining dual-stack evidence. Choose one supported OSPFv3 syntax family and give routers distinct IDs. Check a learned remote prefix after neighbor formation; adjacency and prefix advertisement are separate outcomes.

Inspect HSRP/VRRP virtual addresses and roles. Configure a test client incorrectly with a physical gateway address, then observe why a healthy role transition does not help that client.

Checkpoint: diagnose an area mismatch, recognize a normal broadcast-network 2-Way relationship where appropriate and explain why a source-specific ping can expose a return-path failure hidden by a normal router ping. Keep OSPF neighbor authentication outside the stated v2.0 configuration objective.

Stage 4: services and security requirements

Build an ACL case with one permitted service and a protected subnet. Verify the allowed flow and at least two prohibited flows. Inspect NAT/PAT translations and interface roles, then distinguish translation failure from missing return routing.

Review AAA client behavior and local access, secure configuration-file transfer and the named DNS record types. Test DNS through the resolver actually used by the client. Work through DHCP snooping, DAI, RA guard, storm control and port-security examples with clear trust boundaries.

Checkpoint: provide evidence that the service works and the restriction still holds. Explain why an HTTPS-only requirement is not satisfied by a broad permit ip merely because the application becomes reachable.

Stage 5: operational collection and AI review

Use a properly scoped Ansible inventory to collect a small set of read-only commands. Inspect success, unreachable and failed results separately. Compare the returned state with the design instead of treating task completion as proof of network health.

Read syslog messages for facility, severity, timestamp and event content; connect them with interface or protocol evidence. Review SNMP’s polling and notification roles and the differences among device-, controller-, cloud- and automation-based management.

Give an AI assistant sanitized evidence and ask for hypotheses, a distinguishing check and explicit assumptions. Then review a deliberately overbroad proposed ACL change. Record why it fails the original requirement even if its syntax is valid.

Checkpoint: identify the devices actually observed, what remains unknown, the scope of any proposed action and the tests that would validate it. The scenario guide includes an example collection task and an AI-proposal review.

Stage 6: integrated practice and targeted repetition

Attempt the free practice set under consistent conditions, then use fresh app questions and changed lab conditions. Written practice complements hands-on work; the public set’s length and interaction mix are editorial, not a reproduction of Cisco’s testing interface.

Allocate new sessions according to demonstrated weakness while retaining coverage of all domains. Infrastructure and Switching account for half the official weight together. AI and operations deserves its own practice, but should not consume time needed to understand packet forwarding.

Use an error log that changes the next session

Finish with a small unseen end-to-end fault. State the requirement, collect decisive evidence, make a supported correction and verify client service plus preserved restrictions. Use the Cheat Sheet for recall and official resources to check platform details and appointment guidance as the launch approaches.

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