An engineer enabling the Security Fabric on a control-center FortiGate that has multiple VDOMs configured needs to decide which VDOM should host the fabric root role. What consideration should guide that decision?
Select an answer to reveal the explanation.
Short Explanation
VDOMs don't automatically share a Security Fabric identity just because they live on the same box: the fabric root is anchored to one particular VDOM, so picking the right one matters for how the topology and fabric-wide visibility actually come together. It's a deliberate choice, not a default that takes care of itself.
Full Explanation
The Security Fabric root role is associated with a specific VDOM on the device that hosts it, so the fabric's topology view, synchronized settings, and root-level visibility are anchored to that VDOM rather than shared automatically across every VDOM on the box, meaning an engineer enabling the fabric on a multi-VDOM FortiGate has to deliberately choose the VDOM meant to represent and anchor that fabric. Assuming any VDOM works interchangeably ignores that fabric configuration and root status are scoped, not global, across VDOMs. Picking based purely on policy count optimizes for an irrelevant metric, since processing load from policy evaluation isn't what determines fabric root suitability. Claiming the VDOM choice has no bearing at all contradicts the scoped nature of the root role and would leave fabric topology anchored somewhere the engineer never intended. The operational caveat: this is an introductory-level relationship worth confirming rather than assuming, and checking the Security Fabric status and topology page after enabling it verifies the fabric actually anchored to the intended VDOM rather than a default one.