CCNP Practice Question: Is configuring a new switch that will be used as…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

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

  Why this is correct

  Setting the switch's spanning-tree priority to 61440 (the highest numerical value) ensures its bridge ID will never be preferred over a legitimate root, because the root election down-selects the lowest bridge priority. Since Rapid PVST+ (802.1w) is already active, link failures are recovered through explicit proposal/agreement handshakes, eliminating the need for any extra convergence mechanism. This is the recommended way to pin the root on a distribution switch while making access switches incapable of becoming root even after a topology change.

• ✗

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

  Why it's wrong here

  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's wrong here

  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's wrong here

  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.