The transit authority evaluates software-defined networking for its core. Which architecture implication of SDN is most accurate?
Select an answer to reveal the explanation.
Short Explanation
SDN is like a traffic control tower talking to many intersections—brains in one place, cars still on the roads. Central policy programming is the point, not ditching policy. CLI-per-box forever is the old model SDN is trying to improve.
Full Explanation
Software-defined networking separates the control plane (where policy and forwarding decisions are programmed) from the data plane (where packets are forwarded on switches and routers). That separation lets the transit authority define network policy centrally—segmentation, path rules, security intents—and push consistent enforcement to forwarding devices, improving agility compared with purely per-box CLI management. Security architecture implications include protecting the SDN controllers as high-value assets, authenticating southbound/northbound channels, and ensuring policy changes are authorized and logged, because central brains become a concentrated trust point.
Claiming SDN merges control and data planes so policy can only be set on each switch CLI describes the opposite of SDN's defining trait. Saying SDN removes the need for any network security policy because forwarding becomes random is nonsense—SDN is a way to implement policy, not abandon it. Restricting SDN to wireless guest portals only ignores its common use in wired data-center and campus cores.
Exam caveat: SDN items usually test control-plane/data-plane separation and centralized programmable policy. Operationally, harden and monitor controllers, restrict who can change network intents, segment management of the SDN fabric from general user VLANs, and validate that security policies (microsegmentation, ACL equivalents) still meet municipal zoning requirements after migration from classic CLI workflows.