CCNP Architecture Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Set trust boundary at the access layer switch and re-mark packets based on source.

  Why this is correct

  The access layer is the optimal trust boundary because it is the first device in the path that can inspect source identities (e.g., IP phone vs. workstation) with port-level granularity. Re-marking DSCP here ensures that packets enter the network with a consistent QoS class, allowing all downstream switches to rely on these markings for queuing and policing. This prevents untrusted end devices from dictating their own priority, which is essential for converged networks carrying voice, video, and data.

• ✗

  Configure marking only at the core layer to simplify policy.

  Why it's wrong here

  Configuring marking only at the core layer is ineffective because by the time packets reach the core, they have already traversed lower layers where congestion and queuing decisions have occurred. The core's primary role is high-speed forwarding, not deep packet inspection, and any marking applied there cannot influence how access and distribution switches handled the traffic. This approach fails to provide end-to-end QoS, as upstream prioritization must be set at the edge to benefit all subsequent hops.

• ✗

  Trust only the distribution layer switches to mark traffic.

  Why it's wrong here

  Trusting distribution layer switches to mark traffic is flawed because packets have already passed through access switches where oversubscription and queuing on access links may cause drops before any marking is applied. Additionally, distribution switches aggregate traffic from many sources, making source-based re-marking coarse and operationally complex, while also shifting the trust boundary away from the actual endpoint. QoS policies should be enforced as close to the source as possible, not after the traffic has already been subjected to network conditions.

• ✗

  Trust the DSCP values set by IP phones and workstations.

  Why it's wrong here

  Trusting DSCP values set by IP phones and workstations is risky because these end devices are not under administrative control and can be misconfigured, compromised, or intentionally spoofed to gain unwanted priority. End-user applications may also set arbitrary DSCP values that conflict with network policy, leading to bandwidth abuse or ineffective queuing. The network must re-mark at the access switch to establish a trusted boundary and enforce a consistent classification based on the device and application type, not on potentially untrustworthy labels.