Cisco CCNA 200-301 v1.1 Scenario Practice Guide

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

A useful CCNA scenario gives you a requirement and enough evidence to make a decision. The skill is to connect them: locate the failing boundary, choose a correction supported by the facts and predict how you would verify it. These original worked cases use simplified lab exhibits; command availability and formatting vary by IOS/IOS XE platform.

Read each case up to Reasoning before reading the solution. Write one conclusion the evidence supports and one thing it does not yet establish. Use the Cheat Sheet when a command or rule needs refreshing.

Case 1: a host has the wrong subnet mask

A branch uses 192.0.2.64/27. Its gateway is 192.0.2.65, and a client has address 192.0.2.77. A remote server uses 192.0.2.130/26 behind the router. The client can reach its gateway but not the server. Other clients with the branch’s intended /27 mask reach the server successfully.

The affected client’s configuration shows:

IPv4 address: 192.0.2.77
Subnet mask: 255.255.255.0
Default gateway: 192.0.2.65

A packet capture on its VLAN shows repeated ARP requests for 192.0.2.130, with no answer. The lab does not use proxy ARP.

Reasoning: the /24 mask makes this client believe .130 is local. It therefore asks for the server’s MAC address instead of sending a frame to the gateway. Gateway reachability is consistent with this fault: .65 is considered local under either mask.

The intended /27 places .77 in network .64, with usable addresses .65–.94 and broadcast .95. Correct the mask through the actual configuration source—DHCP if supplied by DHCP, or the static host configuration. Do not compensate by creating a larger routed subnet or adding an unrelated DNS record.

Verify: confirm the corrected mask, clear or let stale neighbor information expire as appropriate, and retest the server. The client should now resolve the gateway’s MAC for that remote destination. Check application access as well as ICMP where permitted.

Change the case: if the host had the correct /27 and already sent frames to the gateway, the ARP explanation would no longer fit. Inspect the next boundary rather than applying the remembered answer.

Case 2: one VLAN disappears across a working trunk

Two switches are connected by an operational trunk. VLAN 10 works across it. Hosts in VLAN 20 work locally on each switch but cannot communicate across the inter-switch link. Both switches have VLAN 20, and their endpoint ports are assigned correctly.

    flowchart TD
	    A["Host A: VLAN 20"] --> S1["Switch 1"]
	    S1 -->|"Trunk: VLAN 10 passes; VLAN 20 fails"| S2["Switch 2"]
	    S2 --> B["Host B: VLAN 20"]

The administrator extracts these facts from show interfaces trunk:

Reasoning: a trunk can be up while filtering one VLAN. The allowed list on Switch 2 does not carry VLAN 20. The fact that VLAN 10 works narrows the fault but does not validate every VLAN. The absence of a VLAN from the allowed set must be resolved before expecting it in the forwarding set.

If VLAN 20 is authorized on this link, add it while preserving the existing list:

interface GigabitEthernet1/0/24
 switchport trunk allowed vlan add 20

This assumes GigabitEthernet1/0/24 is the actual uplink on Switch 2. The add keyword matters: replacing the list with only 20 would remove VLAN 10. If the link is an EtherChannel, inspect and change the appropriate port-channel configuration consistently instead.

Verify: inspect the allowed, active and forwarding VLAN information on both ends, then test between the affected endpoints and confirm VLAN 10 still works. If VLAN 20 remains blocked after being allowed, examine spanning-tree state and topology rather than repeatedly changing the VLAN list.

Change the case: when all lists already contain VLAN 20, a wrong endpoint access VLAN, a missing local VLAN or STP state could require a different correction.

Case 3: select a route without mixing comparisons

A router has the following installed routes. The next hops are reachable, and the question asks only which next hop it uses for destination 10.40.8.25.

Reasoning: .25 matches the first three prefixes but not the /25 covering .128–.255. Of the matching installed routes, /24 is longest, so the next hop is 192.0.2.10. Its higher administrative distance does not make the shorter OSPF route win.

Administrative distance matters when choosing between competing sources for the same prefix. This exhibit already states that the routes are installed. Route lookup is not an election between every AD number in the table.

Verify: show ip route 10.40.8.25 should identify the selected matching route. A packet test then checks forwarding, but a failure would require further evidence about next-hop resolution, filtering, return routing or the destination. It would not retroactively change the longest-prefix rule.

Change the case: use destination 10.40.8.200; now the /25 matches and wins. Remove the /24 for the original .25 destination; the /16 becomes the best remaining match. These variations test understanding more effectively than memorizing one next hop.

Case 4: an OSPF link works but no neighbor forms

Two routers share a routed Ethernet link. Addresses and masks agree, interfaces are up, direct pings succeed and no ACL blocks OSPF. Router IDs are unique. Their relevant configurations are:

R1:
router ospf 10
 passive-interface default
 network 192.0.2.0 0.0.0.3 area 0

R2:
router ospf 20
 network 192.0.2.0 0.0.0.3 area 0

On R1, GigabitEthernet0/0 is the shared link. Its OSPF interface output reports that it is passive.

Reasoning: R1’s passive interface does not send OSPF Hellos. IP connectivity can therefore work while neighbor formation fails. Different process IDs—10 and 20—are not the problem, because the IDs are locally significant.

Enable neighbor exchange on the intended link while keeping the passive-by-default design elsewhere:

router ospf 10
 no passive-interface GigabitEthernet0/0

Verify: check neighbor state, interface area/network type and learned routes. On this two-router broadcast segment, expect an appropriate DR/BDR relationship and a Full adjacency after convergence. If a shared segment has additional routers, a 2-Way relationship between DROTHERs can be normal; interpret the roles before declaring failure.

Change the case: with no passive setting, compare areas, timers and network type, then inspect the actual neighbor state. Do not reset the entire routing process as the default response to every missing route. A formed adjacency also does not prove that every desired LAN prefix participates in OSPF.

Case 5: permit one application without opening a subnet

VLAN 20 clients in 192.0.2.0/26 may reach an application at 198.51.100.10 on TCP 443. Other traffic from that subnet to 198.51.100.0/24 must remain blocked. Existing unrelated permissions must remain intact.

The inbound ACL on the clients’ routed interface currently contains:

ip access-list extended USERS_IN
 20 deny ip 192.0.2.0 0.0.0.63 198.51.100.0 0.0.0.255
 30 permit ip any any

A proposed repair adds the HTTPS permit at sequence 40.

Reasoning: sequence 20 already matches the application packet. Evaluation stops there, so a permit at 40 cannot help. A narrowly scoped permit must precede the subnet-wide deny:

ip access-list extended USERS_IN
 10 permit tcp 192.0.2.0 0.0.0.63 host 198.51.100.10 eq 443

The wildcard .63 selects the /26 source range; host limits the destination to one address. This is a targeted edit to the stated existing ACL, not a universal security baseline. A TCP permit is also not a stateful firewall session policy.

Verify: check ACL attachment/direction and counters. Test HTTPS to the approved host, a prohibited port on that host and a prohibited destination in the protected subnet. Confirm unrelated allowed traffic still behaves as intended. A successful HTTPS request alone is insufficient because the requirement also includes continued blocking.

Change the case: if the ACL were evaluated after a relevant translation or on a different interface, reassess the packet fields at that point. Do not copy addresses from the host diagram without considering the processing context. Cisco explains ordering and implicit deny in its IP ACL guide .

Case 6: separate wireless, DNS and application faults

A wireless client associates successfully, authenticates, receives the expected address and gateway, and reaches a lab web service by its IP address. Access through portal.example.com fails. The client uses the intended DNS resolver. That resolver returns an old IPv4 address for the name; the service moved yesterday.

Reasoning: RF tuning, changing the WLAN key and rebuilding the access VLAN do not address the supplied fault. The evidence points to name resolution. Confirm the authoritative record and caching path, correct the record at its actual source if wrong, and account for the cached record’s TTL. Do not assume flushing one client updates the authoritative zone.

The successful IP-based test establishes this client’s path to the tested service under the stated test conditions. It does not prove every application endpoint works. In real HTTPS testing, hostnames and certificates can affect results; use a controlled test appropriate to the application rather than treating an arbitrary browser error as pure network evidence.

Verify: query the configured resolver again, confirm the expected address and retry using the name. Verify from another affected client when appropriate. If the resolver now returns the correct address but access still fails, examine the new evidence rather than continuing to change DNS.

Change the case: if authentication never completes, investigate the security exchange first. If no lease is obtained, inspect DHCP and VLAN mapping. The same complaint—“Wi-Fi is broken”—can refer to several distinct failures.

Use multiple-answer questions carefully

For Select TWO items, assess each statement independently against the same facts. A valid observation and a valid correction can both be required, but one true statement does not make its neighboring option true. Keep track of the requested number of selections, and evaluate what each option says rather than relying on a remembered letter.

Keep a diagnosis log with evidence

Use one row per meaningful mistake. Repeat the same principle with changed addressing, direction or topology until you can explain the result without referring to the original options. Continue with the free practice exam and the study plan for a schedule of labs and review.

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