Hard Difficulty Questions

YAML files in Python cannot contain comments, so all inventory data must be described without explanatory text.

Why wrong: Incorrect because YAML supports comments using the '#' character, and Python's PyYAML library can parse files that include comments (though comments are not preserved when dumping).

JSON is always more human-readable than YAML for complex inventory structures.

Why wrong: Incorrect because YAML is often considered more human-readable due to its use of indentation and less verbose syntax; JSON can be harder to read for deeply nested structures.

VLAN 10 is a community VLAN.

Why wrong: VLAN 10 cannot be a community VLAN because the output explicitly marks its Private VLAN Type as 'Primary' rather than 'Community.' In Cisco private VLAN terminology, a community VLAN is a secondary VLAN that allows hosts within the same community to communicate directly while still being isolated from other communities, and it is always associated with a primary VLAN. Since VLAN 10 is the primary itself, it is the parent VLAN that community and isolated secondary VLANs hang off of, not a community VLAN.

VLAN 10 is an isolated VLAN.

Why wrong: An isolated VLAN is also a secondary private VLAN type, but the output shows VLAN 10 as 'Primary,' which rules out this classification. Isolated VLANs permit only communication between their ports and a promiscuous port (typically a router or firewall), with no peer-to-peer traffic allowed between isolated ports. VLAN 10's role as a primary VLAN means it is the hub that connects the various secondary VLANs instead of being an isolated secondary. Therefore, this answer is incorrect.

VLAN 10 is a normal data VLAN with no private VLAN features.

Why wrong: The output clearly shows private VLAN configuration for VLAN 10, including a specific 'Private VLAN Type' and associated secondary VLAN fields, which would be absent on a normal data VLAN. A normal data VLAN operates as a simple broadcast domain with no promiscuous, community, or isolated port roles, whereas VLAN 10 is explicitly defined as a primary PVLAN with secondary mappings. Thus, stating it has no private VLAN features contradicts the very information shown in the exhibit.

Enable OSPF Fast Hello on all interfaces.

Why wrong: Fast Hello changes only the hello transmission interval, not the dead timer itself. In Cisco OSPF, the dead interval remains at its configured value (or defaults to multiple seconds), so a router still waits the full dead period before declaring a neighbor down. Therefore, while Fast Hello increases hello frequency, failure detection remains the bottleneck, and the outage is not significantly reduced—both hello and dead timers must be lowered together to achieve sub-second convergence.

Implement OSPF LSA throttling with a minimum interval of 0 ms.

Why wrong: OSPF LSA throttling controls the rate at which link-state advertisements are generated and flooded after a change is recognized, with a minimum interval of 0 ms merely eliminating the hold-down delay. However, this feature takes effect only after the router has already detected the topology change; it does nothing to accelerate the hello/dead timer process that identifies the failure. The 30-second outage is dominated by failure detection, so even instant LSA propagation leaves the detection wait untouched, and aggressive throttling can actually cause unnecessary CPU load.

Use OSPF incremental SPF (iSPF).

Why wrong: Incremental SPF (iSPF) is a post-detection optimization that reduces the CPU work during the Dijkstra calculation by recalculating only the affected branch of the shortest-path tree. It does not shorten the time needed to discover that a neighbor has failed; the router still must wait for the OSPF dead timer to expire before triggering any SPF computation. Since the dead timer is the bottleneck in a 30-second outage, iSPF offers no improvement to the detection phase and is therefore not a solution for this problem.

Increase the policer rate to 20 Mbps to accommodate voice bursts

Why wrong: Raising the policer to 20 Mbps on a 10 Mbps physical interface is ineffective because the interface cannot transmit faster than its line rate, so packets that burst beyond 10 Mbps will still be dropped by the interface or the policer downstream. Additionally, allowing voice to consume up to 20 Mbps of policed bandwidth would over-subscribe the link and cause severe drops for other classes during congestion, without giving voice any queuing priority or drop protection. This approach treats the symptom (bursts) but ignores the root cause, which is the need for a queuing mechanism rather than a rate-limit.

Remove the policer and rely on FIFO queuing

Why wrong: Removing the policer and using default FIFO queuing means all packets—data, voice, and video—share a single queue and are transmitted in arrival order. During link congestion, voice packets will be serialized behind large data packets, producing variable inter-packet delay (jitter) and potential buffer overflow that drops voice. FIFO offers no priority, no bandwidth reservation, and no drop-avoidance for voice, so voice quality will remain poor whenever the link is busy.

Apply the policy in the output direction only

Why wrong: Changing the policy to output direction changes where the policer is evaluated but does not change the fundamental problem: the policer still drops excess voice packets when the traffic rate exceeds the configured policed rate. The reason voice is degraded is the policer's drop behavior, not whether it is applied on ingress or egress; on a congested egress interface, packets are dropped from the output queue unless a scheduler provides priority. The correct fix is to replace the policer with a shaper that queues the excess, and to apply it to the voice class so that voice is prioritized ahead of other traffic.

SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.

Why wrong: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.

BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.

Why wrong: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.

Loop Guard is enabled on the uplink ports, which delays port transition.

Why wrong: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.

Why wrong: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.

The internal routers have a route to the default network with a better metric from another source.

Why wrong: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.

The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.

Why wrong: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.

The access list 1 is too permissive and includes the public IP address of the router.

Why wrong: While a permissive ACL may match more inside hosts than intended, including the router's own public IP in access list 1 does not directly exhaust the NAT translation table. PAT only translates traffic sourced from inside local addresses that enters the inside interface, so packets sourced from the outside/public IP would rarely traverse that path. Even if it did, this would be a constant misconfiguration causing consistent behavior, not sporadic translation failures tied to session volume.

The router is not configured with ip nat inside on the internal interface.

Why wrong: The 'ip nat inside' command marks the interface where inside local addresses are sourced before translation. If it were missing from the internal interface, no traffic arriving on that interface would be translated at all — every inside host would fail to reach the Internet, not just intermittently. With PAT, a missing 'ip nat inside' would also produce a persistent, total outage rather than a table-filling condition. Thus, this configuration error cannot explain sporadic connectivity.

The overload keyword is misspelled or not supported on this IOS version.

Why wrong: The 'overload' keyword is a standard, widely supported IOS parameter that enables PAT; if it were misspelled, the router would reject the command with a syntax error during configuration, not silently malfunction. An unsupported keyword on an older IOS version would similarly cause a configuration rejection, not allow the NAT rule to install and then behave unpredictably. Consequently, the session-dependent failures described are not consistent with a keyword that was never accepted by the router.

gNMI telemetry subscriptions can only use YANG paths from OpenConfig models.

Why wrong: Incorrect because gNMI can use any YANG model path—native, OpenConfig, or IETF—as long as the device supports it.

gNMI relies on NETCONF for session establishment and data encoding.

Why wrong: Incorrect because gNMI is independent of NETCONF; it uses gRPC (HTTP/2) for transport and Protocol Buffers for encoding, not NETCONF's XML-based encoding.

The supplicant is the device that provides authentication services, such as a RADIUS server.

Why wrong: Incorrect; the supplicant is the client requesting access, not the authentication server.

802.1X is only supported on wireless networks and cannot be used on wired switches.

Why wrong: Incorrect; 802.1X is widely used on both wired and wireless networks.

The trunk is using ISL encapsulation.

Why wrong: The encapsulation is shown as 802.1q.

VLAN 1 is pruned from the trunk.

Why wrong: VLAN 1 is in the forwarding state, so it is not pruned.

Only VLANs 10 and 20 are forwarding traffic.

Why wrong: VLAN 1 is also forwarding.

This is an RSPAN session with a remote VLAN.

Why wrong: The type is Local, not Remote.

Only egress traffic from Gi1/0/1 is mirrored.

Why wrong: Both directions are captured.

The destination port is configured to block all incoming traffic.

Why wrong: Ingress is enabled, so traffic is not blocked.

The trunk between the switch and the router is not allowing VLAN 100.

Why wrong: This option is incorrect because the switch is able to reach the captive portal server's IP address, which proves that Layer 2 connectivity for VLAN 100 exists across the trunk to the router. If the trunk were not allowing VLAN 100, the router would not receive frames from that VLAN and the switch would not be able to route to the server at all. The real failure is that the guest wireless client VLAN and the server VLAN are in different subnets but no inter-VLAN routing is configured inside the GUEST VRF, so packets from wireless clients are dropped at the switch even though the server is reachable from the switch itself.

The guest VRF is missing the route-target export command.

Why wrong: This option is incorrect because VRF-lite does not require route-target import/export commands; route-targets are used only in MPLS L3VPN environments when MP-BGP exchanges VPNv4 routes between PE routers. In a standalone VRF on a switch, the routing table is built from directly connected SVIs and any static or dynamic routes configured within that VRF, not from route-target-based VPN route exchange. The problem here is the absence of an SVI or route for the guest server's VLAN in the GUEST VRF, not a missing route-target, so this option does not explain the dropped traffic.

The captive portal server is configured with a default gateway that points to the corporate VRF.

Why wrong: Incorrect because if the server were in the corporate VRF, it would not be reachable from the switch in the GUEST VRF; the switch can reach it, so it must be in the same VRF.

YANG models are written in XML syntax.

Why wrong: Incorrect because YANG uses its own syntax, not XML.

YANG modules are compiled into MIB files for SNMP.

Why wrong: Incorrect because YANG is not compiled into MIBs; MIBs are for SNMP.

YANG defines the transport protocol for data exchange.

Why wrong: Incorrect because YANG is a data modeling language and does not specify transport; NETCONF or RESTCONF provide the transport.

The 'leaf' statement in YANG defines a list of key-value pairs.

Why wrong: Incorrect because 'leaf' defines a single scalar value; 'list' defines a collection of key-value pairs.

The fabric edge nodes have not been configured with the proper SGT mappings.

Why wrong: SGT mappings are IP-to-SGT bindings distributed by the Control Plane node via LISP to fabric edge nodes, primarily used for SXP propagation to legacy devices and for classifying traffic. However, SGT-based enforcement (SGACL) is applied only when traffic crosses Virtual Networks; same-subnet, intra-VN traffic is bridged at Layer 2 without any policy lookup. Therefore, missing SGT mappings on the fabric edge nodes are irrelevant here—they would not prevent enforcement for traffic that is not subject to enforcement in the first place.

The fabric edge nodes are operating in Layer 2 mode and do not support SGT enforcement.

Why wrong: The fabric edge node's forwarding mode (Layer 2 or Layer 3) determines how packets are switched or routed, but it does not affect SGT enforcement capability. In Layer 2 mode, the edge node performs bridging; in Layer 3 mode, it routes inter-VN traffic—but in both cases, the node is fully capable of enforcing SGACLs when traffic enters or leaves a VN. Since the endpoints are in the same subnet, the traffic never crosses a VN boundary, so the edge node's mode is irrelevant to the missing enforcement.

The control plane node has not been configured with the correct IP-SGT mappings.

Why wrong: Although the Control Plane node maintains the IP-to-SGT mappings that are critical for VN routing and policy classification, these mappings are only consulted when traffic is subject to SGT enforcement—namely, inter-VN traffic. Even with perfect IP-SGT mappings, traffic between endpoints in the same subnet and same VN will be bridged without a policy lookup. Thus, incorrect mappings on the Control Plane node cannot be the cause of the issue, as the traffic path does not invoke SGT enforcement.

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why wrong: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why wrong: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why wrong: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

The IP SLA operation must be configured with a 'request-data-size' value to match the remote router's MTU.

Why wrong: The request-data-size parameter for a UDP jitter operation only controls the payload size of the probe packets; it is optional and does not affect whether the remote router answers. The IP SLA responder on the destination processes jitter probes regardless of the configured data size, so this setting has no bearing on the failure. An MTU mismatch is a separate forwarding issue and is not relevant to the absence of a responder.

The source router needs a 'frequency' setting that matches the remote router's response interval.

Why wrong: The frequency command on the source router determines how often the IP SLA operation sends a new probe iteration; it is purely a local scheduling knob and has no corresponding value that must be matched on the remote router. The responder does not maintain its own 'response interval' that needs to align with that frequency, and jitter calculation is unaffected by this scheduling parameter. Changing frequency only changes the sample interval, not whether the remote responder generates a response.

The firewall on the remote router is blocking the UDP port 16384, preventing the probe from reaching the target.

Why wrong: A firewall blocking UDP 16384 could prevent a jitter probe from arriving, but that is a secondary issue and not the root cause described by the need for a responder. Even if the firewall permitted the probe, the remote router would still need an IP SLA responder to listen on that port and generate the return traffic; otherwise the packet is simply discarded. Moreover, the presence of a firewall does not explain why the operation can never establish with the responder, because the responder is mandatory regardless of firewall state.

The destination session on the central switch is configured with 'monitor session 2 destination remote vlan 999' instead of 'monitor session 2 destination interface Gi1/0/1'.

Why wrong: This option is incorrect because the destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.

The source sessions on the remote switches are configured with 'monitor session 1 source vlan 100' but the destination is not set to 'remote vlan 999'.

Why wrong: This option is wrong because a valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.

The RSPAN VLAN is not created as a remote SPAN VLAN; it must be configured with 'remote-span' command.

Why wrong: Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.

In DMVPN Phase 3, the hub router must always be in the data path for all traffic between spokes.

Why wrong: Incorrect. DMVPN Phase 3 allows spoke-to-spoke direct tunnels after the hub sends a redirect, so the hub does not remain in the data path for all traffic.

Spokes register their physical (non-NBMA) addresses with the NHRP server (hub) to enable dynamic tunnel establishment.

Why wrong: Incorrect. Spokes register their NBMA (physical) address, not a 'non-NBMA' address. The phrase 'non-NBMA' contradicts the definition of NBMA as the actual network address used for tunnel endpoints.

DMVPN Phase 3 uses point-to-point GRE tunnels for spoke-to-spoke connections.

Why wrong: Incorrect. DMVPN Phase 3 uses multipoint GRE (mGRE) for spoke-to-spoke connections, not point-to-point GRE.