350-401 · topic practice
Practise ENCOR 350-401 Vpn Technologies practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
Vpn Technologies questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag a concept onto its matching description — or click a concept then click the description.
Applied to data traffic for SLA-based path selection
Applied to enable NetFlow-like traffic monitoring
Applied to modify forwarding, NAT, or QoS on data packets
Applied to OMP routes and TLOCs for route manipulation
Applied to define which VPNs are provisioned on a device
Trap 1: The vEdge routers have not been rebooted after the policy change.
Incorrect because policy changes take effect immediately without reboot.
Trap 2: The OMP graceful restart timer has expired, causing the vEdge to…
Incorrect because OMP graceful restart affects route convergence, not policy application.
Trap 3: The BFD sessions between vEdge and vSmart are flapping.
Incorrect because BFD is for data plane failure detection, not for policy distribution.
The vEdge routers have not been rebooted after the policy change.
Why wrong: Incorrect because policy changes take effect immediately without reboot.
The control policy is not attached to the appropriate site list or VPN list.
Correct because a control policy must be associated with a list to be applied; otherwise, it is not enforced.
The OMP graceful restart timer has expired, causing the vEdge to ignore the policy.
Why wrong: Incorrect because OMP graceful restart affects route convergence, not policy application.
The BFD sessions between vEdge and vSmart are flapping.
Why wrong: Incorrect because BFD is for data plane failure detection, not for policy distribution.
Trap 1: Increase the MTU on the link between the PE routers.
MTU issues would cause packet drops, not route absence.
Trap 2: Reconfigure LDP on the PE routers to establish a targeted session.
LDP is not directly related to VRF route import.
Trap 3: Check the MPLS label stack on the local PE to ensure labels are…
Label issues would affect all destinations, not just one.
Increase the MTU on the link between the PE routers.
Why wrong: MTU issues would cause packet drops, not route absence.
Reconfigure LDP on the PE routers to establish a targeted session.
Why wrong: LDP is not directly related to VRF route import.
Check the MPLS label stack on the local PE to ensure labels are being swapped correctly.
Why wrong: Label issues would affect all destinations, not just one.
Verify that the route target import/export values on the remote PE match those on the local PE for VRF CUSTOMER_C.
Correct: Mismatched route targets cause routes to not be imported into the VRF.
Drag a concept onto its matching description — or click a concept then click the description.
Hub-and-spoke with NHRP registration
Spoke-to-spoke dynamic tunnel via NHRP resolution request/reply
NHRP with prefix-based spoke-to-spoke shortcut
Trap 1: Phase 4: NHRP with BGP for routing
Incorrect. There is no standard DMVPN Phase 4; DMVPN only has three phases.
Trap 2: Phase 5: NHRP with OSPF for routing
Incorrect. There is no standard DMVPN Phase 5; DMVPN only has three phases.
Phase 1: Hub-and-spoke with NHRP registration
Correct. Phase 1 uses NHRP for hub registration.
Phase 2: Spoke-to-spoke dynamic tunnel via NHRP resolution request/reply
Correct. Phase 2 uses NHRP for spoke-to-spoke dynamic tunnel via resolution request/reply.
Phase 3: NHRP with prefix-based spoke-to-spoke shortcut
Correct. Phase 3 uses NHRP with prefix-based spoke-to-spoke shortcut.
Phase 4: NHRP with BGP for routing
Why wrong: Incorrect. There is no standard DMVPN Phase 4; DMVPN only has three phases.
Phase 5: NHRP with OSPF for routing
Why wrong: Incorrect. There is no standard DMVPN Phase 5; DMVPN only has three phases.
Refer to the exhibit. ! NVE configuration interface nve1 no shut source-interface Loopback0 member vni 10100 mcast-group 239.1.1.100 ! ! VRF configuration vrf context TENANT-A rd 65000:1 address-family ipv4 unicast route-target both 65000:100 exit-address-family ! ! BGP EVPN configuration router bgp 65000 neighbor 10.1.1.1 remote-as 65000 neighbor 10.1.1.1 update-source Loopback0 address-family l2vpn evpn neighbor 10.1.1.1 activate neighbor 10.1.1.1 send-community extended ! ! VLAN configuration vlan 100 vn-segment 10100 ! ! Interface configuration interface Vlan100 no shutdown vrf member TENANT-A ip address 192.168.100.1/24
Trap 1: Remove the mcast-group from the NVE member, because EVPN uses BGP…
mcast-group is for data plane, but EVPN still needs the VNI enabled under evpn.
Trap 2: Change the source-interface to a physical interface.
Loopback is recommended for stability.
Trap 3: Add an IP address to the VLAN 100 interface in the default VRF.
The VLAN interface is correctly in VRF.
Configure "evpn" and "vni 10100 l2" under the BGP address-family l2vpn evpn.
The VNI must be activated under evpn for route advertisement.
Remove the mcast-group from the NVE member, because EVPN uses BGP for control plane.
Why wrong: mcast-group is for data plane, but EVPN still needs the VNI enabled under evpn.
Change the source-interface to a physical interface.
Why wrong: Loopback is recommended for stability.
Add an IP address to the VLAN 100 interface in the default VRF.
Why wrong: The VLAN interface is correctly in VRF.
Trap 1: The IKEv2 proposal is not configured correctly.
The proposal is configured with valid parameters.
Trap 2: The IPsec transform set is missing.
The transform set is for Phase 2, not Phase 1.
Trap 3: The pre-shared key is not defined in the keyring.
The keyring is configured, but not applied.
The IKEv2 proposal is not configured correctly.
Why wrong: The proposal is configured with valid parameters.
The IKEv2 profile is not attached to the crypto map or interface.
Correct because the profile must be applied to activate the configuration.
The IPsec transform set is missing.
Why wrong: The transform set is for Phase 2, not Phase 1.
The pre-shared key is not defined in the keyring.
Why wrong: The keyring is configured, but not applied.
Trap 1: The Dead Peer Detection (DPD) interval is too short.
DPD detects failures, but does not cause drops by itself.
Trap 2: The IPsec transform set is misconfigured.
Transform set issues would prevent tunnel establishment.
Trap 3: The Phase 2 lifetime is longer than Phase 1.
Phase 2 lifetime being longer does not cause drops.
The Dead Peer Detection (DPD) interval is too short.
Why wrong: DPD detects failures, but does not cause drops by itself.
The IKE Phase 1 lifetime is set too low.
Correct because a short lifetime causes frequent rekeys, which can lead to drops if not synchronized.
The IPsec transform set is misconfigured.
Why wrong: Transform set issues would prevent tunnel establishment.
The Phase 2 lifetime is longer than Phase 1.
Why wrong: Phase 2 lifetime being longer does not cause drops.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Trap 1: Configure IPsec transform set, then ISAKMP policy, then crypto ACL,…
This order is incorrect because the ISAKMP policy (IKE phase 1) must be configured before the transform set (IKE phase 2). The transform set is negotiated during phase 2 after phase 1 is complete.
Trap 2: Configure ISAKMP policy, then IPsec transform set, then create and…
This order is incorrect because the crypto ACL must be defined before creating the crypto map, as the crypto map references the ACL to identify traffic to be encrypted. Applying the crypto map without the ACL would result in no traffic being encrypted.
Trap 3: Configure crypto ACL, then ISAKMP policy, then IPsec transform set,…
This order is incorrect because the ISAKMP policy and transform set must be configured before the crypto ACL and crypto map are applied. The ACL can be defined earlier, but the overall sequence should start with IKE phase 1.
Configure ISAKMP policy, then IPsec transform set, then crypto ACL, then create and apply crypto map
This is the correct order because IKE phase 1 (ISAKMP policy) must be configured first to establish a secure channel, followed by phase 2 (transform set) to define encryption and hashing, then the ACL to specify interesting traffic, and finally the crypto map to bind everything together and apply it to the interface.
Configure IPsec transform set, then ISAKMP policy, then crypto ACL, then create and apply crypto map
Why wrong: This order is incorrect because the ISAKMP policy (IKE phase 1) must be configured before the transform set (IKE phase 2). The transform set is negotiated during phase 2 after phase 1 is complete.
Configure ISAKMP policy, then IPsec transform set, then create and apply crypto map, then crypto ACL
Why wrong: This order is incorrect because the crypto ACL must be defined before creating the crypto map, as the crypto map references the ACL to identify traffic to be encrypted. Applying the crypto map without the ACL would result in no traffic being encrypted.
Configure crypto ACL, then ISAKMP policy, then IPsec transform set, then create and apply crypto map
Why wrong: This order is incorrect because the ISAKMP policy and transform set must be configured before the crypto ACL and crypto map are applied. The ACL can be defined earlier, but the overall sequence should start with IKE phase 1.
Trap 1: The hub router must be configured with a static crypto map for each…
Incorrect because DMVPN uses dynamic crypto maps (or IPsec profiles) on the hub to accept connections from any spoke.
Trap 2: Data traffic between spokes is forwarded through the hub by default.
Incorrect because in phase 2, once the direct spoke-to-spoke tunnel is established, traffic bypasses the hub.
Spokes can dynamically establish direct tunnels with each other after learning the destination spoke's public address via NHRP.
Correct because in phase 2, NHRP allows spokes to resolve the public IP of other spokes and build direct mGRE tunnels.
The hub router must be configured with a static crypto map for each spoke.
Why wrong: Incorrect because DMVPN uses dynamic crypto maps (or IPsec profiles) on the hub to accept connections from any spoke.
Data traffic between spokes is forwarded through the hub by default.
Why wrong: Incorrect because in phase 2, once the direct spoke-to-spoke tunnel is established, traffic bypasses the hub.
Routing protocols such as EIGRP or OSPF can be run over the DMVPN tunnel interfaces.
Correct because DMVPN supports dynamic routing protocols over the mGRE tunnel interfaces for route exchange.
NHRP redirect and shortcut features are used to enable spoke-to-spoke communication.
Correct because NHRP redirect (on hub) and shortcut (on spoke) are key mechanisms in phase 2 to trigger direct tunnel setup.
Trap 1: Set a lower MED for routes advertised to ISP A and a higher MED for…
Incorrect. MED is used to influence inbound traffic, but it is a multi-exit discriminator that is only considered when the same AS receives routes from multiple points. In a dual-homed scenario with different ISPs, MED is not typically used because the ISPs are different ASes.
Trap 2: Advertise a more specific prefix (e.g., /25) to ISP A and a less…
Incorrect. Advertising different prefix lengths can cause suboptimal routing and may not be accepted by ISPs. It is not a standard practice for load balancing.
Trap 3: Configure the CE router to use BGP multipath with both ISPs.
Incorrect. BGP multipath allows load balancing of outbound traffic, but it does not influence inbound traffic. The scenario requires different behaviors for inbound and outbound.
Set a lower MED for routes advertised to ISP A and a higher MED for routes advertised to ISP B.
Why wrong: Incorrect. MED is used to influence inbound traffic, but it is a multi-exit discriminator that is only considered when the same AS receives routes from multiple points. In a dual-homed scenario with different ISPs, MED is not typically used because the ISPs are different ASes.
Use AS path prepending on routes advertised to ISP B and set a higher local preference for routes learned from ISP A.
Correct. AS path prepending makes the path to ISP B longer, discouraging inbound traffic from using it. Setting a higher local preference for routes from ISP A makes outbound traffic prefer ISP A.
Advertise a more specific prefix (e.g., /25) to ISP A and a less specific prefix (/24) to ISP B.
Why wrong: Incorrect. Advertising different prefix lengths can cause suboptimal routing and may not be accepted by ISPs. It is not a standard practice for load balancing.
Configure the CE router to use BGP multipath with both ISPs.
Why wrong: Incorrect. BGP multipath allows load balancing of outbound traffic, but it does not influence inbound traffic. The scenario requires different behaviors for inbound and outbound.
A network engineer runs the following command on Router R4:
R4# show interfaces tunnel 0
Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 10.0.0.4/30 MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set Tunnel source 192.168.1.4, destination 192.168.2.4 Tunnel protocol/transport GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out
Based on this output, what is true about this tunnel?
Trap 1: The tunnel is using IPsec encryption.
The encapsulation is GRE/IP, not IPsec.
Trap 2: The tunnel is using MPLS over GRE.
No MPLS is indicated; it is plain GRE.
Trap 3: The tunnel is down because there are no packets.
The tunnel is up/up; lack of traffic does not mean it is down.
The tunnel is using IPsec encryption.
Why wrong: The encapsulation is GRE/IP, not IPsec.
The tunnel is a GRE tunnel that is up and operational.
The interface is up/up and protocol is GRE/IP.
The tunnel is using MPLS over GRE.
Why wrong: No MPLS is indicated; it is plain GRE.
The tunnel is down because there are no packets.
Why wrong: The tunnel is up/up; lack of traffic does not mean it is down.
Drag a concept onto its matching description — or click a concept then click the description.
Carries IPv4 VPN routes with MPLS labels across the provider core
Carries IPv6 VPN routes with MPLS labels across the provider core
Carries global IPv4 unicast routes (non-VPN)
Carries global IPv6 unicast routes (non-VPN)
Carries Layer 2 VPN information such as pseudowires and VPLS
Trap 1: The hub is missing the 'tunnel protection ipsec' command on the…
Incorrect. If tunnel protection were missing, the tunnel would not come up at all. The tunnel is up, so protection is configured.
Trap 2: The spoke's crypto map is not using the correct pre-shared key.
Incorrect. If the pre-shared key were incorrect, Phase 1 would fail, and the tunnel would not come up.
Trap 3: The hub's IKEv2 profile is not configured with 'authentication…
Incorrect. The authentication method must match between peers. If it didn't match, the tunnel would not establish. The tunnel is up, so authentication is successful.
The spoke is configured with a static IP address on the tunnel interface that is not in the hub's IP pool.
Correct. In FlexVPN, the hub assigns IP addresses from a pool. If the spoke statically configures an IP address, the hub may not have a route back to that address, causing asymmetric routing or unreachability.
The hub is missing the 'tunnel protection ipsec' command on the tunnel interface.
Why wrong: Incorrect. If tunnel protection were missing, the tunnel would not come up at all. The tunnel is up, so protection is configured.
The spoke's crypto map is not using the correct pre-shared key.
Why wrong: Incorrect. If the pre-shared key were incorrect, Phase 1 would fail, and the tunnel would not come up.
The hub's IKEv2 profile is not configured with 'authentication remote rsa-sig'.
Why wrong: Incorrect. The authentication method must match between peers. If it didn't match, the tunnel would not establish. The tunnel is up, so authentication is successful.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Trap 1: The BGP session between PE and CE is not established.
Incorrect because the routes are in the VRF BGP table, indicating the session is up.
Trap 2: The route-target import is not configured on the PE.
Incorrect because the routes are already in the VRF BGP table, so import is working.
Trap 3: The VRF is not configured on the PE.
Incorrect because the VRF must be configured for the routes to be present.
The 'redistribute bgp' command is missing under the VRF BGP address-family on the PE.
Correct because without redistribution, the PE does not advertise VPN routes to the CE via eBGP.
The BGP session between PE and CE is not established.
Why wrong: Incorrect because the routes are in the VRF BGP table, indicating the session is up.
The route-target import is not configured on the PE.
Why wrong: Incorrect because the routes are already in the VRF BGP table, so import is working.
The VRF is not configured on the PE.
Why wrong: Incorrect because the VRF must be configured for the routes to be present.
Drag a concept onto its matching description — or click a concept then click the description.
Forwards MPLS packets by performing label lookup and swapping
Pushes labels on ingress and pops labels on egress
Core router that swaps labels without pushing or popping
Edge router that connects customer sites and runs MPLS VPNs
Customer edge router that connects to the PE
Trap 1: The router's 'aaa authorization commands 15 default group tacacs+'…
Incorrect because the engineer wants TACACS+ to authorize commands, and the issue is that TACACS+ is responding with a deny, not that the router is failing to fall back. Adding 'local' would not help if TACACS+ explicitly denies.
Trap 2: The router's privilege level 15 is not correctly assigned to the…
Incorrect because the user is already at privilege level 15 (as indicated by the 'commands 15' in the authorization command), and the issue is command authorization, not privilege level assignment.
Trap 3: The TACACS+ server is not reachable due to a firewall change,…
Incorrect because the scenario states that the TACACS+ server logs show authorization requests are being sent and responded to, indicating connectivity is fine.
The router's 'aaa authorization commands 15 default group tacacs+' command is missing the 'local' keyword, so if TACACS+ denies, there is no fallback.
Why wrong: Incorrect because the engineer wants TACACS+ to authorize commands, and the issue is that TACACS+ is responding with a deny, not that the router is failing to fall back. Adding 'local' would not help if TACACS+ explicitly denies.
The TACACS+ server upgrade changed the default authorization behavior from permissive to restrictive, requiring explicit 'permit' statements for each command, and the existing rules may not cover all commands.
Correct because TACACS+ authorization rules are defined on the server; an upgrade can change default behavior (e.g., from permit-all to deny-all), requiring updated rules to allow previously permitted commands.
The router's privilege level 15 is not correctly assigned to the user.
Why wrong: Incorrect because the user is already at privilege level 15 (as indicated by the 'commands 15' in the authorization command), and the issue is command authorization, not privilege level assignment.
The TACACS+ server is not reachable due to a firewall change, causing the router to deny all commands.
Why wrong: Incorrect because the scenario states that the TACACS+ server logs show authorization requests are being sent and responded to, indicating connectivity is fine.
Trap 1: P routers in the MPLS core must maintain a full routing table for…
Incorrect because P routers only need IGP routes to forward MPLS packets; they do not participate in VPN routing.
Trap 2: CE routers must run MPLS and participate in the label distribution…
Incorrect because CE routers are standard IP routers; they do not run MPLS and exchange only IP routes with the PE.
Trap 3: The MPLS label stack in a Layer 3 VPN always contains exactly one…
Incorrect because the label stack typically has two labels: an IGP label (for transport) and a VPN label (for the egress PE).
PE routers use MP-BGP to exchange VPNv4 routes that include the route distinguisher and the VPN label.
Correct because MP-BGP carries VPNv4 routes (with route distinguisher) and the VPN label in the NLRI, enabling MPLS Layer 3 VPN operation.
P routers in the MPLS core must maintain a full routing table for each customer VRF.
Why wrong: Incorrect because P routers only need IGP routes to forward MPLS packets; they do not participate in VPN routing.
CE routers must run MPLS and participate in the label distribution with the PE router.
Why wrong: Incorrect because CE routers are standard IP routers; they do not run MPLS and exchange only IP routes with the PE.
Each VRF on a PE router maintains a separate routing table and forwarding table per customer.
Correct because a VRF creates an isolated routing and forwarding instance for each customer on the PE.
The MPLS label stack in a Layer 3 VPN always contains exactly one label.
Why wrong: Incorrect because the label stack typically has two labels: an IGP label (for transport) and a VPN label (for the egress PE).
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Vpn Technologies sessions
Every question in these sessions is drawn from the Vpn Technologies domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Practise 350-401 questions linked to Architecture.
Practise 350-401 questions linked to Virtualization.
Practise 350-401 questions linked to Infrastructure.
Practise 350-401 questions linked to Network Assurance.
Practise 350-401 questions linked to Security.
Practise 350-401 questions linked to Automation.
Practise eBGP/iBGP peering, path attributes, route selection and BGP troubleshooting.
Practise OSPF area types, LSA types, neighbour states and multi-area design.
Practise EIGRP DUAL, metrics, stub routing and route redistribution.
Practise VLAN configuration, trunk negotiation and inter-VLAN routing.
Practise RSTP, MSTP, port roles and STP protection features.
Practise extended ACLs, CoPP rate-limiting and control-plane protection.
A free account saves results across sessions and highlights which topics need work.
Sign up free