A port authority wants one operational surface for SD-WAN templates, policies, and monitoring. Which component is that single pane of glass?
Select an answer to reveal the explanation.
Short Explanation
vManage is the port’s glass cockpit—templates, policies, and health views in one place, plus APIs for automation. vBond greets devices; it is not the day-2 ops dashboard. OMP is a protocol, not a GUI, and managing dozens of Edges only from each box’s local UI does not scale.
Full Explanation
A port authority wanting one operational surface for SD-WAN templates, policies, and monitoring should use vManage as the management and orchestration UI and API surface. Operators build feature/device templates, define policies, monitor overlay health, and automate via northbound APIs from vManage.
vBond exclusively forwarding user packets and hosting Assurance dashboards misstates vBond (orchestrator, not data-plane forwarder or primary ops UI).
Each WAN Edge’s local web UI as the only supported multi-site management method does not scale multi-site civic operations.
OMP itself as a graphical operations console for change control confuses a routing protocol with a management GUI.
Exam caveat: day-2 ops still use Edge CLI for deep troubleshooting, but intent and monitoring center on vManage.
Operational check: perform a template change, policy push, and health view entirely from vManage for a pilot site. Declare vManage the port authority’s SD-WAN system of record in ops policy. 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.