What the Cisco CCNP ENARSI (300-410) exam covers
- Layer 3 Technologies192 questions
- VPN Technologies110 questions
- Infrastructure Security138 questions
- Infrastructure Services183 questions
Free Cisco CCNP ENARSI (300-410) sample questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 623.
-
Which routing protocol is a Cisco-developed advanced distance-vector protocol using DUAL?
- AOSPF (link-state)
- BEIGRPCorrect
- CRIPng
- DBGP (path-vector)
✓ Correct answer: BEIGRP (Enhanced Interior Gateway Routing Protocol) is a Cisco-proprietary advanced distance-vector protocol that uses the Diffusing Update Algorithm (DUAL) to guarantee loop-free paths and fast convergence. DUAL allows EIGRP to maintain feasible successors as pre-computed backup routes, eliminating the need to flood the network with queries in most failure scenarios.
Why the other options are wrong- AOSPF (link-state) is a link-state protocol using Dijkstra's SPF algorithm, not DUAL, and it is an open standard rather than a Cisco-proprietary protocol.
- CRIPng is a distance-vector protocol for IPv6 that uses simple hop-count as its metric and does not implement DUAL for loop-free path computation.
- DBGP (path-vector) is an exterior path-vector protocol used between autonomous systems and does not employ DUAL or classify as a distance-vector IGP.
-
Which TWO actions reduce the size of the BGP table accepted from an ISP to control memory and CPU cost? (Choose TWO)
- AApply an inbound prefix list to accept only needed prefixesCorrect
- BDisable BGP synchronization
- CIncrease the BGP hold timer to 600 seconds
- DRequest a default route only instead of full tablesCorrect
✓ Correct answer: A, DWhen a router peers with an ISP, receiving the full BGP table (800,000+ prefixes) consumes significant RAM and CPU for route processing. Applying an inbound prefix-list filters accepted prefixes to only those needed, while negotiating a default route only (with no full-table) reduces the accepted table to a single entry - both approaches directly cut memory use and RIB/FIB processing load.
Why the other options are wrong- BDisabling BGP synchronization (a legacy feature already off by default in modern IOS) allows iBGP routes to be used without IGP sync - it does not reduce the number of prefixes accepted from an ISP.
- CIncreasing the BGP hold timer to 600 seconds slows failure detection, making BGP sessions more tolerant of packet loss - it has no effect on the number of prefixes stored in the BGP table.
-
A network architect wants deterministic, easily troubleshot inbound path selection from an upstream provider without relying on the provider's policy. Which approach is the most reliable design choice?
- ALower your own local administrative distance for the eBGP routes
- BUse AS-path prepending and more-specific advertisements; inbound control stays limitedCorrect
- CSet Local Preference on your own routers to control inbound traffic
- DIncrease your Weight values on your routers to force inbound paths
✓ Correct answer: BInbound traffic control is fundamentally limited because it depends on the upstream provider's routing decisions. The most reliable tools available to the customer are AS-path prepending (making one path appear longer to make it less preferred) and advertising more-specific prefixes over the preferred link while advertising the aggregate on both. These are BGP attributes that upstream routers will honor, though the customer must accept that inbound control is inherently less deterministic than outbound control via Local Preference or Weight.
Why the other options are wrong- ALowering your own administrative distance for eBGP affects your routers' outbound choice, not how upstream providers select the inbound path to you.
- CLocal Preference is an iBGP attribute never advertised to eBGP peers; it controls outbound path selection within your AS, not inbound traffic.
- DWeight is Cisco-proprietary and local to a single router; it is never sent to peers and cannot influence inbound paths from the provider.
-
Which command applies a Flexible NetFlow flow monitor to capture ingress traffic on an interface?
- Aflow record <name>
- Bip flow-export destination <ip> <port>
- Cflow exporter <name>
- Dip flow monitor <name> inputCorrect
✓ Correct answer: DTo activate Flexible NetFlow on an interface, you apply a flow monitor in interface configuration mode using 'ip flow monitor <monitor-name> input' for ingress traffic or 'output' for egress traffic. The flow monitor ties together the flow record (defining which fields to track) and the flow exporter (defining where to send the data). Without this interface-level application command, the flow monitor is defined but no traffic is actually captured.
Why the other options are wrong- Aflow record <name> is the global configuration command that defines the key and non-key fields for a flow - it does not apply monitoring to an interface.
- Bip flow-export destination <ip> <port> is the legacy NetFlow v5/v9 command for configuring export destination - it is not used in Flexible NetFlow, which uses flow exporter objects instead.
- Cflow exporter <name> is the global configuration command that defines the collector destination for Flexible NetFlow data - it must be referenced by a flow monitor but does not itself activate capture on an interface.
-
In a DMVPN deployment, spokes register with the hub and hub-to-spoke works, but spoke-to-spoke tunnels never form in Phase 2. Which is the most likely cause?
- ANTP is unsynchronized, so the spokes reject the hub's timestamps and abandon NHRP resolution attempts
- BNHRP is not resolving the spoke mappings, often due to next-hop being changed by the routing protocol on the hubCorrect
- CThe hub advertises too much bandwidth on the tunnel, so spokes suppress direct spoke-to-spoke shortcuts
- DIPsec transform sets are mismatched, so the protected NHRP resolution replies between spokes are dropped
✓ Correct answer: BIn DMVPN Phase 2, spokes must be able to exchange NHRP resolution requests and receive the real NBMA addresses of other spokes so they can build direct spoke-to-spoke tunnels. A common failure occurs when the hub's routing protocol (e.g., EIGRP or OSPF) rewrites the next-hop to itself instead of preserving the spoke's next-hop, preventing the spoke from learning the correct NBMA address. The fix is to apply 'no ip next-hop-self eigrp' (or equivalent) on the hub so that spoke prefixes are advertised with the original spoke next-hop intact.
Why the other options are wrong- ANTP being unsynchronized affects IKE certificate validity or log correlation, but it does not prevent NHRP resolution or spoke-to-spoke tunnel formation in Phase 2.
- CInterface bandwidth is not a factor in NHRP registration or spoke-to-spoke tunnel building; a hub with high bandwidth does not suppress Phase 2 shortcuts.
- DMismatched IPsec transform sets would stop IKE Phase 2 SAs from forming at all, not selectively block NHRP resolution between spokes; the stem shows hub-to-spoke works, so IPsec is fine.
-
Select TWO BGP attributes that are WELL-KNOWN MANDATORY and must be present in every BGP UPDATE message.
- AAS-PathCorrect
- BMED (Multi-Exit Discriminator)
- CNext-HopCorrect
- DLocal Preference
✓ Correct answer: A, CBGP attributes are categorized as well-known mandatory, well-known discretionary, optional transitive, or optional non-transitive. Well-known mandatory attributes must appear in every BGP UPDATE message. AS-Path (prevents routing loops by listing ASes a route has traversed) and Next-Hop (the IP address to use to reach the advertised prefix) are both well-known mandatory. Their absence would make an UPDATE invalid.
Why the other options are wrong- BMED (Multi-Exit Discriminator) is an optional non-transitive attribute; it is not required in every UPDATE and is only passed to directly connected eBGP peers, not propagated further.
- DLocal Preference is a well-known discretionary attribute shared among iBGP peers within an AS but is not mandatory and is not sent to eBGP peers.
-
Which statement correctly describes the 'ip prefix-list' behavior when the 'le' keyword is used without a 'ge' keyword, such as 'ip prefix-list FILTER permit 10.0.0.0/8 le 24'?
- AIt matches only the exact prefix 10.0.0.0/8 with a /24 mask.
- BIt matches any prefix within 10.0.0.0/8 with a prefix length from /8 up to and including /24.Correct
- CIt matches any prefix anywhere in the routing table with a mask of exactly /24.
- DIt matches prefixes within 10.0.0.0/8 with mask lengths strictly greater than /24.
✓ Correct answer: BIn an IP prefix list, 'permit 10.0.0.0/8 le 24' matches any subnet that falls within the 10.0.0.0/8 address space AND has a prefix length between /8 (the base length) and /24 inclusive. The 'le' keyword sets the upper bound on the mask length. Without 'ge', the lower bound defaults to the base prefix length. This is useful for permitting aggregates and their more-specific subnets up to a certain granularity.
Why the other options are wrong- AThe 'le' keyword does not create an exact match on /24; it defines an upper bound for the mask length range. An exact match would use 'permit 10.0.0.0/24' with no length keywords.
- CPrefix list entries are always evaluated within the network address specified (10.0.0.0/8 here); the entry does not match arbitrary /24 subnets outside the 10.0.0.0/8 block.
- DThe 'le' (less-than-or-equal) keyword sets the maximum, not minimum, prefix length. Prefixes greater than /24 would be matched by a 'ge 25' or 'le 32' specification, not by 'le 24'.
-
A static route is configured as 'ip route 10.5.0.0 255.255.0.0 Null0'. In a BGP context, what is the most common purpose of this route?
- ATo provide a valid IGP entry so a network statement can originate the aggregate into BGPCorrect
- BTo permanently blackhole all production traffic destined to the 10.5.0.0/16 supernet
- CTo create a recursive next-hop entry that iBGP peers use to reach the aggregate prefix
- DTo force OSPF to automatically summarize the 10.5.0.0/16 prefix at the area boundary
✓ Correct answer: ABGP only originates a prefix via the network command if an exact-match route exists in the routing table. A discard route to Null0 satisfies that requirement and also harmlessly drops traffic to addresses within the aggregate that are not covered by more-specific routes, preventing loops.
Why the other options are wrong- BIt does not blackhole production traffic, because more-specific routes are matched first; only uncovered addresses are dropped.
- CIt does not create a recursive next hop for iBGP peers; next-hop resolution is unrelated to this discard route.
- DOSPF summarization is configured with area range or summary-address, not with a Null0 static route.
-
Which statement best describes the role of the next-hop-self setting when running BGP as the overlay routing protocol on a DMVPN hub in Phase 2?
- AIt should be disabled so spokes learn each other's tunnel addresses as next hops, enabling direct spoke-to-spoke tunnelsCorrect
- BIt must always be enabled so that all spoke-to-spoke traffic permanently transits the hub instead of going direct
- CIt encrypts the BGP update messages exchanged over the tunnel so that route data stays confidential
- DIt converts BGP into a link-state protocol on the overlay to speed up spoke-to-spoke convergence
✓ Correct answer: AWith next-hop-self disabled (using no next-hop-self for the spoke peers), the originating spoke's tunnel IP is preserved as the BGP next hop. NHRP can then resolve that next hop to its NBMA address and a direct spoke-to-spoke tunnel forms instead of hairpinning through the hub.
Why the other options are wrong- BForcing next-hop-self defeats Phase 2 spoke-to-spoke optimization by always pointing to the hub.
- Cnext-hop-self is a BGP attribute behavior, not an encryption mechanism.
- DIt does not change BGP's path-vector nature into link-state operation.
-
Which IP SLA configuration element makes a tracked object change state based on the success or failure of an SLA operation?
- Aip sla schedule
- Btrack <number> ip sla <op> reachabilityCorrect
- Cip sla responder
- Dthreshold
✓ Correct answer: BThe 'track <number> ip sla <operation> reachability' command creates a tracked object that is up when the SLA probe succeeds and down when it fails. A floating static route or HSRP can then track that object to trigger failover.
Why the other options are wrong- Aip sla schedule starts the operation but does not create a tracked object.
- Cip sla responder enables the far-end device to answer jitter/UDP probes; it does not track state.
- Dthreshold sets a rising/falling value for reactions but is not the object that links to a static route.
Related Cisco resources
- Cisco CCNP ENARSI (300-410) study guideKey concepts
- Cisco practice examsAll Cisco
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- Cisco CCNP Security SCOR (350-701) practice examRelated
- Cisco CCST Cybersecurity (100-160) practice examRelated
- Cisco Cybersecurity Associate (200-201 CBROPS) practice examRelated
Cisco CCNP ENARSI (300-410) practice exam FAQ
How many questions are in the Cisco CCNP ENARSI (300-410) practice exam on CertGrid?
CertGrid has 623 practice questions for Cisco CCNP ENARSI (300-410), covering 4 exam domains. The real Cisco CCNP ENARSI (300-410) exam runs 90 min, with a published question count that varies. CertGrid's timed mock is a fixed 60 questions.
What is the passing score for Cisco CCNP ENARSI (300-410)?
The Cisco CCNP ENARSI (300-410) exam passing score is 82.5%, and you have about 90 min to complete it. CertGrid scores your practice attempts the same way so you know when you are ready.
Are these official Cisco CCNP ENARSI (300-410) exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the Cisco CCNP ENARSI (300-410) exam.
Can I practice Cisco CCNP ENARSI (300-410) for free?
Yes. You can start practicing Cisco CCNP ENARSI (300-410) for free with daily practice and sample questions. Paid plans unlock full timed exams, complete explanations, and domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Cisco. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.