Select Two (Multi-Select) Questions

Application-aware routing policies

Why it fails: Application-aware routing policies control path selection based on application performance, but they do not provide traffic segmentation. They are used to steer traffic based on SLA, not to isolate segments. While they can be applied per VPN, they are not the component that creates the segmentation itself. The question asks for components used to achieve segmentation, not policy enforcement.

IPsec tunnels between branches

Why it fails: IPsec tunnels provide secure transport between branches, but they do not inherently provide segmentation. All segments can share the same IPsec tunnels, with segmentation enforced via VPN segments and VRFs. IPsec ensures confidentiality and integrity, but without VPN segmentation, traffic from different segments would mix. Therefore, IPsec tunnels alone do not achieve the required isolation.

VLANs on the WAN Edge routers

Why it fails: VLANs on WAN Edge routers are used for local LAN segmentation, but they do not provide end-to-end segmentation across the SD-WAN fabric. VLANs are Layer 2 constructs and are not carried across the overlay. While they can map to VPN segments, they alone do not achieve the required isolation and policy enforcement across all branches. They are a local mechanism, not a fabric-wide segmentation solution.

A Type 2 hypervisor runs directly on the physical hardware without a host operating system.

Why it fails: A Type 2 hypervisor runs as an application on top of a host operating system, so it cannot run directly on hardware; that describes Type 1. It is tempting because bare-metal execution is the defining performance advantage of virtualisation, but attributing it to Type 2 inverts the architectural distinction.

VMware ESXi is an example of a Type 2 hypervisor.

Why it fails: ESXi installs directly on bare metal, so it is a Type 1 hypervisor; Type 2 runs atop a host OS such as Windows or Linux. The option is tempting because VMware also ships Type 2 products like Workstation and Fusion, which are the correct examples for that classification.

Type 1 hypervisors are typically used for desktop virtualization in enterprise environments.

Why it fails: Type 1 hypervisors run directly on hardware in data centres for server consolidation; desktop virtualisation on a workstation uses a Type 2 hypervisor hosted by an operating system. The statement is tempting because Type 1 offers strong performance and isolation, which enterprise deployments value, but that applies to servers, not desktops.

A route reflector client must be fully meshed with all other clients in the same cluster.

Why it fails: Reflector clients peer only with the reflector, which is the entire purpose of the design; requiring a full mesh among clients reinstates the scalability problem reflectors solve. It is tempting because iBGP speakers normally must be fully meshed, but that rule is precisely what route reflection relaxes.

The route reflector modifies the AS_PATH attribute to prevent loops.

Why it fails: Route reflectors propagate iBGP routes by relaxing the full-mesh requirement; loop prevention relies on ORIGINATOR_ID and CLUSTER_LIST attributes, not AS_PATH modification. It is tempting because AS_PATH is BGP's familiar loop-prevention mechanism, but that applies to eBGP, not reflector clusters.

IP SLA is only supported on ASR routers.

Why it fails: IP SLA is a software feature within Cisco IOS, IOS-XE, and IOS-XR platforms, not a hardware-specific capability of ASR routers. It is supported on a wide range of Cisco routers and switches, including ISRs, Catalyst, and even Nexus platforms, provided the release and feature license permit it. The assumption that only ASR routers support IP SLA likely comes from ASR being common at the enterprise edge, but that is a platform popularity bias, not a technical restriction.

IP SLA uses actual user traffic for measurements.

Why it fails: IP SLA generates its own synthetic or probe traffic with controlled parameters such as packet size, protocol, and frequency, rather than monitoring or using live user traffic. This approach ensures consistent, repeatable measurements that can be compared over time and across different paths without contaminating user data. Real user traffic analysis is a function of technologies like NetFlow or NBAR, not IP SLA.

IP SLA can only measure round-trip time, not one-way delay.

Why it fails: IP SLA can measure one-way delay, but only when the source and destination devices have synchronized clocks, typically via NTP or PTP. The base ICMP echo operation only reports round-trip time, but advanced operations like UDP jitter and UDP delay can return one-way values. Thus, claiming IP SLA can only measure RTT is overly restrictive and ignores its more sophisticated capabilities that require proper time synchronization.

VRF can be used to replace VLANs for Layer 2 isolation.

Why it fails: VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.

In VRF-lite, path isolation is achieved using MPLS labels.

Why it fails: VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.

VRF-lite requires MPLS enabled on all interfaces.

Why it fails: Incorrect because VRF-lite is specifically designed to work without MPLS.

VRF-lite can only use static routes for inter-VRF communication.

Why it fails: Incorrect because dynamic routing protocols like OSPF, EIGRP, and BGP can be used within VRFs.

A router can have at most two VRFs configured.

Why it fails: Incorrect because Cisco IOS supports many VRFs (the exact limit depends on platform and memory).

The 'command' module is idempotent by default because it always runs the given command.

Why it fails: The command module runs the given command every time, so it is not idempotent by default; it reports changed on each execution unless creates or removes is supplied. It is tempting because command execution appears deterministic, but Ansible cannot infer desired state from an arbitrary command string.

All Ansible modules are inherently idempotent regardless of how they are implemented.

Why it fails: Idempotency depends on how each module is written, not on Ansible itself; many modules such as command and shell re-run unconditionally. It is tempting because Ansible's design goal encourages idempotent modules, so people assume the property is automatic, but only modules deliberately coded to check current state achieve it.

Idempotency only applies to network modules, not to Linux system modules.

Why it fails: Idempotency is a property of individual module implementation, applying equally to Linux system modules like apt, yum and service, which are typically idempotent. It is tempting because network modules often need explicit state handling, suggesting the concept is network-specific, but the mechanism is module code, not platform.

The underlay can be configured as a Layer 2 network with VLANs to simplify deployment.

Why it fails: Cisco SD-Access underlay is typically a Layer 3 network. While it is possible to have Layer 2 segments for certain legacy devices, the fabric underlay itself requires IP routing to support VXLAN and LISP. A pure Layer 2 underlay would not provide the necessary scalability and loop prevention. The underlay is designed as a routed network, often using IS-IS, to ensure fast convergence and simplicity.

The underlay network carries endpoint subnet information and is used for endpoint-to-endpoint communication.

Why it fails: Endpoint subnet information is carried in the overlay network, specifically via LISP in the control plane. The underlay only provides transport between fabric nodes; it does not carry endpoint prefixes. Endpoint-to-endpoint communication occurs over VXLAN tunnels in the overlay. Confusing the roles of underlay and overlay is a common mistake; the underlay is purely the transport network.

The underlay uses VXLAN to encapsulate traffic between fabric nodes.

Why it fails: VXLAN is used in the overlay network to encapsulate endpoint traffic between fabric edge nodes. The underlay does not use VXLAN; it forwards native IP packets. VXLAN tunnels are established over the underlay, but the underlay itself is not VXLAN-encapsulated. This distinction is important: the underlay provides the IP transport that carries the VXLAN-encapsulated packets.

RESTCONF uses SSH for transport security.

Why it fails: RESTCONF secures transport with HTTPS over TLS, not SSH, which is NETCONF's transport. SSH is tempting because NETCONF runs over it by default, but RESTCONF's reliance on HTTP semantics means TLS is the mechanism providing confidentiality and integrity.

RESTCONF is designed to replace NETCONF entirely.

Why it fails: RESTCONF is a complementary HTTP-based interface, not a NETCONF replacement; both are maintained by the IETF and can coexist on the same device. The temptation arises because RESTCONF offers a lighter, web-friendly alternative, yet NETCONF remains for full datastore and notification capabilities.

RESTCONF uses remote procedure calls (RPCs) for all operations.

Why it fails: RESTCONF maps CRUD operations onto HTTP methods (GET, POST, PUT, PATCH, DELETE) rather than RPCs, which are NETCONF's mechanism. It is tempting because NETCONF does use RPCs, so candidates conflate the two protocols; RESTCONF's HTTP verbs are the actual axis of difference.

Enable DHCP relay on the bridge domain.

Why it fails: DHCP relay is used to forward DHCP requests from endpoints to a DHCP server. It is not related to enabling Layer 3 gateway services or unknown unicast flooding. While it may be configured in some designs, it does not satisfy the specific requirements of this scenario.

Enable IGMP snooping on the bridge domain.

Why it fails: IGMP snooping is used to optimize multicast traffic by limiting multicast floods to ports that have interested receivers. It does not provide Layer 3 gateway services or unknown unicast flooding. While it is a valid feature, it is not relevant to the stated requirements.

Enable ARP flooding on the bridge domain.

Why it fails: ARP flooding is used to handle ARP requests when the fabric does not have a proxy ARP entry. While it can be part of some designs, it is not a requirement for enabling Layer 3 gateway services or unknown unicast flooding. Enabling it unnecessarily can increase broadcast traffic and is not mandated by the scenario.

A bridge domain requires a VLAN pool to be defined in the fabric access policies.

Why it fails: A VLAN pool is used for VLAN allocation in fabric access policies, but it is not a direct requirement for a bridge domain itself. Bridge domains are logical constructs that can be mapped to VLANs via VLAN pools, but the bridge domain definition does not mandate a VLAN pool. The association is through the application EPG or external connections.

A bridge domain can only contain a single subnet.

Why it fails: This is false because a Cisco ACI bridge domain supports multiple subnets. Each subnet can have its own gateway IP. This multi-subnet capability allows for efficient use of bridge domains without creating separate Layer 2 domains for each subnet, simplifying configuration and reducing overhead.

A bridge domain provides Layer 3 routing between subnets by default.

Why it fails: A bridge domain does not provide Layer 3 routing by default. Routing between subnets within the same bridge domain or between different bridge domains requires the bridge domain to be associated with a VRF and the appropriate contracts to be in place. By default, bridge domains are Layer 2 constructs.

It converts VXLAN tunnels into MPLS LSPs to improve forwarding performance between leaf switches

Why it fails: EVPN does not convert VXLAN tunnels into MPLS LSPs. VXLAN encapsulation remains MAC-in-UDP, and EVPN is purely a control plane for advertising reachability. While EVPN can run over MPLS in service provider contexts, the scenario describes a VXLAN data center fabric, so claiming tunnel conversion is technically inaccurate and irrelevant to the design justification.

It eliminates the need for any underlay routing protocol because BGP carries all traffic between leaf switches

Why it fails: EVPN still requires a fully routed underlay to provide VTEP-to-VTEP IP reachability; BGP EVPN runs as an overlay on top of that underlay. Saying it eliminates the underlay protocol is incorrect because the loopback addresses of VTEPs must be reachable across the fabric. The underlay and overlay serve distinct roles and both remain necessary.

It removes the requirement for a loopback interface on each VTEP by using physical interface addresses

Why it fails: A stable loopback address is essential on each VTEP because it serves as the tunnel source and is advertised in EVPN Type-3 routes. Using physical interface addresses would break tunnel stability if a link failed. EVPN does not remove the loopback requirement; it depends on loopbacks being reachable and consistently advertised across the fabric underlay.

The HTTP operation measures the time to resolve the DNS name of the target web server.

Why it fails: Incorrect because HTTP probes measure the time to retrieve a web page (including TCP connect and HTTP GET), but DNS resolution time is not part of the HTTP probe; it can be measured separately with a DNS probe.

The ICMP echo operation requires the IP SLA responder to be enabled on the target device.

Why it fails: ICMP echo probes are generated by the source and answered by the target's IP stack, so no IP SLA responder is needed; only operations such as UDP jitter require a responder. The statement is tempting because responder-enabled operations do demand configuration on the target device.

Switch CPU utilization

Why it fails: Switch CPU utilization is a wired network metric that does not directly affect wireless client SNR or retry rates. While high switch CPU can impact overall network performance, it is not a primary cause of wireless signal quality issues. The engineer should focus on wireless-specific metrics like RF conditions and channel utilization.

DHCP pool utilization

Why it fails: DHCP pool utilization indicates how many IP addresses are in use but does not impact wireless signal quality or retry rates. While DHCP issues can affect connectivity, they do not cause high retry rates or low SNR. This metric is irrelevant to the RF-related symptoms described.

WAN latency and jitter

Why it fails: WAN latency and jitter affect application performance over the wide area but are not directly related to wireless client SNR or retry rates. These metrics are relevant for WAN troubleshooting, not local wireless RF issues. The client's poor performance is likely due to local RF conditions, not WAN characteristics.

Enable the exec-timeout 0 0 command on all VTY lines to prevent session lockouts during maintenance

Why it fails: Setting exec-timeout to 0 0 disables idle timeouts, leaving administrative sessions open indefinitely and increasing exposure if a terminal is left unattended. This weakens security rather than hardening it, and contradicts the goal of protecting management access on an internet-facing router. Idle timeouts should be short, not disabled.

Configure a local username with privilege level 15 and no password to ensure emergency access is always available

Why it fails: A privilege-15 account without a password is a severe security weakness that allows anyone reaching the login prompt to obtain full control. It directly undermines the goal of protecting the router from untrusted networks. Emergency access should be handled with securely stored credentials, AAA, and out-of-band management, not with passwordless privileged accounts.

Enable the ip http server command to allow web-based management as a backup access method

Why it fails: Enabling the plain HTTP server exposes an unencrypted management interface and broadens the attack surface, which is the opposite of hardening. Management should use HTTPS with strong authentication if web access is needed at all, and only from trusted networks. This action does not protect the router and should be avoided on an internet-facing device.

Eliminates the need for STP by using a centralized controller.

Why it fails: VXLAN doesn't require STP but does not use a controller.

Uses only multicast for control plane learning.

Why it fails: Can use BGP EVPN as well.

Provides native encryption for data in transit.

Why it fails: VXLAN does not encrypt; it can be combined with IPsec.

The underlay network must be a Layer 2 network to carry VXLAN traffic.

Why it fails: VXLAN is designed to run over a Layer 3 underlay network. The underlay provides IP connectivity between VTEPs, and VXLAN encapsulates Layer 2 frames in UDP/IP packets. A Layer 3 underlay is typical and recommended for scalability. A Layer 2 underlay is not required and would limit the benefits of VXLAN. Therefore, this statement is false.

EVPN requires that all VTEPs be in the same subnet.

Why it fails: EVPN VTEPs can be in different subnets because they communicate over the Layer 3 underlay using IP routing. The VTEP IP addresses (RLOCs) can be in different subnets, as long as they are reachable. VXLAN tunnels are established between VTEPs across the routed underlay. Therefore, this statement is false.

The underlay network must support multicast for BUM traffic replication.

Why it fails: In VXLAN with an EVPN control plane, multicast is not required in the underlay for BUM traffic replication. EVPN uses ingress replication, where the ingress VTEP replicates BUM traffic to all remote VTEPs based on the EVPN IMET route. This eliminates the need for multicast in the underlay. While multicast can be used, it is not mandatory with EVPN. Therefore, this statement is false.

The NVE interface must be assigned an IP address from the same subnet as the remote VTEP.

Why it fails: The NVE interface is a logical interface that does not take an IP address for tunnel endpoint addressing; instead, it references a source interface. The source interface address must be routable to remote VTEP addresses, but they do not need to be in the same subnet. Requiring the same subnet would unnecessarily limit the design and is not how VXLAN VTEPs are addressed.

VXLAN requires that the underlay provide Layer 2 adjacency between all VTEPs.

Why it fails: VXLAN is designed to work over a Layer 3 underlay, which is one of its main advantages over traditional Layer 2 extensions. VTEPs only need IP reachability to each other, not Layer 2 adjacency. Requiring Layer 2 adjacency would defeat the purpose of using VXLAN to stretch Layer 2 segments across a routed network and is not a valid requirement.

The underlay must run MPLS LDP to carry VXLAN traffic between VTEPs.

Why it fails: VXLAN is an overlay technology that runs over a standard IP underlay; it does not require MPLS LDP. The underlay simply needs IP reachability between VTEP source addresses. While MPLS can be used in some designs, it is not a requirement for VXLAN, and stating that LDP is mandatory is incorrect. The overlay encapsulates traffic in UDP/IP, independent of MPLS.

The fabric uses a single shared bridge domain across all edge nodes to avoid VLAN proliferation.

Why it fails: SD-Access can use a shared subnet for a virtual network, but it does not rely on a single shared Layer 2 bridge domain stretched across all edge nodes. Stretching one bridge domain would reintroduce flooding and scale problems. Instead, the overlay uses LISP and VXLAN so endpoints in the same virtual network appear local without a stretched Layer 2 domain.

The underlay uses VXLAN flooding to propagate endpoint reachability to all fabric edge nodes.

Why it fails: The SD-Access underlay is a routed Layer 3 fabric, typically using IS-IS, and does not use VXLAN flooding to propagate endpoint reachability. VXLAN is used in the overlay, and reachability is learned through the LISP control plane, not through flooding. Relying on flooding would not scale to thousands of endpoints as the scenario requires.

Fabric edge nodes use OSPF to advertise endpoint host routes into the underlay for reachability.

Why it fails: The SD-Access underlay carries only infrastructure reachability, such as loopbacks and fabric-enabled link networks, using IS-IS. Endpoint host routes are not advertised into the underlay with OSPF. Endpoint reachability is handled in the overlay by LISP, so this statement misrepresents how the fabric scales and how endpoints are resolved.

Each switch in the StackWise Virtual pair maintains an independent control plane and separate management IP address.

Why it fails: StackWise Virtual creates a single control plane and a single management IP address for the pair. One switch becomes active and the other standby, with the standby ready to take over if the active fails. Maintaining independent control planes and management addresses describes a traditional two-switch design, not StackWise Virtual.

It requires that both switches run different IOS XE versions to provide software redundancy.

Why it fails: Both switches in a StackWise Virtual pair must run the same IOS XE software version to form the logical entity. Running different versions is not supported and would prevent the SVL from coming up. Software redundancy is achieved through the active/standby control plane model, not by mismatched software versions.

The StackWise Virtual Link can be formed using any two 1 Gigabit Ethernet ports on the switches.

Why it fails: The SVL requires high-bandwidth links, typically 10G, 25G, 40G, or 100G ports, and often uses multiple physical links in a port-channel for redundancy. Using 1 Gigabit Ethernet ports would not provide sufficient bandwidth for the inter-switch traffic and is not a supported configuration for StackWise Virtual on Catalyst 9000 platforms.