Municipal operators used to log into every top-of-rack switch and type unique CLI. The city now wants desired network state stored once and pushed to the fabric. Which SDN building block replaces device-by-device CLI?
Select an answer to reveal the explanation.
Short Explanation
SDN is one recipe card in a central kitchen, not a bigger stove and not a sticky note on every switch. The manager and controller keep the desired state and push it—buying a larger chassis does not create that plane.
Full Explanation
Municipal operators who abandon unique CLI on every top-of-rack switch need centralized desired state in the management and control planes—the defining SDN building block that stores network intent once and programs the fabric. In NSX, Manager persists configuration while the control plane pushes runtime state to transport nodes so civic networks are declared, not hand-typed per device. A larger modular chassis that still requires per-port CLI is traditional hardware networking scaled up; chassis size is not an SDN control plane. A Horizon App Volumes manager attaches application volumes to desktops and does not program ToR forwarding. A Carbon Black prevention policy can block malicious behavior on endpoints; it does not replace switch CLI with an NSX controller. Exam caveat: SDN centralization does not mean the physical underlay disappears—operators still need underlay IP, MTU, and VLAN hygiene—but desired overlay and security state should not live as unique device CLIs. Operational check: make a segment or policy change once in NSX Manager and confirm it appears consistently on multiple transport nodes without logging into each ToR to hand-edit tenant forwarding; contrast that with a chassis-only change that never updates NSX inventory.