Practice Test #3

Incorrect. Onboarding and initial orchestration of WAN edge devices into the fabric is primarily the role of vBond (orchestrator). vBond helps with initial authentication, NAT traversal, and directing edges to the appropriate controllers. vSmart becomes relevant after control connections are established, but it is not the component responsible for onboarding.

Incorrect. Telemetry collection/monitoring is mainly associated with vManage (management plane), which aggregates statistics, logs, and operational state for visualization and troubleshooting. While edges send operational data into the system, vSmart’s primary job is control-plane route/policy distribution, not acting as the telemetry collector.

Incorrect. Managing, maintaining, and gathering configuration and status for nodes is the responsibility of vManage. vManage provides centralized configuration templates, device inventory, software upgrades, and operational dashboards. vSmart does maintain control-plane state, but it is not the management-plane system of record for configuration and status.

Incorrect. Route targets do control route import and export in MPLS L3VPN environments where MP-BGP distributes VPN routes between PE devices. However, the question asks specifically about VRF-Lite, which does not rely on route targets for route exchange or VRF membership. In VRF-Lite, routes are typically exchanged with per-VRF static routing or standard routing protocols, so this statement is not true in that context.

Incorrect. Route targets are not transmitted as BGP standard communities; they are carried as BGP extended communities. In addition, VRF-Lite does not inherently depend on MP-BGP VPN route exchange, so this statement is doubly misleading for the scenario given. The wording is technically wrong even outside VRF-Lite because the community type is incorrect.

Incorrect. Route targets do not uniquely identify a customer routing table. In MPLS L3VPN, route distinguishers are used to make otherwise identical prefixes unique in VPNv4/vpnv6 advertisements, while route targets define import/export policy. Multiple VRFs can share the same route target, so an RT cannot serve as a unique identifier for a specific customer routing table.

MR (Map-Resolver) is used by ITRs to resolve EID-to-RLOC mappings. It receives Map-Requests (from ITRs) and helps return mapping information, often by querying the mapping system. The MR facilitates lookup, not publication. It does not originate or register a site’s EID prefixes into the mapping database.

ITR (Ingress Tunnel Router) encapsulates traffic from non-LISP or LISP sites toward the destination RLOC after learning the mapping. It triggers mapping lookups by sending Map-Requests (typically to an MR). The ITR consumes mappings to forward traffic; it does not publish/register EID-to-RLOC mappings for a site.

MS (Map-Server) is the control-plane component that receives Map-Register messages from ETRs, authenticates them, and stores the EID-to-RLOC mappings in its database. While it is central to making mappings available, it is not the device that publishes them on behalf of a site; the ETR is the one that originates the registrations.

Tap mode is out-of-band monitoring. The NGFW receives a copy of traffic from a network TAP device or SPAN session, analyzes it, and generates alerts/telemetry. Because it is not in the forwarding path, it cannot directly drop packets or reset sessions for the original flow. Tap is chosen for visibility, baselining, and low-risk deployments where blocking is not required.

Passive mode is another term commonly used for out-of-band monitoring/IDS-style deployment. The device inspects mirrored traffic and provides detection and reporting, but it does not sit inline and therefore cannot block flows crossing the network. Passive deployments are useful for evaluation, troubleshooting, and environments where introducing an inline device is not acceptable.

Inline tap is a hybrid term that can be confusing. It typically indicates the device is physically inline but configured to operate like a tap (monitor-only), forwarding traffic without enforcing policy drops. In many vendor contexts, it is used to reduce risk during initial rollout (visibility first), but it is not the mode associated with blocking flows.

Active is an LACP mode that actively sends LACPDU packets to negotiate an EtherChannel. Cisco WLC LAG does not use LACP negotiation, so configuring the switch for active will not establish the expected bundle with the controller. This option is a common distractor because many candidates equate LAG with LACP. In this scenario, active is incorrect because the WLC expects a static port-channel instead.

Passive is also an LACP mode, but it only responds to LACP packets rather than initiating them. Since the WLC does not negotiate EtherChannel with LACP, passive will not successfully form the required port-channel. Even in normal LACP operation, passive depends on the other side being active, which is not the case here. Therefore passive is not valid for connecting a WLC with LAG enabled.

Auto is a PAgP mode, which is Cisco proprietary and used for PAgP-based EtherChannel negotiation. Cisco WLC LAG does not use PAgP, so auto cannot establish the bundle. This option is incorrect both because it uses the wrong protocol and because the WLC requires a static EtherChannel. On exam questions, auto should be eliminated whenever the peer does not support PAgP.

Incorrect. The enable password can be decrypted if it is stored as type 7 (which is what service password-encryption produces). Type 7 is reversible and widely crackable. Only the enable secret is intended to be non-reversible (one-way hash), assuming a strong algorithm and password.

Incorrect. The enable password does not get a stronger encryption method than enable secret. With service password-encryption, enable password becomes type 7, which is weaker than enable secret hashing. The enable secret remains the stronger mechanism and is the recommended configuration for privileged access.

Incorrect. They are not encrypted identically. Enable password with service password-encryption uses type 7 reversible encoding, while enable secret uses a one-way hash (type 5/8/9). Additionally, when both are configured, IOS uses enable secret for authentication, underscoring their functional and security differences.

Incorrect. The URG bit is a TCP flag used to indicate urgent data and is unrelated to the IOS ACL “established” keyword. “Established” does not match on URG; it matches on ACK or RST. Even if a packet has URG set, it would still need ACK or RST set to match this ACL line.

Incorrect. SYN is used to initiate a TCP connection (first step of the three-way handshake). The “established” keyword is specifically intended to block new inbound connection attempts, so SYN-only packets (typical initial connection attempts) do not match and will be denied by the explicit “deny ip any any.”

Incorrect. DF (Don’t Fragment) is an IP header bit, not a TCP flag. The ACL line uses “permit tcp ... established,” which evaluates TCP flags (ACK/RST) only. This ACL does not include any match criteria for IP DF, so DF being set does not cause a permit.

Incorrect. Requiring a client certificate is characteristic of EAP-TLS, which uses mutual certificate-based authentication. EAP-FAST is designed to avoid mandatory client certificates by using a PAC to establish the protected tunnel and then performing inner authentication (often password-based) inside the tunnel. While certificates can be used in some designs, they are not required for EAP-FAST.

Incorrect. EAP-FAST originated as a Cisco method and is not an IETF standards-track EAP type in the same way as broadly standardized approaches. It is documented in RFCs (for example, RFC 4851) but not as a universally adopted IETF standard method like many candidates assume. On exams, treat EAP-FAST as Cisco-developed rather than an IETF standard.

Incorrect. “Transparent mode” is not a defining operational mode of EAP methods. Transparent mode is more commonly associated with certain network devices (for example, firewalls or bridging behaviors), not with EAP-FAST. EAP-FAST is an authentication method used within 802.1X/EAP exchanges between supplicant, authenticator (switch/AP), and authentication server (RADIUS).

Port flapping is a Layer 1/2 stability problem (bad cable/SFP, duplex mismatch, STP issues, interface errors) causing link up/down events and reconvergence. QoS does not stabilize a physical link or prevent interface resets; traffic will be disrupted regardless of priority. The correct fix is to troubleshoot the interface, cabling, transceiver, and switchport configuration.

Misrouted packets point to routing/control-plane issues (incorrect routes, redistribution mistakes, asymmetric routing, policy-based routing errors) or possibly L2 loops. QoS does not correct forwarding decisions; it only influences scheduling and drop behavior once packets are already on the correct path. Fix routing tables, adjacencies, and policies instead.

Duplicate IP addresses are an IP management and Layer 2/ARP problem that can cause intermittent connectivity, ARP instability, and traffic blackholing. QoS cannot resolve address conflicts because the issue is not congestion-based. The solution is proper IPAM, DHCP snooping/DAI where appropriate, and correcting host/static addressing.