A water utility wants audit-sensitive spoke-to-spoke flows forced through a hub while camera streams may use direct tunnels. Which SD-WAN capability expresses those different topology intents?
Select an answer to reveal the explanation.
Short Explanation
Topology policy lets you be choosy: some water-works traffic must punch the time clock at the hub, while cameras can take the direct tunnel shortcut. One-size full mesh for every VPN ignores audit needs. PortFast at the plant switch does not shape overlay spoke-to-spoke rules.
Full Explanation
A water utility forcing audit-sensitive spoke-to-spoke flows through a hub while allowing camera streams more direct tunnels should use centralized topology policies. Those policies can enforce hub-and-spoke for some traffic while allowing more direct meshes for others—expressing different topology intents per VPN or traffic class in Cisco SD-WAN.
Identical full-mesh mandatory for every VPN regardless of policy removes the ability to hairpin regulated flows.
Only access-layer PortFast settings at treatment plants affect STP edge behavior, not SD-WAN overlay topology.
Removing all TLOCs except one so topology policy becomes unnecessary forever collapses transport diversity instead of expressing selective topology.
Exam caveat: topology policy interacts with available TLOCs and control policy—verify both or traffic may still take an unexpected path.
Operational check: apply hub-and-spoke topology for the audit VPN and allow mesh for camera VPN, then traceroute both flow types. Document the topology intents in the utility SD-WAN security architecture. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.