An airport authority is designing the civic data-center handoff from SD-Access and must distinguish border responsibilities. Which statement correctly contrasts internal and external border roles at a conceptual level?
Select an answer to reveal the explanation.
Short Explanation
Picture doors on a terminal: one opens to the secure ops wing you already trust, another opens to the wild outside world. Internal borders face known internal networks like a civic DC or shared services. External borders face outside/WAN/Internet-style realms with tougher trust and routing assumptions—names that actually change design choices.
Full Explanation
An airport authority designing the civic data-center handoff must distinguish border roles conceptually: an internal border typically connects to known internal networks such as a DC/shared-services fabric area, while an external border faces outside or unknown networks such as Internet/WAN with different trust and routing expectations. That contrast guides routing policy and security posture at the fabric edge of the campus.
Claiming internal and external borders are identical and names exist only for cabling documentation erases real trust and routing differences.
Saying external borders only terminate Layer-2 handoffs while internal borders only run wireless controllers invents false role monopolies.
Requiring internal borders to never run BGP while external borders must not run any routing protocol is an incorrect protocol prohibition.
Exam caveat: exact feature names and fusion options evolve; focus on trust boundary and routing expectations rather than memorizing a single CLI keyword as the whole definition.
Operational check: label each airport border as internal vs external in design docs, verify route exchange and policy match that trust model, and test DC versus Internet-bound flows separately. Keep the border role table in the airport SD-Access interconnect package.