Transit operations marks PSAP-bound traffic at trusted phones, then asks where the campus QoS trust boundary should typically be enforced?
Select an answer to reveal the explanation.
Short Explanation
Trust boundaries are like the front door security check—either you accept the visitor badge the phone already printed, or you rewrite it before they roam the building. That check belongs at the edge, not after the tour is over.
Full Explanation
A campus QoS trust boundary is where the network decides whether to accept endpoint markings or to remark traffic before it enters interior hops. For transit operations marking PSAP-bound traffic at trusted phones, that boundary is typically enforced at the access edge: trusted phone markings may be accepted, or untrusted markings remarked, before packets enter the campus core. Placing trust correctly protects priority treatment for emergency-bound traffic without allowing arbitrary endpoints to claim expedited markings deep in the network.
Enforcing trust only on Internet peering routers after NAT hides DSCP values is too late and often too lossy for campus classification intent; interior congestion may already have mishandled traffic. Relying only on DHCP scopes that assign voice option 150 confuses provisioning of TFTP/server information with QoS trust. Limiting the idea to SPAN sessions that copy frames to a packet broker describes monitoring, not enforcement of trust before core entry.
Exam caveat: trust-boundary questions reward access-edge enforcement. Options that relocate trust to WAN peering, DHCP options, or SPAN are common distractors.
Operational check: document which phone ports are trusted versus remarked, verify access policies preserve PSAP-bound markings into core queues, and sample packets after the first hop to confirm DSCP still matches the intended emergency voice class.