STP practice questions

Change the port type of Gi0/3 to trunk to allow multiple VLANs.

Why wrong: Configuring Gi0/3 as a trunk only affects VLAN tagging and the set of VLANs carried, not the STP port role. The blocking state indicates an STP decision—likely that the current root bridge has a higher bridge priority than another switch for VLAN 10—so the port cannot forward even after trunk mode is set. Trunking would be relevant if VLANs were being pruned, but it cannot change the root bridge election or port cost calculations.

Configure spanning-tree portfast on Gi0/3 to speed up convergence.

Why wrong: Portfast is intended solely for access ports connected to end stations, allowing them to bypass the listening and learning states to converge quickly. Applying it to an inter-switch uplink like Gi0/3 is dangerous because it could create a temporary bridging loop during STP recalculation. Even if Portfast were enabled, the port would still block after the switch receives the superior BPDU that elected another switch as root; it only skips the forward-delay timers, not the STP decision itself.

Enable BPDU guard on Gi0/3 to prevent unauthorized switches from affecting the network.

Why wrong: BPDU guard is an STP protection feature typically enabled on PortFast-configured access ports; when it receives a BPDU, it disables the port to prevent rogue switches. On an uplink connecting two switches, BPDUs are expected and necessary for STP operation, so enabling BPDU guard would shut down Gi0/3 and disrupt the link entirely. It does nothing to influence root bridge selection or why Gi0/3 is in a blocking state, since that state is determined by root bridge priorities and path costs.

Increase the bridge priority on SW2 for VLAN 40.

Why wrong: Increasing the bridge priority on SW2 for VLAN 40 would assign a higher numeric priority value, making it less likely to become the root bridge for that VLAN. However, the root bridge election only determines the spanning-tree topology; it does not alter the fixed forward-delay timers of PVST+ that cause the 30-second reconvergence. Even if SW2 were the root, PVST+ still requires listening and learning delays, whereas Rapid PVST+ eliminates that delay via Proposal/Agreement. The correct fix is to switch the entire stack to Rapid PVST+, not to manipulate root priority.

Disable PortFast on all access ports.

Why wrong: Disabling PortFast on all access ports would force every host-facing port to spend 30 seconds in listening and learning states after any link event, making client connectivity worse. PortFast is designed only for edge ports and has no effect on the convergence of an inter-switch trunk when an uplink flaps. The 30-second outage on VLAN 40 stems from the root port transition on SW2's trunk, not from access port behavior, so this change would be counterproductive.

Convert the uplink to a routed port.

Why wrong: Converting the uplink to a routed port would eliminate Layer 2 spanning tree on that segment, but it would also terminate the VLAN 40 broadcast domain and require IP addressing on the links. This fundamentally changes the network design and does not address the STP reconvergence delay that occurs when the Layer 2 uplink flaps. The exhibit clearly indicates an STP mode mismatch, not a need for Layer 3 switching, so this is not a valid corrective action.

The root bridge election failed, causing a loop.

Why wrong: The root bridge did not fail; SwitchC is the correctly elected root for VLAN 10 based on the lowest bridge priority and MAC address. A failed root election would cause all switches to claim root status and generate BPDU storms, not a single port being placed into err-disabled state. The actual cause is BPDU Guard, which administratively disables the port upon receiving an unexpected BPDU.

Rapid PVST+ is not compatible with PortFast.

Why wrong: Rapid PVST+ fully supports PortFast as a per-port enhancement. PortFast bypasses the listening and learning states but does not disable spanning-tree operation; it is designed for access ports that connect end hosts. Therefore, claiming that Rapid PVST+ and PortFast are incompatible is incorrect; they are commonly used together in enterprise campus networks.

The port is configured as a trunk but should be an access port.

Why wrong: The interface is configured as an access port using 'switchport mode access', so the premise of this option is false. BPDU Guard is independent of trunk or access mode; it is tied to PortFast, and it will shut down the port regardless of the port mode if a BPDU is received. Therefore, the problem is not a misconfigured trunk but the intentional BPDU Guard protection triggered by an unexpected BPDU.

STP manages VLANs, VTP prevents loops, EtherChannel restricts MAC addresses, Port Security aggregates links, DTP provides fast per-VLAN convergence, and Rapid PVST+ negotiates trunks.

Why wrong: This option assigns each feature another feature's job: STP is given VLAN management (VTP's role), VTP is given loop prevention (STP's role), EtherChannel is given MAC address restriction (Port Security's role), Port Security is given link aggregation (EtherChannel's role), DTP is given fast per-VLAN convergence (Rapid PVST+), and Rapid PVST+ is given trunk negotiation (DTP). Since none of the features are matched with their actual purpose, the mapping is completely invalid.

STP aggregates links, VTP prevents loops, EtherChannel manages VLANs, Port Security negotiates trunks, DTP restricts MAC addresses, and Rapid PVST+ provides fast per-VLAN convergence.

Why wrong: This option mixes up five of the six features: STP is incorrectly said to aggregate links (EtherChannel's role), VTP is incorrectly said to prevent loops (STP's role), EtherChannel is incorrectly said to manage VLANs (VTP's role), Port Security is incorrectly said to negotiate trunks (DTP's role), and DTP is incorrectly said to restrict MAC addresses (Port Security's role). Only Rapid PVST+ is correctly matched with providing fast per-VLAN convergence, but the five wrong pairings make the overall option incorrect.

STP provides fast per-VLAN convergence, VTP aggregates links, EtherChannel prevents loops, Port Security manages VLANs, DTP restricts MAC addresses, and Rapid PVST+ negotiates trunks.

Why wrong: Every pairing in this option is mismatched: STP does not provide fast convergence, that is the role of Rapid PVST+; VTP does not aggregate links, EtherChannel does; EtherChannel does not prevent loops, STP does; Port Security does not manage VLANs, VTP does; DTP does not restrict MAC addresses, Port Security does; and Rapid PVST+ does not negotiate trunks, DTP does. Because all six features are assigned to the wrong function, the entire answer is incorrect.

The native VLAN must be set to 30

Why wrong: The native VLAN is used exclusively for untagged frames on an 802.1Q trunk and defaults to VLAN 1; user data VLAN traffic is normally tagged, so setting the native VLAN to 30 would not affect traffic delivery for VLAN 30. Since the problem is that VLAN 30 frames are not permitted or are pruned on the trunk, adjusting the native VLAN would neither allow those frames onto the trunk nor resolve the allowed-list mismatch.

STP blocks all VLANs on the trunk when one VLAN fails

Why wrong: Spanning Tree Protocol operates on a per-VLAN basis (PVST/PVST+) or per-instance in MST, so STP independently evaluates blocking or forwarding state for each VLAN on the trunk. A failure such as VLAN 30 not being allowed on one side is an administrative filtering issue, not a Layer 2 loop condition, and STP would not respond by blocking all VLANs on the trunk merely because one VLAN's frames are not being transmitted.

The trunk must be changed to access mode for VLAN 30

Why wrong: Configuring the trunk as an access port would force the link to carry traffic for only a single, untagged VLAN, eliminating the multi-VLAN 802.1Q trunk entirely. This would break connectivity not only for VLAN 30 but also for VLAN 10 and any other VLANs currently traversing the link, so it is not a valid fix for the reported issue and would degrade the network further.

Root Guard and UDLD

Why wrong: Root Guard is a spanning-tree feature that prevents a designated port from becoming a root port by placing the port in root-inconsistent state if it receives a superior BPDU, and it is used on ports that should never become the root bridge, not on edge ports. UDLD (Unidirectional Link Detection) detects and disables unidirectional fiber or copper links, but it does not affect the port's forwarding state during STP convergence. Neither feature speeds up initial forwarding for an end host nor protects against rogue BPDUs, so it does not meet the access-port requirement.

Loop Guard and native VLAN

Why wrong: Loop Guard prevents alternate or root ports from becoming designated when BPDUs stop being received on a redundant link, which protects against loops caused by unidirectional link failures, but it is not intended for edge ports and does not accelerate forwarding. The native VLAN is a VLAN assignment for frames on a trunk link that lack an 802.1Q tag, so it is irrelevant to an access port connected to a single end host. This combination neither enables fast transition nor provides BPDU filtering, making it an incorrect choice for an edge-port configuration.

Port security and EtherChannel

Why wrong: Port security restricts the number of MAC addresses allowed on a port and can take action if a violation occurs, but it does not bypass the STP listening and learning states or alter how the port receives BPDUs. EtherChannel is a link aggregation technology that bundles multiple physical links into one logical link, which has nothing to do with STP edge-port behavior or protecting the spanning-tree domain. These features address different concerns, so they are not the correct set for a layer 2 switch port connected to an end host.

Configure spanning-tree vlan 10,20 root primary and spanning-tree portfast on Gi0/1; then use 'errdisable recovery cause bpduguard' to automatically recover the port.

Why wrong: The 'root primary' command sets priority to 24576, which may not be low enough if another switch has a lower priority. Also, automatic recovery via 'errdisable recovery' is not the recommended manual recovery method described in the question; the question asks to recover without reloading, but automatic recovery is an alternative, not the direct action.

Configure spanning-tree vlan 10,20 priority 0 and spanning-tree bpduguard enable on Gi0/1; then use 'no spanning-tree bpduguard' to recover the port.

Why wrong: Setting priority to 0 is valid but extreme and may cause issues if other switches also use 0. More importantly, disabling BPDU Guard does not recover the port; the port remains err-disabled until you issue 'shutdown' and 'no shutdown'.

Configure spanning-tree vlan 10,20 priority 4096 and spanning-tree portfast on Gi0/1; then use 'clear spanning-tree detected-protocols' to recover the port.

Why wrong: While the spanning-tree configuration is correct, the recovery command is wrong. 'clear spanning-tree detected-protocols' is used to re-run the spanning-tree algorithm, not to recover an err-disabled port. The correct recovery is 'shutdown' and 'no shutdown'.

G0/1 is in forwarding state (Root Guard), G0/2 is in blocking state (Loop Guard), G0/3 is in err-disable state (BPDU Guard).

Why wrong: This is incorrect because Root Guard does not allow the port to forward when a superior BPDU is received; it blocks the port. Loop Guard does not block the port immediately; it only blocks if BPDUs stop being received. Here, BPDUs are still being received, so G0/2 should be forwarding.

G0/1 is in err-disable state (Root Guard), G0/2 is in forwarding state (Loop Guard), G0/3 is in blocking state (BPDU Guard).

Why wrong: This is incorrect because Root Guard does not place the port in err-disable; it blocks the port while the superior BPDU is received, and the port recovers automatically when the superior BPDU stops. BPDU Guard places the port in err-disable, not blocking state.

G0/1 is in blocking state (Root Guard), G0/2 is in loop-inconsistent state (Loop Guard), G0/3 is in err-disable state (BPDU Guard).

Why wrong: This is incorrect because Loop Guard only transitions to loop-inconsistent blocking state when BPDUs are no longer received. In this scenario, BPDUs are still being received on G0/2, so it remains in forwarding state. The question does not indicate a unidirectional link failure.

Another DHCP scope

Why wrong: A DHCP scope is a pool of IP addresses that a server hands out to clients; it controls address assignment, not traffic measurement. Adding another scope would only expand the number of leases available, and while it might indirectly change addressing, it would not reveal which applications or conversations fill the interface. The 'high utilization' observed via SNMP therefore remains an unexplained aggregate number, not a conversation detail.

A new STP priority

Why wrong: STP priority is a spanning-tree election value that determines which switch becomes the root and which redundant paths are placed in blocking state. Reconfiguring it can move traffic to a different physical path, but it offers zero visibility into existing flows. The administrator needs a flow-based telemetry source, not a topology-control parameter, to see the specific traffic causing high utilization.

A larger OSPF metric

Why wrong: OSPF metric (cost) is a routing parameter that influences shortest-path selection, not a tool for inspecting live traffic. Even with a larger metric on an interface, the administrator would only see route changes, never which source/destination pairs are consuming the interface's bandwidth. SNMP utilization counters are aggregate, so OSPF tuning cannot break down the utilization by conversation.

1. Configure BPDU Guard on PortFast ports. 2. Configure Loop Guard on non-designated ports. 3. Configure Root Guard on designated ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, re-enable BPDU Guard on the port.

Why wrong: This is incorrect because BPDU Guard should be applied after PortFast is enabled, but the order of applying protections is not arbitrary; Root Guard and Loop Guard have specific port roles. Also, re-enabling BPDU Guard does not recover an err-disabled port; the port must be manually reset or errdisable recovery must be configured.

1. Configure Loop Guard on non-designated ports. 2. Configure Root Guard on designated ports. 3. Configure BPDU Guard on PortFast ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, configure errdisable recovery cause bpduguard.

Why wrong: This is incorrect because while errdisable recovery can automatically recover the port, the question asks for the steps to recover a port that enters err-disabled due to BPDU Guard violation. The standard recovery method is manual reset, not automatic recovery. Additionally, the order of Root Guard and Loop Guard is swapped; Root Guard should be configured before Loop Guard? Actually, the order of these two does not matter as long as they are applied to correct port roles. However, the recovery method is not the most direct answer.

1. Configure Root Guard on designated ports. 2. Configure BPDU Guard on PortFast ports. 3. Configure Loop Guard on non-designated ports. 4. To recover a port that enters err-disabled due to BPDU Guard violation, remove BPDU Guard from the port.

Why wrong: This sequence correctly places Root Guard on designated ports and Loop Guard on non-designated ports, but the recovery step is fundamentally flawed. Removing BPDU Guard from the interface does NOT clear the err-disabled state; the port remains administratively down until you issue a manual shutdown followed by no shutdown, or until global errdisable recovery (if configured) automatically re-enables it. Additionally, merely deleting the BPDU Guard configuration does not alter the fact that the port was error-disabled by the STP watchdog, and the port will not pass traffic until that state is manually cleared.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable no shutdown

Why wrong: This is incorrect because after enabling BPDU Guard, the port is already in err-disabled state and will not recover without a manual shutdown/no shutdown cycle. Simply issuing 'no shutdown' without first shutting down the interface will not clear the err-disabled state.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable end copy running-config startup-config

Why wrong: The command sequence enables PortFast and BPDU Guard, but then exits to privileged exec and saves the running configuration. This does not address the immediate operational issue: the port is currently in err-disabled state because BPDU Guard detected a BPDU. Saving the configuration only persists the intended PortFast/BPDU Guard settings; it does not clear the error condition. To recover, the port must be manually cycled with shutdown followed by no shutdown, or the interface must be brought out of err-disabled via other means (e.g., errdisable recovery). Therefore, this sequence leaves the port offline.

interface g0/3 spanning-tree portfast spanning-tree bpduguard enable shutdown

Why wrong: After enabling BPDU Guard, issuing only shutdown places the port administratively down. While shutdown does clear the err-disabled state (as part of the manual recovery process), the port remains down because no subsequent no shutdown is issued. The standard recovery sequence requires both shutdown and no shutdown to transition from err-disabled to up/up. Hence, this incomplete sequence fails to restore connectivity.

Root Guard on Gi0/1, Loop Guard on Gi0/2, BPDU Guard on Gi0/0

Why wrong: This is incorrect because Root Guard should be applied on the designated port facing SW2 (Gi0/2), not on the uplink to the core (Gi0/1). Loop Guard should be on the uplink, not on the designated port.

Root Guard on Gi0/0, Loop Guard on Gi0/1, BPDU Guard on Gi0/2

Why wrong: This is incorrect because Root Guard should not be on an access port (Gi0/0) as it is PortFast-enabled and not expected to receive BPDUs; BPDU Guard is more appropriate there. BPDU Guard on Gi0/2 would err-disable the designated port upon receiving a superior BPDU, which is not the intended behavior.

Root Guard on Gi0/2, Loop Guard on Gi0/0, BPDU Guard on Gi0/1

Why wrong: This answer correctly places Root Guard on the designated port Gi0/2, but it misassigns the two remaining protections. Loop Guard is intended for root or alternate blocking ports, where a unidirectional link could cause a stale blocking state; an access port like Gi0/0 is not a blocking port and is better protected by BPDU Guard because it is PortFast-enabled. Placing BPDU Guard on the uplink Gi0/1 would improperly err-disable a legitimate switch-to-switch link if a normal BPDU is received, defeating its purpose of protecting end-user access ports.

JSON — data modeling language used to define network schemas such as YANG modules

Why wrong: The pairing is incorrect because JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format, not a data modeling language. It uses curly braces and arrays to represent structured data, but it cannot define network schemas or modules. In the YANG ecosystem, JSON is often used as an encoding format for data that is modeled by YANG, but the modeling language itself is YANG, not JSON.

YANG — lightweight interchange format built from curly braces and arrays

Why wrong: The pairing is incorrect because YANG (Yet Another Next Generation) is a data modeling language used to define network schemas, constraints, and semantics for configuration and operational data. It uses a hierarchical tree-like syntax with modules and statements, not curly braces and arrays. The description of a lightweight interchange format with curly braces and arrays actually refers to JSON, which is a data serialization format, not a modeling language.

NETCONF — spanning-tree enhancement for rapid convergence

Why wrong: The pairing is incorrect because NETCONF is a network management protocol, defined in RFC 6241, that provides mechanisms to install, manipulate, and delete configuration on network devices using XML-based messages over SSH or TLS. It has nothing to do with spanning-tree or rapid convergence. Rapid convergence is a feature of spanning-tree enhancements like Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP), which are unrelated to NETCONF.

Learning

Why wrong: During the learning state, the switch does begin populating its MAC address table by examining the source addresses of frames received on the port, even though it still does not forward those frames out any port. This state lasts for the forward-delay timer (15 seconds) and serves to avoid temporary loops while the port prepares to enter the forwarding state. It does not listen for BPDUs as its primary function; that happens in the listening state.

Forwarding

Why wrong: In the forwarding state, a port actively sends and receives normal user traffic, including its own BPDUs, and it is the final operating state for all root and designated ports. While a port in forwarding state continues to receive BPDUs from neighboring switches, it is no longer in the formal 'listening' phase because the switch has already converged on the active topology. Forwarding is not the state where a port listens for BPDUs to make STP decisions; that listening function is confined to the earlier listening state.

Disabled

Why wrong: A disabled port on a classic 802.1D switch is administratively shut down or has failed a hardware or link test, so it is completely excluded from the spanning-tree process. Because the port is not active, it neither sends nor receives BPDUs, does not learn MAC addresses, and does not forward any frames. The disabled state is not a normal STP transition state but rather an administrative or fault condition.

Root Guard automatically shuts down the port when a superior BPDU is received, similar to BPDU Guard.

Why wrong: The claim that Root Guard shuts down the port like BPDU Guard is incorrect. BPDU Guard moves the port to errdisable state, but Root Guard never errdisables the interface; it places the port in a root-inconsistent (blocking) state only as long as the superior BPDU is received. When the superior BPDU disappears, the port immediately resumes forwarding, so no manual recovery or administrative shutdown is involved.

Loop Guard, when enabled, disables a port if BPDUs are no longer received on it, preventing a unidirectional link failure.

Why wrong: This option misstates Loop Guard's behavior and purpose. Loop Guard does not disable (errdisable) a port; rather, when a root or alternate port stops receiving BPDUs — typically because of a unidirectional link failure — it transitions that port to a loop-inconsistent state, which is a blocking state that still allows BPDUs to be sent. Moreover, Loop Guard does not prevent the physical link failure itself; it only prevents the bridging loop that would occur if the switch incorrectly made that port designated and started forwarding.

BPDU Guard places the port in a blocking state (loop-inconsistent) when a BPDU is received, similar to Loop Guard.

Why wrong: BPDU Guard does not place the port in an STP blocking or 'loop-inconsistent' state like Loop Guard; it takes much more aggressive action by placing the interface in errdisable state. The loop-inconsistent state is used by Loop Guard when a port stops receiving BPDUs, and it does not involve BPDU reception. This option inverts the two mechanisms and incorrectly claims that BPDU Guard behaves similarly to Loop Guard.

Configure 'spanning-tree vlan 10 root primary' and 'spanning-tree vlan 20 root secondary' on MLS1. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This configuration is incorrect for VLAN 20 because 'spanning-tree vlan 20 root secondary' sets MLS1's bridge priority to 28672, which is the backup-root value, not the primary-root value of 24576 used by 'root primary'. While MLS1 would still outbid a switch at the default priority 32768, the command explicitly designates it as the standby root, contrary to the requirement that MLS1 be the root for both VLANs. Moreover, the verification commands only inspect VLAN 10 via 'show spanning-tree vlan 10' and the interface status, leaving VLAN 20's root election completely unverified.

Configure 'spanning-tree vlan 10 priority 4096' and 'spanning-tree vlan 20 priority 4096' on MLS1. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This is incorrect because setting the priority to 4096 is not the standard method; the 'root primary' command automatically sets the priority to 24576 (or lower if needed). A priority of 4096 is lower than 24576 and would also make the switch root, but the question specifically asks to use the 'root primary' command.

Configure 'spanning-tree vlan 10 root primary' and 'spanning-tree vlan 20 root primary' on MLS1. Then configure 'spanning-tree portfast default' and 'spanning-tree bpduguard default' globally. Verify with 'show spanning-tree vlan 10' and 'show interfaces gigabitEthernet0/1 status'.

Why wrong: This is incorrect because the question states that PortFast and BPDU Guard are already enabled on G0/1. Configuring them globally would apply to all access ports, which is unnecessary and could cause issues on trunk ports. The existing configuration on the interface is sufficient.

DNS automatically assigns IP addresses to hosts.

Why wrong: This is wrong because DHCP assigns IP configuration.

DNS replaces the need for subnet masks.

Why wrong: This is wrong because subnet masks still define address scope.

DNS elects the STP root bridge.

Why wrong: This is wrong because DNS and STP are unrelated.

The trunk native VLAN is 1 on both sides

Why wrong: The native VLAN applies only to untagged frames on a trunk, and both sides having native VLAN 1 is a consistent, default configuration that would not block tagged VLAN 30 traffic. VLAN 30 frames would typically be sent with an 802.1Q tag, so the native VLAN setting has no bearing on their forwarding. If a native VLAN mismatch existed, it would affect untagged management traffic, not the tagged user VLAN that already has local connectivity.

SW2 must run VTP server mode

Why wrong: VTP mode controls VLAN database advertisement, not the per-interface permitted VLAN list. SW2 could be a VTP server or client and still drop VLAN 30 on a trunk if the trunk's allowed list excludes it. Since local hosts in VLAN 30 can already communicate, the VLAN exists; the missing remote reachability points to trunk filtering, not VTP. Changing VTP mode would not alter the trunk's configured allowed VLANs.

Spanning tree blocks all user VLANs by default

Why wrong: Spanning Tree Protocol places redundant interfaces into a blocking state to prevent loops, but it does not block all user VLANs by default; normal forwarding ports remain active for every allowed VLAN. If STP were blocking VLAN 30, local devices on SW2 would also fail to communicate because their access ports would be in a blocking or disabled state. Since local reachability works and the failure is specific to remote destinations, a trunk-level VLAN filtering issue—not STP—is the correct explanation.