A school district wants proof that guest Wi-Fi conversations are not reaching finance subnets. How does Flexible NetFlow help validate that policy intent?

A school district wanting proof that guest Wi-Fi conversations are not reaching finance subnets uses Flexible NetFlow as visibility into policy intent. Inspecting exported flow records for guest-source conversations toward finance destinations that should not exist validates whether segmentation is holding. If such flows appear, the fence has a hole—misapplied ACL, routing leak, or shared VRF issue—and NetFlow provides the conversation evidence. If guest-to-finance flows are absent over a representative window while other guest flows appear normally, intent looks intact from a traffic-visibility perspective.

Electing a finance VLAN HSRP active based on guest SSID priority fails because FHRP active election is not how NetFlow validates guest-to-finance isolation. Rewriting guest DHCP options so finance routes disappear from student laptops fails because DHCP option tricks are not NetFlow’s validation method and are not reliable enforcement substitutes. Replacing ACLs entirely so NetFlow becomes the enforcement point fails because NetFlow informs and verifies; ACLs/segmentation policies still enforce. Visibility is not the same as control.

Exam caveat: NetFlow = observe conversations; ACL/firewall/segmentation = enforce policy. ENCOR items often test whether you know NetFlow proves intent without claiming it replaces enforcement. Combine NetFlow findings with interface ACLs or SGTs as the design intends.

Operational check: build a flow record that keys guest source prefixes and finance destinations, export from enforcement-path interfaces, review collector queries for forbidden pairs, and remediate any hits by correcting ACL/routing—then re-check flows to confirm the leak is closed.