A school district wants SaaS and general Internet to exit locally at each branch while private district apps still go to the hub. Which SD-WAN pattern enables that local Internet exit?
Select an answer to reveal the explanation.
Short Explanation
DIA is the branch’s own on-ramp to the public Internet for SaaS, while private apps still ride the overlay back to the hub. Hauling every student YouTube flow across MPLS to a central exit wastes circuits. Classroom switches do not need the full Internet table to make this work.
Full Explanation
A school district wanting SaaS and general Internet to exit locally at each branch while private district apps still go to the hub should use Direct Internet Access steered by centralized policy so selected traffic breaks out locally. DIA keeps private prefixes on the overlay to hubs while eligible Internet-bound flows exit at the branch—common for civic education sites.
Forcing all Internet URLs through an underlay MPLS-only default with no local exit denies the local-breakout goal.
Hosting the entire public Internet routing table on every classroom switch is operationally absurd and not an SD-WAN DIA pattern.
Disabling OMP site-IDs so every branch becomes a vManage cluster member corrupts site identity and is unrelated to local Internet exit.
Exam caveat: DIA often pairs with security (URL filtering/firewall) at the branch—pathing alone is not a complete guest/SaaS security design.
Operational check: enable DIA for SaaS/Internet app lists, verify local exit with a traceroute, and confirm private apps still prefer hub. Record DIA policy and security posture in the district branch WAN standard. 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.