Cisco CCNA 200-301 v2.0 Scenario Practice Guide

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

CCNA v2.0 preparation benefits from small operational cases: inspect the supplied state, explain the failure and select a correction that preserves the requirement. These original examples include simplified exhibits rather than captured production output. Cisco IOS/IOS XE syntax and feature support vary; confirm the relevant platform documentation when reproducing a case.

Use the Cheat Sheet for command recall. Here, pause before each Reasoning section and write the next check or correction, plus the evidence that would prove it worked.

Case 1: DHCP succeeds locally but fails across a routed boundary

Clients in VLAN 20 should receive 192.0.2.0/26 addresses from an IOS DHCP server at 198.51.100.10. The server has the correct pool and available leases. A statically configured VLAN 20 test host can reach the server, and the server has a return route. No relevant ACL filters the traffic. Automatic clients send Discover messages but receive no Offer.

    flowchart TD
	    C["VLAN 20 client: DHCP Discover"] --> S["Gateway SVI: 192.0.2.1/26"]
	    S -->|"Routed network"| D["DHCP server: 198.51.100.10"]
	    D --> P["Pool: 192.0.2.0/26"]

The client-facing SVI configuration is:

interface Vlan20
 ip address 192.0.2.1 255.255.255.192
 no shutdown

Reasoning: ordinary IP reachability does not forward the client’s initial broadcast across the routed boundary. The stated remote-server design needs a relay on the interface receiving that broadcast. Add the helper to VLAN 20’s SVI:

interface Vlan20
 ip helper-address 198.51.100.10

Changing the server pool or client mask is unsupported because the exhibit already establishes the intended pool and static-path reachability. Adding the helper on an arbitrary transit interface would miss the client’s initial broadcast.

Verify: renew a test client’s lease; check server bindings and confirm address, mask, gateway and DNS options. The relay’s gateway-address information should identify the VLAN 20 subnet. Then test gateway and required application access. Obtaining any address is not enough if the supplied options are wrong.

Variation: if the relay already exists, check whether the server has selected the correct pool, exhausted its leases or encountered a return-path/filtering problem. Keep the original evidence separate from the new hypothesis. See Cisco’s DHCP guide .

Case 2: IPv4 works while OSPFv3 has no neighbor

R1 and R2 share an Ethernet link. IPv4 connectivity and OSPFv2 are healthy. Their IPv6 addresses are in the same /64, direct IPv6 pings succeed, router IDs are distinct and no filtering blocks OSPFv3. The IPv6 address-family interface commands differ:

R1 interface GigabitEthernet0/0:
 ipv6 address 2001:db8:12::1/64
 ospfv3 10 ipv6 area 0

R2 interface GigabitEthernet0/0:
 ipv6 address 2001:db8:12::2/64
 ospfv3 20 ipv6 area 1

The intended design has this link in area 0. Both devices otherwise have the required IPv6 routing and OSPFv3 process configuration.

Reasoning: IPv4 operation does not establish correct IPv6 routing-protocol configuration. The shared-link area differs. Correct R2’s IPv6 OSPFv3 area to 0 using the supported IOS XE interface syntax. Process IDs 10 and 20 can remain different; they are local identifiers.

After removing the incorrect area assignment, the relevant R2 interface command should read:

ospfv3 20 ipv6 area 0

Verify: inspect show ospfv3 interface, show ospfv3 neighbor and show ipv6 route. Confirm the neighbor forms, then check that intended remote prefixes are actually learned and test a remote IPv6 destination. A neighbor can form without advertising a LAN that was never included in the process.

Do not copy an OSPFv2 network statement into an OSPFv3 interface-based configuration and assume it enables the IPv6 address family. Use one syntax family appropriate to the image; Cisco documents the OSPFv3 address-family configuration .

Variation: if areas already match, examine actual state, timers, participating interfaces and network type. On a broadcast network, distinguish a normal 2-Way relationship between DROTHERs from a failed expected adjacency.

Case 3: healthy HSRP, wrong client gateway

Two routers provide redundant gateways for VLAN 30. The HSRP virtual address is 192.0.2.1; R1 and R2 use physical addresses .2 and .3. The subnet is /26. Their summarized status is:

Client A uses gateway .1. Client B uses .2. During an isolated lab failure of R1, R2 becomes active and Client A continues to work after convergence; Client B loses remote connectivity. Both clients remain in the correct VLAN and subnet.

Reasoning: Client B bypasses the virtual gateway by using R1’s physical address. A correct HSRP failover does not transfer ownership of that physical address to R2. Fix the client’s gateway at its configuration source. If DHCP supplies it, correct the intended pool option and renew the affected lease; do not merely edit a client that will receive the wrong option again.

Changing HSRP priority is not supported by this evidence. The routers have already performed the intended role transition, demonstrated by Client A’s behavior.

Verify: inspect the client’s actual gateway, test normal operation, repeat controlled failover and verify restoration. Account for convergence rather than demanding zero packet loss. Review the relevant virtual address and roles with show standby brief; VRRP uses its own status command and master/backup terminology.

Variation: if every client uses the virtual gateway and fails together, inspect VLAN reachability, FHRP state and upstream forwarding. A working control-plane role is not a promise that all data-plane paths are healthy. Cisco’s HSRP overview explains the virtual-gateway model.

Case 4: the native router test hides a missing return route

A distribution switch routes VLAN 20, 192.0.2.0/26, and reaches an upstream router over 198.51.100.0/30. The switch’s transit address is 198.51.100.1; the upstream address is .2. A server is reachable beyond the upstream router at 203.0.113.10. No ACL or NAT is present in this lab.

    flowchart TD
	    H["Client: 192.0.2.20"] --> D["Distribution: VLAN 20 gateway"]
	    D -->|"198.51.100.0/30"| R["Upstream router"]
	    R --> S["Server: 203.0.113.10"]
	    R -.->|"Missing route back to 192.0.2.0/26"| D

A normal ping from the distribution switch uses its transit address and succeeds. A ping sourced from Vlan20 fails. VLAN 20 clients reach their gateway. The upstream route table contains a route to the server and its connected transit network, but no route covering 192.0.2.0/26 and no default route.

Reasoning: the two pings test different return destinations. Replies to 198.51.100.1 have a connected return path; replies to VLAN 20 do not. The route-table evidence now establishes the missing return route, rather than merely suggesting it.

If static routing is the intended design, the upstream router needs:

ip route 192.0.2.0 255.255.255.192 198.51.100.1

Recreating VLAN 20 would not fix the upstream return path. Adding NAT could conceal the missing route while changing the design; it is not the required correction in this private routed lab.

Verify: inspect the installed route and next-hop resolution, repeat the source-specific test and then test from the client. A router-originated success is useful, but the original complaint belongs to the client path.

Variation: without the upstream route-table evidence, source-dependent filtering would remain another plausible hypothesis. State the uncertainty and choose a distinguishing check rather than asserting that every source-specific failure is a route fault.

Case 5: an AI assistant proposes an overly broad ACL repair

Users in 192.0.2.0/26 may access server 198.51.100.10 on TCP 443. They must not access other systems in 198.51.100.0/24. An inbound ACL on the users’ routed interface currently denies the whole destination subnet before its existing unrelated permits.

The assistant proposes inserting:

permit ip 192.0.2.0 0.0.0.63 198.51.100.0 0.0.0.255

Reasoning: this could restore the requested application and also open every IP protocol to every address in the protected subnet. The proposal fails the continued-restriction requirement. “It fixes access” is only half of the acceptance test.

The appropriate new entry must limit protocol, destination and port, and must appear before the matching deny:

permit tcp 192.0.2.0 0.0.0.63 host 198.51.100.10 eq 443

This is the required entry shape, not an instruction to replace the entire ACL. Preserve existing rules and verify attachment, direction and sequence. Review the packet fields as seen at that interface.

A better follow-up prompt would provide the sanitized current ACL and ask:

Compare this proposal with the requirement.
Keep all unrelated permissions and the protected-subnet restriction.
Return the smallest candidate edit, its insertion position,
one permitted-flow test and two prohibited-flow tests.
List assumptions separately; do not claim to have applied the change.

Verify: test approved HTTPS, a disallowed service on the same host and another protected host. Inspect counters and any management-path effect. The operational owner decides whether and how to apply a reviewed change; generated text alone is not authorization.

Variation: an assistant can return syntactically valid commands that target the wrong interface or device. Check scope and topology, not just grammar. This is why v2.0’s AI work belongs alongside network evidence rather than replacing it.

Case 6: review an automation result

An administrator wants to collect VLAN and trunk evidence from two access switches. The Ansible inventory and connection settings already identify supported IOS devices, and credentials are managed outside the playbook. This read-only task illustrates the intended work:

- name: Collect access-switch evidence
  hosts: access_switches
  gather_facts: false
  tasks:
    - name: Read VLAN and trunk state
      cisco.ios.ios_command:
        commands:
          - show vlan brief
          - show interfaces trunk
      register: access_state
    - name: Display returned evidence
      ansible.builtin.debug:
        var: access_state.stdout_lines

The report says Switch A completed successfully and Switch B was unreachable. Switch A’s output shows VLAN 20 allowed but not forwarding on the expected uplink. The overall automation run has ended.

Reasoning: the run produced useful evidence for one switch and no current evidence for the other. It did not prove that both switches are healthy or apply a correction. Investigate Switch B’s management reachability/authentication separately, and inspect VLAN/STP state for Switch A before choosing a change.

A module returning successfully means the requested command execution completed under that module’s criteria. It does not mean every state in the returned text matches the design. Compare outputs with the expected network behavior and the correct device identity. See the official cisco.ios.ios_command documentation for prerequisites and returned fields.

Verify: obtain fresh evidence from the correct devices, record failed targets explicitly and keep collection separate from remediation. If a later configuration task is proposed, review its scope and expected state change before treating it as equivalent to this read-only task.

Variation: a syslog message with severity 5 can report a normal state transition; a severity 3 message may indicate an error. Read the device, facility, mnemonic, timestamp and message. Neither the severity alone nor an AI-generated summary replaces the actual evidence.

A repeatable review method

For every case, record five things: the requirement, the decisive observation, the selected action, the alternative you rejected and the recovery test. Add a sixth field when using AI or automation: what was assumed or not observed.

Repeat cases with changed addresses, interface directions and failure locations. Use the study plan to schedule the corresponding labs, then attempt the free practice exam without relying on familiar option positions.

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