rule is "If a root-guard-enabled port receives BPDUs that are superior to the current root bridge is sending, that port is moved to a root-inconsistent state. "
* where the superior BPDU is that the BID is lower than the current root (BID is bridge priority and the system MAC).
so, in your topology, either switch can be Root if current root fails. Or u can make a executive decision not to make sw x root at all (never).
it only matters if one of your switches is oldest one, cannot handle traffic, does not have connections to other switches.
Or if u connect 5th switch off a non-root switch, i.e connect sw5 to sw4. u would put root guard on sw 4 connecting to sw 5. so that some1 does not force sw5 to become root sw.
In a switched network environment with shared administrative control or in a service provider (SP) environment where there are many connections to other switches (into customer networks), it is important to identify the correct placement of the root bridge. If possible, it is also important to identify a specific predetermined location to achieve an optimal forwarding loop-free topology. There is no mechanism in the standard STP to enforce the position of the root bridge, as any bridge in a network with a lower bridge ID can assume the role of the root bridge. Sometimes because of a misconfiguration, a spanning tree may converge incorrectly by selecting an imprecise switch to be the root switch. This situation can be prevented by enabling the Root Guard feature. For example, you could enable Root Guard on SP-side switch interfaces that connect to a customer-side switch. With the Root Guard feature implemented, if a switch outside the SP network becomes the root switch, the interface is put in a blocked state, and spanning tree will select a new root switch. The customer's switch does not become the root switch and is not in the path to the root.
With the Root Guard feature, a Layer 2 interface is set as the designated port, and if any device through this port becomes the root bridge, the interface is placed into the blocked (root-inconsistent) state. The Root Guard feature can be enabled by using the spanning-tree guard root command in interface configuration mode.
In general, you should configure root guard on the ports that should not become root ports under any circumstances. For example, if you have got clearly defined Core, Distribution and Access layer, you want to make sure that ports on Distribution switches, connecting to Access layer switches never become root ports.
In your example topology, you don't have clearly defined layers and there is no indication as to what switch should be the root. In terms of connectivity, you've got a full mesh and each switch is just as well placed to be the root as any other switch. In this case, there is no real need to protect your root ports, because in case of failure, you do want to have alternative path to the root. So, root guard is not a mandatory feature and is highly dependant on the actual topology.