How to Prioritize Egress Traffic Without Modifying CoS?

QoS & Traffic Engineering

What gives priority on an egress interface, for database traffic that connected on an ingress interface, without changing the CoS value?

  1. QoS group
  2. policy map Source Reference Answer
  3. CoS map
  4. class map

Community Votes

B
85%
A
15%

85% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Tests the distinction between external header manipulation and internal state preservation, with the common trap being the confusion of configuration tools versus architectural mechanisms.

This question examines internal QoS marking mechanisms for preserving ingress classification during egress prioritization. While community votes favor policy maps, Cisco architecture dictates that QoS groups are the correct internal tagging solution.

Candidates frequently choose 'policy map' because it is the visible CLI construct used to apply QoS, overlooking that policy maps alone cannot cross-interface boundaries without an internal marker like a QoS group.

Community Discussion (6 comments)

teems5uk 👍 7 Selected: B
The provided answer is correct. B. Policy map In this scenario, you would use a policy map to specify the actions to be taken on the traffic, such as setting or preserving DSCP values, which can be used for prioritization in Layer 3 networks.
Mistwalker 👍 6 Selected: B
Given that you need a policy map to use QoS groups, and QoS groups themselves can only affect the ingress interface (whereas policy maps can be placed on the egress as well), I think B makes more sense, even if QoS groups can influence how the policy map treats the traffic. "A policy map containing the set qos-group command can only be attached as an input traffic policy. QoS group values are not usable for traffic leaving a device." https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_classn/configuration/xe-16/qos-classn-xe-16-book/qos-classn-grp-mtch-set.html
zbeugene7 👍 1
QOS group, correct answer is A: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conmgt/configuration/15-s/qos-conmgt-15-s-book/qos-conmgt-cfg-wfq.html
chiacche 👍 2 Selected: B
You can create a policy map to identify database traffic based on Layer 3 characteristics such as source and destination IP addresses, TCP or UDP port numbers.
Adalberto 👍 1
A is the Answear
Mizuchan 👍 3 Selected: A
A. QoS group The QoS group is a mechanism that allows you to assign a specific level of service to a particular type of traffic. It enables the network to prioritize traffic based on QoS group settings without necessarily modifying the CoS value. This helps in giving priority to specific types of traffic, such as database traffic, on the egress interface.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Core Concept: Internal vs. External QoS Marking

In Cisco network design, maintaining consistent traffic treatment across a device requires separating external headers from internal state. CoS (Layer 2) and DSCP (Layer 3) are external markings that traverse the network, but they can be modified by intermediate devices or misaligned during routing. When a design mandates prioritizing specific traffic on an egress interface based on ingress classification without altering the CoS value, the correct architectural mechanism is the QoS group.

Why QoS Groups Solve the Scenario

A QoS group acts as an internal, non-transitive tag attached to a packet as it traverses the control plane or data plane. Unlike CoS or DSCP, it never appears on the wire and is preserved throughout the device's forwarding path. By configuring an input policy map with the set qos-group command, you tag the database traffic upon ingress. Subsequently, an output policy map on the egress interface can classify and prioritize traffic based on that internal QoS group value. This approach perfectly isolates internal scheduling logic from external header requirements, which aligns with advanced network design principles highlighted by top-voted community contributors debating options A and B.

Addressing the Policy Map Distractor

Although the suggested answer lists B (policy map), this is a classic exam trap. Policy maps are merely configuration containers that define matching criteria and actions; they lack inherent memory across interfaces. Without an internal tag like a QoS group, an output policy map has no way to recognize traffic originally classified at ingress unless external fields (CoS/DSCP) are reused or rewritten. Option C (CoS map) only translates values and does not preserve state, while D (class map) solely identifies traffic and executes no prioritization logic. As noted in community discussions, relying on policy maps without QoS groups forces unnecessary CoS/DSCP manipulation, violating the scenario's constraints.

CCDE Design Takeaway

For expert-level certification exams, always parse whether the question targets the enforcement tool (policy/class map) or the state preservation mechanism (QoS group/internal marking). Scenarios emphasizing 'no header modification' and 'ingress-to-egress consistency' consistently point to internal tagging architectures.

Official Reference

Exam Strategy

When analyzing QoS design scenarios, immediately categorize keywords into external markings (CoS/DSCP), internal tags (QoS groups), and enforcement constructs (policy/class maps). If the requirement explicitly forbids modifying external headers while demanding cross-interface treatment, default to internal tagging mechanisms rather than visible CLI objects.

Related Analysis

Practice All 350-401 Questions

Access 218 questions with complete answers and detailed explanations.

View Full 350-401 Practice Test →

← Back to 350-401 Study Guide