Reinforce 300-410 concepts with active-recall study cards covering all 4 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For 300-410 preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the 300-410 question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your 300-410 flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real 300-410 exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass 300-410.
Sample cards from the 300-410 flashcard bank. Read the question, think of the answer, then read the explanation below.
Consider the following DHCPv6 configuration on router R2: ipv6 dhcp pool DHCP6_POOL dns-server 2001:db8::1 domain-name example.com ! interface GigabitEthernet0/0 ipv6 address 2001:db8:1::1/64 ipv6 dhcp server DHCP6_POOL ipv6 nd other-config-flag no shutdown What is the effect of this configuration?
Hosts on this subnet will use SLAAC to obtain their IPv6 address and then use DHCPv6 to get DNS and domain information.
The configuration uses the `ipv6 nd other-config-flag` command, which sets the 'Other Configuration' flag (O-flag) in Router Advertisement (RA) messages. This tells hosts to use Stateless Address Autoconfiguration (SLAAC) for their IPv6 address (based on the prefix in the RA) and then use DHCPv6 (stateless DHCPv6) only to obtain additional parameters like DNS server and domain name, as defined in the DHCPv6 pool.
A network engineer runs the following command to troubleshoot a Control Plane Policing (CoPP) issue: R1# show bgp neighbors 10.1.1.2 received-routes BGP table version is 10, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.3.3.0/24 10.1.1.2 0 100 0 i Total number of prefixes 1 What does this output indicate?
BGP is receiving routes correctly, and CoPP is not interfering with inbound updates.
The output shows a single BGP prefix (10.3.3.0/24) received from neighbor 10.1.1.2, with the route marked as valid (*) and best (>). This confirms that BGP is successfully receiving and processing the update, and the route is eligible for installation in the routing table. Since the route appears in the received-routes output, CoPP is not dropping the inbound BGP update packets, as CoPP would prevent the packets from reaching the BGP process entirely.
When using the 'access-group' command to apply an ACL to an interface, what is the default direction if none is specified?
The command is rejected without a direction keyword.
The 'access-group' command in Cisco IOS requires a direction keyword (either 'in' or 'out') to specify whether the ACL filters inbound or outbound traffic. If no direction is provided, the command is rejected with an error message because the direction is a mandatory parameter. This behavior is consistent across all Cisco IOS versions and platforms.
An engineer configures an IPsec VPN between two routers using a transform-set with ESP encryption (AES 256) and ESP authentication (SHA-256). The engineer also applies an IPv4 ACL to define interesting traffic that matches all IP traffic. After configuration, the VPN tunnel comes up, but only ICMP traffic is encrypted; other traffic like HTTP is sent in clear text. What is the most likely explanation?
The ACL for interesting traffic only permits ICMP, so only ICMP is encrypted.
The most likely explanation is that the ACL for interesting traffic only permits ICMP, so only ICMP is encrypted. In Cisco IOS, the crypto map uses the ACL to identify which traffic should be protected by IPsec. If the ACL only matches ICMP (e.g., 'permit icmp any any'), then only ICMP packets trigger IPsec encryption; all other traffic, such as HTTP, is forwarded in clear text because it does not match the ACL and is therefore not subject to IPsec processing.
On a DMVPN Phase 2 hub-and-spoke network, an engineer applies an inbound IPv4 ACL on the tunnel interface of a spoke router to permit only traffic from specific spoke IPs. After the ACL is applied, the spoke cannot establish a direct spoke-to-spoke tunnel with another spoke, even though NHRP resolution succeeds. What is the most likely explanation?
The ACL is filtering the outer IP header of the mGRE tunnel, blocking spoke-to-spoke traffic.
In a DMVPN Phase 2 network, spoke-to-spoke traffic is encapsulated in a new IP header with the destination IP set to the target spoke's public address. When an inbound ACL is applied to the spoke's tunnel interface, it filters traffic after decapsulation, meaning it inspects the inner (original) IP header. However, the ACL is applied on the physical interface or the tunnel interface in a way that inadvertently filters the outer IP header of the mGRE tunnel, blocking the encapsulated spoke-to-spoke packets before they can be processed. Since NHRP resolution succeeds, the spoke knows the peer's address, but the actual data traffic is dropped because the ACL denies the outer encapsulation.
An MPLS network with EIGRP as the IGP is experiencing label distribution failures. Router R1 shows: 'show mpls ldp neighbor' does not list R2. R1's configuration: mpls ip on interfaces, but no router-id configured. R2's configuration: mpls ldp router-id Loopback0 force. R1 and R2 are directly connected. What is the root cause?
R1's LDP router-id is not configured, so it uses the IP of the interface facing R2, which may not be reachable from R2's loopback.
R1 has no explicit LDP router-id configured, so it defaults to the highest IP address on a loopback interface or, if none exists, the highest IP on a physical interface. Since R1 has no loopback, it uses the IP of the interface facing R2. R2's LDP router-id is forced to its Loopback0 address via the 'force' keyword. For LDP sessions to establish, each router must be able to reach the other's LDP router-id. R2's loopback may not be reachable from R1's interface IP, or R1's interface IP may not be reachable from R2's loopback, breaking the TCP transport required for LDP.
A DMVPN network with hub R1 and spokes R2 and R3 is configured with mGRE and NHRP. Spoke-to-spoke tunnels fail to form. R1 configuration: interface Tunnel0, ip address 10.0.0.1 255.255.255.0, tunnel source GigabitEthernet0/0, tunnel mode gre multipoint, ip nhrp network-id 1, ip nhrp map multicast dynamic. R2 shows: 'show dmvpn' shows no dynamic sessions. R3 shows: 'show ip nhrp' shows no entries for R2. What is the root cause?
The spokes are missing the 'ip nhrp nhs' command to point to the hub, preventing registration and resolution of spoke-to-spoke addresses.
In a DMVPN network, spokes must use the 'ip nhrp nhs' command to register their real (physical) IP addresses with the hub (NHS). Without this command, the hub never learns the spokes' addresses, so it cannot provide NHRP resolution replies to other spokes attempting to form spoke-to-spoke tunnels. The absence of dynamic sessions on R2 and no NHRP entries for R2 on R3 directly indicate that R2 never registered with the hub.
An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface connected to a customer network. The customer has a default route pointing to the router. After enabling uRPF, the router drops traffic from the customer that has a source IP address that is not in the routing table as a directly connected or static route. What is the most likely explanation?
Strict mode uRPF requires a specific route for the source IP; a default route is not sufficient.
Strict mode uRPF verifies that the source IP address of an incoming packet matches a specific route in the routing table, and that the interface used to reach that source IP is the same as the incoming interface. A default route (0.0.0.0/0) is a catch-all entry and does not provide a specific, directly connected or static route for the customer's source IP. Therefore, the router drops the traffic because it cannot find an exact match for the source IP in the routing table, which is a fundamental requirement of strict mode.
An engineer configures mutual redistribution between OSPF and EIGRP on a router. Both protocols have routes for the same prefix. The engineer also applies an inbound ACL on the OSPF interface to deny certain routes from being learned via OSPF. After the ACL is applied, the router still has the prefix in the routing table, but it is learned via EIGRP instead of OSPF. What is the most likely explanation?
The ACL blocks OSPF updates, so the router learns the prefix via EIGRP with a lower AD.
The inbound ACL on the OSPF interface blocks the OSPF-learned route from being installed in the routing table. Since mutual redistribution is configured, the same prefix is also learned via EIGRP. EIGRP has a default administrative distance (AD) of 90 for internal routes, which is lower than OSPF's AD of 110. Therefore, the router selects the EIGRP route as the best path, and the prefix remains in the routing table but now points to the EIGRP next hop.
A network engineer runs the following command on Router R1: R1# show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::1 Global unicast address(es): 2001:DB8:2::1, subnet is 2001:DB8:2::/64 Joined group address(es): FF02::1 FF02::2 ICMP redirects are enabled ICMP unreachables are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds IPv6 uRPF: loose mode (allow default route) Based on this output, what is the uRPF configuration on this interface?
uRPF is enabled in loose mode
The output explicitly shows 'IPv6 uRPF: loose mode (allow default route)', which confirms that unicast Reverse Path Forwarding (uRPF) is enabled in loose mode. In loose mode, the router checks that the source address of an incoming packet has a matching entry in the routing table, but it does not require the incoming interface to match the best return path. This is distinct from strict mode, which requires both a routing table entry and that the incoming interface is the same as the outgoing interface for the return route.
A network engineer is troubleshooting an IPv6 connectivity issue on a router that is receiving routes via EIGRP for IPv6. The engineer notices that some routes are not being installed in the routing table, even though the EIGRP neighbor relationship is established. The engineer checks the interface configuration and finds an inbound IPv6 ACL that permits only certain EIGRP packets. The ACL permits EIGRP hello packets and updates, but not EIGRP queries or replies. What is the most likely cause of the missing routes?
The ACL is blocking EIGRP query and reply packets, which are necessary for the EIGRP process to install routes.
EIGRP for IPv6 uses multicast address FF02::A for all EIGRP packets, including hello, update, query, and reply. The ACL permits only hello and update packets, blocking query and reply packets. EIGRP requires query and reply packets for the Diffusing Update Algorithm (DUAL) to converge and install routes; without them, the router cannot complete the route installation process, even though the neighbor relationship is established.
An engineer is troubleshooting a DMVPN phase 3 network where spoke-to-spoke tunnels are established, but traffic between spokes is taking a suboptimal path through the hub. The engineer checks 'show ip nhrp shortcut' on the spoke and sees no shortcut entries. The hub has 'ip nhrp redirect' enabled, and the spoke has 'ip nhrp shortcut' enabled. The engineer also verifies that the spoke's routing table has a route to the remote spoke's LAN via the hub. What is the most likely cause?
The hub router does not have a route to the remote spoke's LAN subnet.
In DMVPN phase 3, for spoke-to-spoke shortcuts to be installed, the spoke must receive an NHRP redirect from the hub. If the hub does not send a redirect, the spoke will not create a shortcut. The hub sends a redirect only if it has a route to the destination subnet. If the hub does not have a route to the remote spoke's LAN, it will not send a redirect.
Which IPv6 access-list entry will deny traffic from any source to the destination prefix 2001:db8:1::/48?
deny ipv6 any 2001:db8:1::/48
The IPv6 access-list entry 'deny ipv6 any 2001:db8:1::/48' uses the correct syntax: the source is 'any' (all traffic), and the destination is the prefix 2001:db8:1::/48, which matches all addresses within that /48 range. This entry denies traffic from any source to the entire destination prefix, as required by the question.
An engineer configures a DMVPN Phase 2 network. Spoke routers are configured with a route map that sets the next-hop to the tunnel interface for routes learned from the hub. This is intended to allow spoke-to-spoke direct communication. However, spoke-to-spoke traffic still goes through the hub. Which is the most likely explanation?
The route map is applied on the spoke router inbound from the hub, but it should be applied on the hub router outbound to the spokes.
In DMVPN Phase 2, spoke-to-spoke direct communication requires that the spoke routers have a route with the next-hop set to the tunnel interface of the remote spoke. However, if the route map is applied inbound on the spoke from the hub, it sets the next-hop to the hub's tunnel interface, not the remote spoke. The correct approach is to use a route map on the hub that sets the next-hop to the spoke's tunnel IP when advertising routes, or to use the 'next-hop-self' command incorrectly. The edge case is that the route map is applied on the spoke, not the hub.
A DMVPN phase 3 network with IPv6 over IPv4 tunnels is experiencing spoke-to-spoke tunnel failures. Hub router R1 has the following relevant configuration: interface Tunnel0 ipv6 address 2001:DB8:1::1/64 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ip nhrp network-id 1 ip nhrp map multicast dynamic ipv6 nhrp map multicast dynamic. Spoke router R2 shows: R2# show dmvpn detail Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete NHRP domain: 1 Interface: Tunnel0, IPv4 NHRP Details Type:Spoke, Total NBMA Peers: 1 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb 1 192.0.2.2 2001:DB8:1::2 UP 00:10:00 D. What is the root cause?
The hub is missing the ip nhrp redirect command under Tunnel0.
In DMVPN Phase 3, spoke-to-spoke tunnels rely on the hub to send NHRP Redirect messages to trigger shortcut creation. The hub's configuration is missing the `ip nhrp redirect` command under Tunnel0, which prevents it from informing the spoke that a better path exists directly to another spoke. Without this redirect, the spoke never initiates an NHRP Resolution Request to build a direct tunnel, causing spoke-to-spoke communication to fail.
In a VRF-Lite setup, Router R1 and R2 are running OSPF in VRF-A. R1 has interface Gig0/0 in VRF-A with ip ospf network point-to-point. R2 has interface Gig0/1 in VRF-A with default network type (broadcast). The link between them is a direct Ethernet connection. OSPF neighbors are not forming. What is the root cause?
The OSPF network types are mismatched: one side is point-to-point, the other is broadcast, causing neighbor adjacency failure.
OSPF network type mismatch prevents neighbor formation. On a broadcast network, OSPF expects DR/BDR elections, while point-to-point expects no election. The mismatch causes hello packets to be ignored because the OSPF interface parameters (like hello interval, dead interval, and network type) differ. Specifically, on a point-to-point link, the neighbor state machine expects a different packet format and does not process broadcast hellos.
A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# debug crypto ipsec *Mar 1 00:02:34.567: IPSEC(sa_request): , (key eng. msg.) src=10.0.0.1, dst=10.0.0.2, src_proxy=192.168.1.0/255.255.255.0/0/0, dst_proxy=192.168.2.0/255.255.255.0/0/0, *Mar 1 00:02:34.567: IPSEC(validate_proposal): transform proposal (esp-3des esp-sha-hmac) not supported for proxy 192.168.1.0/255.255.255.0/0/0 *Mar 1 00:02:34.567: IPSEC(validate_proposal): proposal doesn't match! *Mar 1 00:02:34.568: IPSEC(create_sa): SA created with (0x1234, 0x5678) but no inbound or outbound SPI What does this output indicate?
The transform set on the remote peer does not match the local transform set, causing IPsec SA negotiation to fail.
The debug output shows that the IPsec SA request is generated, but the transform proposal (esp-3des esp-sha-hmac) is rejected with 'not supported for proxy'. This indicates that the remote peer does not support or is configured with a different transform set, causing the proposal to fail validation. The SA is created with placeholder SPIs (0x1234, 0x5678) but no actual inbound/outbound SPI, confirming negotiation failure due to transform set mismatch.
A network engineer runs the following command to verify IPv6 uRPF operation: R1# show ipv6 interface GigabitEthernet0/0 | include verify IPv6 verify source: strict What does this output indicate?
Strict uRPF is enabled, so the router will drop packets if the source address is not in the routing table or if the best return path is not through the receiving interface.
The output 'IPv6 verify source: strict' indicates that strict unicast Reverse Path Forwarding (uRPF) is enabled on the interface. Strict uRPF verifies that the source IPv6 address of an incoming packet is reachable via the routing table AND that the best return path to that source uses the same interface on which the packet was received. If either condition fails, the packet is dropped. This matches option A exactly.
The 300-410 flashcard bank covers all 4 official blueprint domains published by Cisco. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Layer 3 Technologies
VPN Technologies
Infrastructure Security
Infrastructure Services
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that 300-410 questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.300-410 questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective 300-410 study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free 300-410 flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 1966+ original 300-410 flashcards across all 4 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are written by certified engineers against the official Cisco exam objectives.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official 300-410 exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included