{"id":12694,"date":"2026-10-12T14:30:06","date_gmt":"2026-10-12T14:30:06","guid":{"rendered":"https:\/\/www.examcollection.com\/blog\/ccna-200-301-v11-v20-february-2027\/"},"modified":"2026-10-12T14:36:34","modified_gmt":"2026-10-12T14:36:34","slug":"ccna-200-301-v11-v20-february-2027","status":"publish","type":"post","link":"https:\/\/www.examcollection.com\/blog\/ccna-200-301-v11-v20-february-2027\/","title":{"rendered":"CCNA v1.1 vs v2.0: What Changes in February 2027"},"content":{"rendered":"

CCNA v1.1 vs v2.0: What Changes in February 2027<\/h1>\n

There are two different Cisco CCNA study decisions in late 2026, and the distinction comes down to a date. Cisco will deliver the existing 200-301 CCNA v1.1 exam for the final time on February 2, 2027. The revised v2.0 exam begins February 3. The certification and exam code remain CCNA and 200-301, but the published skills measured are not identical. Before committing to a course, a simulator lab schedule, or the Cisco 200-301 exam<\/a> preparation route, match the material to the exam version you will actually sit.<\/p>\n

That does not mean someone studying in October 2026 should abandon routing, switching, or security fundamentals until the new version arrives. Most of the useful skills transfer. What changes is how Cisco organizes the objectives, the practical verbs attached to them, and which operational evidence candidates must be able to interpret. An exam-date decision therefore matters more than trying to memorize a long list of renamed domains.<\/p>\n

The date determines the blueprint<\/h3>\n

If your booking falls on or before February 2, 2027, v1.1 is the current target. Prepare for its six weighted domains and the commands, behaviors, and interpretations Cisco actually lists in that version. If your booking is February 3 or later, use Cisco’s published v2.0 topics from the start of your focused review. Studying from a v1.1 book does not become worthless on the transition date, but it needs a deliberate gap check against the future outline.<\/p>\n

Cisco describes both exams as 120-minute assessments. The scheduled transition is not a new prerequisite for CCNA or a requirement to earn another credential first. A candidate who is close to readiness can reasonably prefer the established version, while someone whose realistic study timeline runs into spring 2027 should deliberately prepare for v2.0. Neither choice is inherently more prestigious; the practical question is whether you can show the networking skill under the tested objectives.<\/p>\n

Six v1.1 domains become five v2.0 domains<\/h3>\n

The easiest comparison is to look at the two objective sets separately. Simply pairing domain 1.0 against domain 1.0 would imply that every topic has moved one-for-one, which is misleading. Cisco changed both the groupings and, in some places, the expected task.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Current CCNA v1.1 domain<\/th>\nWeight<\/th>\n<\/tr>\n<\/thead>\n
Network Fundamentals<\/td>\n20%<\/td>\n<\/tr>\n
Network Access<\/td>\n20%<\/td>\n<\/tr>\n
IP Connectivity<\/td>\n25%<\/td>\n<\/tr>\n
IP Services<\/td>\n10%<\/td>\n<\/tr>\n
Security Fundamentals<\/td>\n15%<\/td>\n<\/tr>\n
Automation and Programmability<\/td>\n10%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n\n
Scheduled CCNA v2.0 domain<\/th>\nWeight<\/th>\n<\/tr>\n<\/thead>\n
Network Infrastructure and Connectivity<\/td>\n25%<\/td>\n<\/tr>\n
Switching and Network Access<\/td>\n25%<\/td>\n<\/tr>\n
IP Routing<\/td>\n20%<\/td>\n<\/tr>\n
Network Services and Security<\/td>\n20%<\/td>\n<\/tr>\n
AI, and Network Operations and Management<\/td>\n10%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In v1.1, the combined Network Fundamentals and Network Access domains account for 40 percent. In v2.0, infrastructure\/connectivity and switching\/access total 50 percent. That does not mean the new exam ignores routing; IP Routing still accounts for a fifth of the objectives. It does mean that a learner who treats cabling, wireless clients, VLANs, trunking, and switch verification as easy background material would be poorly aligned with the future emphasis.<\/p>\n

Infrastructure questions move closer to actual fault isolation<\/h3>\n

The v1.1 outline asks candidates to configure and verify addressing, identify interface and cabling problems, and understand wireless principles. The v2.0 outline more explicitly says to diagnose<\/em> copper or fiber problems, troubleshoot IPv4 and IPv6 client addressing, investigate wireless-client connectivity, and troubleshoot DHCPv4 client, server, and relay behavior on IOS devices. These verbs should change how you rehearse a lab. A diagram alone is not evidence that the network is healthy.<\/p>\n

For an IPv4 example, configure two subnets, a default gateway, and a DHCP pool. Give a client an address with the wrong mask, then predict whether it will ARP locally or send its packet to the gateway. Compare the client route table, DHCP lease, and device interface state. An IPv6 variation can deliberately use an incorrect prefix or gateway assumption; diagnose how link-local reachability differs from reaching a remote network. This kind of exercise survives the version transition because it teaches a forwarding model rather than an isolated command.<\/p>\n

Wireless troubleshooting should take the same end-to-end view. A device might associate to an access point and still fail because its VLAN, DHCP scope, authentication policy, or upstream DNS is wrong. In v2.0, Cisco explicitly includes wired and wireless client diagnosis on Windows, macOS, and Linux. The useful habit is to distinguish association, identity, addressing, gateway reachability, name resolution, and application access instead of blaming RF conditions whenever a user reports that Wi-Fi is broken.<\/p>\n

Switching demands configuration plus verification<\/h3>\n

VLANs, trunks, LACP EtherChannel, and spanning tree are central to v1.1. In v2.0, the switching and access objectives explicitly include infrastructure and edge-port attributes, switch virtual interfaces, PoE-aware endpoint types, and troubleshooting with show commands, logs, ping, extended ping, traceroute, and packet captures. Cisco also names configuring Rapid PVST+ behavior, including PortFast, root guard, loop guard, and BPDU guard.<\/p>\n

Build a two-switch topology with a user VLAN, a voice VLAN, a management SVI, and a trunk. Break the allowed-VLAN list on one side, confirm the symptom, and compare each switch’s operational trunk state before repairing it. Introduce an LACP mismatch, then inspect which links actually joined the port-channel. After the topology works, change the root-bridge preference and predict the resulting port roles. A campus VLAN and spanning-tree example<\/a> gives useful design context, but the exam rehearsal should require proof from observed state.<\/p>\n

Do not confuse a guard feature with a universal security setting. BPDU guard may be appropriate on a properly designed edge port but can disrupt the connection when enabled on a legitimate switch uplink. A practical question can turn on where the feature is applied, what kind of neighboring device is expected, and which fault should be prevented. These are operational judgments, not vocabulary tests.<\/p>\n

Routing still matters, but the future outline is more explicit<\/h3>\n

Under v1.1, IP Connectivity is the largest domain at 25 percent. It covers route-table interpretation, longest-prefix match, static routes, single-area OSPFv2, and first-hop redundancy concepts. Under v2.0, IP Routing is 20 percent, but Cisco explicitly asks for troubleshooting IPv4 and IPv6 static routes, configuring single-area OSPFv2 for IPv4 and OSPFv3 for IPv6, and interpreting the operational status of HSRP and VRRP.<\/p>\n

A useful routing lab starts with two routers and a remote subnet. Put two candidate routes in the table, with different prefix lengths and administrative distances, and write down which route should win before looking at the output. Remove the return path to show why an outgoing route is insufficient for end-to-end connectivity. Then bring up a single-area OSPF adjacency and deliberately misalign an interface or area assumption. For v2.0 preparation, repeat the reasoning with IPv6 and OSPFv3 rather than assuming IPv4 configuration practice automatically proves the new objective.<\/p>\n

The broader OSPF and BGP comparison<\/a> can help explain where interior routing ends and policy-driven interdomain routing begins. It should not distract an associate candidate into treating BGP configuration as a replacement for the published CCNA static-route and single-area OSPF tasks. In every lab, decide whether the fault concerns adjacency, route selection, forwarding, or the return path.<\/p>\n

Network services and security become one operational group<\/h3>\n

In v1.1, IP Services and Security Fundamentals are separate domains. The v2.0 objectives bring network services and security together at 20 percent and name several concrete tasks: configuring a device as an AAA client with TACACS+ or RADIUS, using SFTP or SCP for secure file transfers, configuring NAT\/PAT and IPv4 access lists, diagnosing common DNS record failures, and applying Layer 2 controls such as DHCP snooping, dynamic ARP inspection, storm control, RA guard, and port security.<\/p>\n

To practice, make a small inside network reach a simulated outside service through NAT, then test an ACL that restricts a specific source subnet. Record where the ACL is applied and which direction it evaluates. Next, keep basic IP reachability working while breaking DNS: a client that can reach a server by address but not by name is not evidence of a routing failure. Finally, test the difference between allowing a user to log into a switch and authorizing a packet to traverse an interface. Both involve access control, but they operate at different boundaries.<\/p>\n

Security controls also need a failure model. A DHCP-snooping trust setting on the wrong switch port can block legitimate address assignment. Port security can react to more MAC addresses than expected behind a downstream device. A strong candidate must identify the control from the symptom, read the relevant operational evidence, and make a narrowly scoped correction instead of disabling protections indiscriminately.<\/p>\n

AI does not replace networking knowledge<\/h3>\n

CCNA v1.1 already acknowledges AI, machine learning, controllers, structured data, and automation. The v2.0 fifth domain expressly covers agentic AI in network operations, selecting prompts for a generative AI system, comparing device, cloud, controller and automation management approaches, using configuration management such as Ansible, and interpreting SNMP and syslog. These topics are about responsibly handling network state and operational recommendations, not about training a large language model.<\/p>\n

Imagine a network assistant proposes disabling an ACL because a branch application is unreachable. A responsible engineer must first check whether the diagnosis matches the observed route, ACL counters, policy intent, and destination service. A well-formed prompt might give a sanitized topology, the exact error, permitted changes, the desired output format, and a request to identify missing evidence. The assistant can help organize an investigation, but it does not grant authorization to alter production policy or prove a root cause simply by sounding confident.<\/p>\n

For a compact hands-on task, collect a few non-sensitive interface facts as structured data, compare them against expected state, and propose a change without applying it. Make the distinction between discovery, validation, approval, implementation, and rollback explicit. Those stages matter whether the interface is a CLI, REST API, controller, or automation tool.<\/p>\n

Choose a study sequence that serves both versions<\/h3>\n

The best shared foundation is to build one network and keep extending it. Start with addressing and subnetting. Add VLANs and trunks, then inter-VLAN routing and a second router. Configure static routes and an OSPF adjacency, make DHCP and DNS dependencies visible, apply a deliberate ACL, add a wireless client scenario, and capture operational evidence. When each step works, introduce one realistic fault and write down the expected state before issuing a diagnostic command.<\/p>\n

For a v1.1 booking, use Cisco’s six-domain blueprint as the final checklist and spend proportionate time on IP Connectivity, network fundamentals and access. For a v2.0 booking, use the five-domain outline to identify added troubleshooting depth and specific operational tasks; devote more work to client and Layer 2 failure cases, IPv6 routing, security configuration, and AI-supported network management. The existing CCNA study sequence<\/a> can remain your base, with a version-specific objective checklist layered over it.<\/p>\n

Do not switch exam versions mentally halfway through a practice question. A service or protocol can belong to different domains in the two outlines, and some tasks change from describe to configure or troubleshoot. What Cisco will assess depends on the version delivered on your test date. Build around the behavior common to both, then finish with the documented differences for the exam you actually booked.<\/p>\n

The better preparation test is operational evidence<\/h3>\n

There is no substitute for being able to explain why a packet reaches its destination or why it does not. That requires a correct addressing model, a view of switch forwarding state, a routing decision, working services, appropriate security boundaries, and evidence that the chosen repair had the expected effect. A CCNA candidate can practice those skills today without predicting every detail of a future exam question.<\/p>\n

The transition to v2.0 raises the value of that habit. Cisco is making practical diagnosis, controlled configuration, and the evaluation of AI-assisted recommendations more explicit. If you can build a topology, create a fault, explain the symptom, inspect the right evidence, and verify the repair, you have something more durable than a memorized six- or five-domain table. You have the working model of a network that both versions are meant to assess.<\/p>\n","protected":false},"excerpt":{"rendered":"

CCNA v1.1 vs v2.0: What Changes in February 2027 There are two different Cisco CCNA study decisions in late 2026, and the distinction comes down to a date. Cisco will deliver the existing 200-301 CCNA v1.1 exam for the final time on February 2, 2027. The revised v2.0 exam begins February 3. The certification and\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2342,2345],"tags":[],"class_list":["post-12694","post","type-post","status-publish","format-standard","hentry","category-certifications","category-cisco"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t