CCNP Practice Question: Which two statements about the QoS trust boundary…

Answer analysis

Option-by-option breakdown

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

• ✗

  By default, a Cisco switch port in access mode trusts the CoS value received from the attached device.

  Why it's wrong here

  Access ports are inherently untrusted in Cisco's default QoS model. Because a PC or other end host may generate arbitrary 802.1p CoS values, the switch ignores any such marking and reclassifies the traffic to internal DSCP zero. To change this, you must explicitly configure 'mls qos trust cos' or 'mls qos trust dscp' on the access port, thereby placing the endpoint inside the trust boundary.

• ✓

  On a trunk port, the switch can be configured to trust the CoS value by default.

  Why this is correct

  Trunk ports carry 802.1Q frames between infrastructure devices, so the switch defaults to trusting the CoS field in the frame header. This design assumes that the upstream switch, router, or voice gateway has already classified and marked the traffic, and preserving that Layer 2 marking prevents frame-by-frame reclassification. If you want to trust DSCP instead of CoS on a trunk, you must explicitly override the default with 'mls qos trust dscp'.

• ✓

  The trust boundary can be extended to the endpoint by configuring the interface with the 'mls qos trust' command.

  Why this is correct

  The 'mls qos trust' interface-level command moves the trust boundary from the switch to the attached device by instructing the port to honor an incoming CoS, DSCP, or IP-precedence value. For example, 'mls qos trust cos' on an access port tells the switch to use the phone's 802.1p priority to derive the internal DSCP rather than zeroing it out. This command is commonly used with IP phones or IP cameras that mark their own traffic, but it must be paired with the correct trust parameter or the switch will trust the wrong field.

• ✗

  When a Cisco IP Phone is connected, the switch automatically trusts the CoS values from the phone but not from the PC behind the phone.

  Why it's wrong here

  Incorrect. With a Cisco IP Phone, the switch can be configured to trust the phone's marking, but the PC traffic is typically re-marked or untrusted unless the phone is configured to pass through the PC marking.

• ✗

  The 'trust device cisco-phone' command enables the switch to trust all CoS values from both the phone and the attached PC.

  Why it's wrong here

  The 'trust device cisco-phone' command instructs the switch to use CDP to detect and report a Cisco IP Phone, and it activates special phone-related behaviors such as voice VLAN and LLDP-MED settings. It does not change the trust state for either the phone or the PC behind it; to trust the PC's markings, you must separately issue 'mls qos trust cos', and even then the phone typically rewrites or strips the PC's CoS. This command is frequently confused with 'mls qos trust' because both are used in phone deployments, but they perform entirely different functions.