Spanning Tree Protocol Scenarios

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

Why it fails: 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 it fails: 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 it fails: 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.

Configure 'spanning-tree vlan vlan-list priority 0' on the access switch.

Why it fails: A priority of 0 is the lowest possible numeric bridge priority and therefore carries the highest election precedence, meaning the access switch would immediately be selected as root for the listed VLANs. This reverses the desired design, forcing traffic to traverse the access layer and creating an inefficient and potentially unstable forwarding path. In a network where multiple switches hold priority 0, the lowest MAC address decides the root, making the outcome unpredictable. Thus, while 0 is a legal value, using it here directly contradicts the goal of keeping the distribution layer as root.

Enable UplinkFast on the access switch to provide fast failover.

Why it fails: UplinkFast is a legacy proprietary mechanism that only accelerates failover for blocked root ports on access switches, not for general link outages in a Rapid PVST+ domain. Because 802.1w already performs fast convergence through synchronizing handshakes, enabling UplinkFast is redundant and can force the switch to behave inconsistently when both mechanisms are present. It also does not participate in root bridge election, so it would not prevent the access switch from becoming root. In modern Catalyst environments, UplinkFast is effectively obsolete and is automatically disabled when Rapid PVST is configured.

Enable PortFast on the trunk ports to speed up convergence.

Why it fails: PortFast is intended strictly for ports that connect to end hosts, immediately moving them to the forwarding state and bypassing listening and learning; applying it to a trunk that links to another switch suppresses STP on that segment entirely. This creates a serious loop risk because the trunk can forward BPDUs that the switch will ignore, leading to broadcast storms and MAC address flapping. Cisco does offer a 'spanning-tree portfast trunk' option, but that is for authenticated host connections (e.g., a host that requires a trunk), never for a normal switch-to-switch uplink. Since the access switch's trunk to the distribution switch is a switch-to-switch link, PortFast would be an unsafe and incorrect convergence shortcut.

The new switch is not configured with the same VLANs as the distribution switches.

Why it fails: A lack of identical VLAN configurations does not create loops; instead, it causes per-VLAN connectivity failures because traffic for missing VLANs is simply not forwarded. The switch can still run STP and maintain a loop-free topology for the VLANs it does carry. The described symptoms of broadcast storms and severe degradation are not consistent with a simple VLAN mismatch, which would affect only specific VLAN traffic.

The new switch has a lower bridge priority than the current root bridge.

Why it fails: Setting a lower bridge priority makes the new switch more eligible to become the root bridge, but STP still ensures a loop-free environment regardless of which switch is root. The root bridge is a legitimate role, and changing it merely alters the topology paths, causing some traffic to take different routes. It would not by itself generate the broadcast storms or MAC flapping indicative of a Layer 2 loop, so this is not the cause.

The new switch has become the root bridge and is sending inferior BPDUs.

Why it fails: The root bridge does not send inferior BPDUs; it sends superior BPDUs with a higher priority that other switches accept as the best. Becoming the root bridge is a normal condition and does not inherently create loops. This option is incorrect because it both mischaracterizes BPDU behavior and confuses a topology change with a loop, which is the actual cause.

4

Why it fails: The value 4 appears in the output as the individual cost assigned to interfaces Gi0/1 and Gi0/3, typically for 1 Gbps links. However, the question asks for the root path cost—the accumulated cost from this switch to the root bridge—which is listed in the Root ID section as 12. Confusing a per-port cost with the root path cost is a common error. The per-port cost only affects the calculation; it is not the final sum.

16

Why it fails: The output contains no field with the value 16; it is not a port cost, a timer, or the root path cost. A test-taker might incorrectly guess 16 as a mid-range value, but STP costs are typically power-of-two-related (2, 4, 8, 16, 32, 64, etc.) depending on link speed, so 16 could theoretically be a port cost for a slower link, yet the output explicitly shows a root path cost of 12. Since the question asks for the value shown in the output, 16 is a distractor with no basis in the provided data.

20

Why it fails: The spanning-tree output includes timers such as Max Age, Hello Time, and Forward Delay, which are expressed in seconds. In many Cisco outputs, Max Age has a default value of 20, and a candidate might mistake it for a cost metric. However, the root path cost is a dimensionless accumulated cost, not a timer. The correct cost is found in the Root ID section, not in the timer fields. Thus, 20 is a timer value, not the root path cost.

1

Why it fails: Option 1 is incorrect because the spanning-tree output shows more than one port in the Forwarding state. Specifically, Gi0/1, Gi0/2, and Gi0/3 all report state FWD, so counting only a single forwarding port ignores two additional active interfaces. A single forwarding port would only be true if the other two were in Listening, Learning, or Blocking, which is not the case here.

2

Why it fails: Option 2 is incorrect because the output reveals three interfaces, not two, are in the Forwarding state. While Gi0/1 and Gi0/2 might be easily noticed as forwarding, Gi0/3 is also in FWD state, and omitting it undercounts the forwarding ports on this switch. The actual count must include every non-blocking interface that is fully converged and passing traffic, which totals three.

4

Why it fails: Option 4 is incorrect because Gi0/4 is not in the Forwarding state; the spanning-tree output clearly marks it as BLK (Blocking). A Blocking port does not forward user frames and only listens for BPDUs to maintain STP participation. Since Gi0/4 is blocked, counting it as a forwarding port would overstate the number of active forwarding interfaces, which remains three.

bundled: Port is a member of the channel and forwarding

Why it fails: Incorrect: This is a duplicate of the bundled state. While the description is valid, only P1 is the intended match.

stand-alone: Port operates as a regular switch port

Why it fails: Incorrect: This is a duplicate of the stand-alone state. While the description is valid, only P2 is the intended match.

GigabitEthernet0/2

Why it fails: GigabitEthernet0/2 is incorrect because its role is designated ('Desg'), not root. A designated port is the port on a segment that has the best path to the root bridge and is responsible for sending BPDUs to that segment; it is not the port that receives the root bridge's superior BPDUs. Thus, Gi0/2 cannot be SW4's root port.

GigabitEthernet0/3

Why it fails: GigabitEthernet0/3 is also incorrect because its role is designated ('Desg'). Like Gi0/2, it is the forwarding port for its attached segment, but it does not receive the best BPDU from the root bridge. The root port selection is based on lowest root path cost from received BPDUs, and Gi0/1 must have a lower cost than Gi0/3, making Gi0/3 a non-root designated port.

There is no root port because SW4 is the root bridge.

Why it fails: The statement that there is no root port because SW4 is the root bridge is false. The root bridge is identified by the lowest Bridge ID (priority + MAC address), and the spanning-tree output would show SW4 as the root only if its Bridge ID matched the root ID. Since Gi0/1 has a Root role, SW4 must be a non-root switch; the root bridge has no root ports, but all non-root bridges have exactly one.

Set the priority of the access switch to 0 using the 'spanning-tree vlan vlan-id priority 0' command.

Why it fails: Setting the access switch's priority to 0 using `spanning-tree vlan vlan-id priority 0` would make it the root bridge because 0 is the lowest possible bridge priority, giving it precedence over all other switches in the VLAN. This is incorrect because the engineer wants the distribution switch to be the root, not the access switch. Additionally, forcing an access-layer switch to be root can cause suboptimal traffic forwarding, as all inter-VLAN traffic would need to traverse the access layer, which is not designed for such a role.

Increase the priority of the distribution switch to 61440 using the 'spanning-tree vlan vlan-id priority 61440' command.

Why it fails: Increasing the distribution switch's priority to 61440 via `spanning-tree vlan vlan-id priority 61440` would make it less likely to become the root bridge, because a higher numeric priority value indicates a lower priority in STP. Since the root bridge is elected as the switch with the lowest priority (and bridge ID), setting the distribution switch to 61440 would actually push it toward the edge of the spanning tree topology. The engineer's goal is to make the distribution switch the root, so this command directly contradicts the intent and could result in an unexpected access switch becoming root.

Disable STP on the distribution switch and manually configure it as the root bridge.

Why it fails: Disabling STP on the distribution switch removes its ability to participate in the dynamic root bridge election, but it does not manually configure it as the root bridge; a root bridge must still be elected through BPDUs, and without STP running, the switch will not advertise its bridge ID. Furthermore, disabling STP creates a serious risk of Layer 2 loops, which can cause broadcast storms, MAC address flapping, and network outages. Even if you could manually 'force' a root, this approach is unsafe and violates best practices; the correct way is to use STP commands that adjust the bridge priority or use the root primary macro.

Enable Loop Guard on all access ports.

Why it fails: Loop Guard is incorrect because it is designed to detect the absence of BPDUs on a port that is expected to receive them, typically a root port or designated port, and then transition the port to a loop-inconsistent state. It does not take action on receiving a BPDU; rather, it prevents alternate paths from forwarding when BPDUs are lost due to unidirectional link failures, so it cannot block an unauthorized switch that actively sends BPDUs.

Enable Root Guard on all access ports.

Why it fails: Root Guard is incorrect because it only protects the placement of the root bridge by placing a port into a root-inconsistent state when a superior BPDU is received, preventing that port from becoming a root port. The port remains administratively up and still processes BPDUs; it simply stops forwarding on that port while the superior BPDU is present, which does not disable the port or permanently block an unauthorized switch from causing a loop.

Enable UDLD on all access ports.

Why it fails: UDLD is incorrect because it addresses physical unidirectional links by exchanging protocol frames with the neighbor and, upon a missing acknowledgment, either errdisables the interface or reports an undetermined state. It does not examine BPDUs and has no mechanism to detect or prevent a rogue switch from injecting BPDUs into the spanning tree, so it is irrelevant to the scenario of an unauthorized switch causing a loop.

The port will immediately transition to forwarding state and then wait for authentication.

Why it fails: PortFast accelerates Spanning Tree Protocol convergence by moving the port into the forwarding state, but it does not bypass 802.1X authentication. With 'authentication port-control auto', the controlled port remains in the unauthorized state, blocking all user traffic until the supplicant completes EAP authentication. The port may be STP-forwarding, but the 802.1X controlled port will not forward data frames until successful authentication, so this statement conflates two independent mechanisms.

The port will be placed in a VLAN assigned by the RADIUS server after authentication.

Why it fails: Dynamic VLAN assignment by the RADIUS server requires a configured RADIUS server, a AAA method list, and the RADIUS server to return vendor-specific attributes such as Tunnel-Private-Group-ID to change the port VLAN. The given configuration fragment shows none of these elements, so there is no basis to conclude that a RADIUS-assigned VLAN will be used. Without such attributes or server configuration, the port would remain in its locally configured access VLAN after authentication, making this option unsupported by the evidence shown.

The switch will act as a supplicant and respond to EAP requests from an upstream authenticator.

Why it fails: The switch configured with 'dot1x pae authenticator' is explicitly assigned the authenticator role, not the supplicant role. A supplicant would require 'dot1x pae supplicant', and would send EAPOL-Start and respond to EAP-Request/Identity from an upstream authenticator, such as when a switch is connected to a larger network and must prove itself. Since the configuration clearly sets the switch as the authenticator, it is responsible for authenticating downstream devices rather than responding to authentication requests from upstream devices, so this option contradicts the command's purpose.

The local switch is the root bridge for VLAN 10

Why it fails: The output clearly distinguishes the Root ID from the local switch's Bridge ID. The Root ID lists the MAC address 0011.2233.4455, while the Bridge ID for the local switch is 0011.2233.4466, which is a higher MAC address. Since STP elects the root bridge by the lowest bridge ID, a different MAC address confirms the local switch is not that root.

Interface Gi0/2 is in a forwarding state

Why it fails: The interface status in the show spanning-tree output lists Gi0/2 as BLK, which stands for blocking. A blocking port does not forward user traffic; it only listens for BPDUs and is prevented from causing loops. This is distinct from the forwarding state, where the port sends and receives frames. Thus, claiming Gi0/2 is in a forwarding state directly contradicts the output.

The spanning-tree mode is Rapid PVST+

Why it fails: The command output displays 'protocol ieee', which denotes the original IEEE 802.1D STP, not Rapid PVST+. Rapid PVST+ would still show 'protocol ieee' but with additional RSTP-specific port roles such as Alternate and Backup, and it might include timing characteristics like Uptime and Port State based on RSTP. In this output, the only states shown are BLK and FWD, which match 802.1D STP, not the RSTP-based states or roles. Therefore, the spanning-tree mode cannot be Rapid PVST+.

SW2 is the root bridge for VLAN 10.

Why it fails: SW2 cannot be the root bridge for VLAN 10 because it has a root port (Gi0/1); a root bridge has no root port and all of its ports are designated. The Root ID in the output shows a specific MAC address (aabb.cc00.0100) as the root, which would be SW2's own MAC if SW2 were root. Since the Bridge ID for SW2 would differ, SW2 is a non-root switch forwarding toward that root.

Port Gi0/2 is in forwarding state.

Why it fails: Port Gi0/2 is labeled 'Altn BLK' in the output, meaning it is an alternate port in the blocking state. Alternate ports are backups to the root port and are deliberately placed in blocking to prevent L2 loops, receiving more-superior BPDUs from another neighbor. They do not forward traffic unless the root port fails, so Gi0/2 is not currently forwarding.

The STP priority for VLAN 10 is 32768.

Why it fails: The STP priority for VLAN 10 is displayed as 32778, not 32768, because the bridge ID priority field carries both the configurable base priority (32768) and the extended system ID of 10 for VLAN 10. On PVST+ switches, the 12-bit extended system ID is appended to the 4-bit priority, so the effective numeric priority becomes base + VLAN number. Saying 32768 ignores that VLAN component and misreads the bridge ID that STP uses for root election.

SW1 is the root bridge for VLAN 10.

Why it fails: SW1 cannot be the root bridge for VLAN 10 because the root bridge election is decided by the lowest bridge ID, and bridge IDs are compared first by priority and then by MAC address. In this topology, both SW1 and the actual root bridge have the same priority of 32778, so the switch with the lower MAC address, 0011.2233.4455, wins that election. Since SW1's MAC address is 0011.2233.4466, which is higher, SW1 is not the root bridge; instead, SW1 has a root port toward the true root and a blocking alternate port, neither of which would exist on the root bridge.

Gi0/3 is a root port.

Why it fails: Gi0/3 is not a root port because its role in the spanning tree is designated, meaning SW1 is the designated bridge for the segment connected to that interface and is responsible for forwarding BPDUs to that segment. A root port, by contrast, is the single port on a switch that provides the shortest path to the root bridge, and it always remains in forwarding state. Since Gi0/3 has a designated role, it does not satisfy the requirement of being the port with the lowest root path cost, and the actual root port on SW1 is a different interface.

The root bridge has a higher priority than SW1.

Why it fails: The claim that the root bridge has a higher priority than SW1 is incorrect because both switches use the same bridge priority value of 32768 plus the VLAN 10 extended system ID, resulting in 32778. In STP, a numerically lower priority is considered better, so a higher numeric priority would actually make a switch less likely to become the root bridge. Since the priorities are equal, the root bridge is determined by the lower MAC address, and the root bridge's MAC address (0011.2233.4455) is lower than SW1's, not its priority.