350-401 · topic practice
Practise ENCOR 350-401 Qos practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
Trap 1: Weighted Random Early Detection (WRED)
Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that actively drops packets as queue depth crosses configured thresholds, preferentially marking or dropping lower-priority traffic to prevent TCP global synchronization. It is not a scheduling algorithm and has no concept of a priority queue or a dequeue order that can favor voice packets. In practice, WRED alone would still allow delay-sensitive packets to be dropped or queued arbitrarily, adding jitter and violating the strict latency requirement for real-time traffic.
Trap 2: Class-Based Weighted Fair Queuing (CBWFQ)
Class-Based Weighted Fair Queuing (CBWFQ) defines traffic classes and allocates each a guaranteed minimum bandwidth using weighted fair queuing within each class. However, it lacks a strict-priority queue: the scheduler serves classes based on configured weights and bandwidth, so a voice packet cannot be dequeued ahead of all remaining packets in lower-priority classes if its class is not the current user of the scheduler. Because latency and jitter are not bounded and no class gets absolute precedence, CBWFQ alone cannot deliver the lowest, predictable delay that interactive real-time traffic demands.
Trap 3: First-In, First-Out (FIFO)
First-In, First-Out (FIFO) places all packets in a single transmit queue and sends them in the exact order they arrive, meaning there is no mechanism to classify or prioritize interactive voice over bulk data. A single burst of file transfers or a greedy TCP stream can fill the queue, causing real-time packets to wait behind earlier arrivals and introducing variable delay and jitter. Consequently, FIFO offers no latency guarantee and is entirely unsuitable for low-latency real-time transport on a WAN link.
Low Latency Queuing (LLQ)
Low Latency Queuing (LLQ) is correct because it integrates a strict priority queue (PQ) with CBWFQ. The LLQ scheduler always empties the priority class before servicing any other CBWFQ class, which guarantees that real-time packets like voice are dequeued first and experience minimal, jitter-free delay. To prevent the PQ from starving other classes, LLQ applies a policer to priority-class traffic, dropping or shaping excess packets while still meeting the latency objective for admitted real-time flows.
Weighted Random Early Detection (WRED)
Why it fails: Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that actively drops packets as queue depth crosses configured thresholds, preferentially marking or dropping lower-priority traffic to prevent TCP global synchronization. It is not a scheduling algorithm and has no concept of a priority queue or a dequeue order that can favor voice packets. In practice, WRED alone would still allow delay-sensitive packets to be dropped or queued arbitrarily, adding jitter and violating the strict latency requirement for real-time traffic.
Class-Based Weighted Fair Queuing (CBWFQ)
Why it fails: Class-Based Weighted Fair Queuing (CBWFQ) defines traffic classes and allocates each a guaranteed minimum bandwidth using weighted fair queuing within each class. However, it lacks a strict-priority queue: the scheduler serves classes based on configured weights and bandwidth, so a voice packet cannot be dequeued ahead of all remaining packets in lower-priority classes if its class is not the current user of the scheduler. Because latency and jitter are not bounded and no class gets absolute precedence, CBWFQ alone cannot deliver the lowest, predictable delay that interactive real-time traffic demands.
First-In, First-Out (FIFO)
Why it fails: First-In, First-Out (FIFO) places all packets in a single transmit queue and sends them in the exact order they arrive, meaning there is no mechanism to classify or prioritize interactive voice over bulk data. A single burst of file transfers or a greedy TCP stream can fill the queue, causing real-time packets to wait behind earlier arrivals and introducing variable delay and jitter. Consequently, FIFO offers no latency guarantee and is entirely unsuitable for low-latency real-time transport on a WAN link.
Trap 1: The voice class should use priority instead of bandwidth
Replacing `bandwidth` with `priority` for the voice class will not fix the underlying allocation problem. `priority` provides strict priority queueing for delay-sensitive traffic, but it still uses the interface `bandwidth` value to compute the policed rate when the `priority percent` keyword is used. Moreover, strict priority can starve other classes if traffic exceeds the priority policer, whereas the issue described is about incorrect absolute bandwidth reservation due to a wrong interface reference—not about latency or priority handling.
Trap 2: The video class should use bandwidth remaining percent
Moving the video class to `bandwidth remaining percent` would only change how the unused bandwidth is distributed after all classes receive their guaranteed minimums. It does not alter the absolute amount of bandwidth reserved for the voice class, which is incorrectly based on the default interface bandwidth. The voice class's `bandwidth percent` is still computed against the wrong reference value, so video's allocation method has no bearing on the voice under-allocation. The proper fix is to correct the interface bandwidth, not to reallocate leftover bandwidth.
Trap 3: The policy map is applied in the input direction
Applying the policy map in the input direction is unsupported for CBWFQ bandwidth guarantees; on Cisco IOS, the `bandwidth` and `priority` commands are only honored in the output direction. For ingress traffic, only policing (e.g., `police`) is available—bandwidth reservation and queuing are egress-only features. Even if the policy were applied outbound, the voice under-allocation would persist because the interface bandwidth reference is still incorrect. Additionally, the question describes a misallocation, not a directional limitation, so the answer must address the root cause: the missing `bandwidth 50000` statement.
The interface bandwidth command is not set to 50000 kbps
The root cause is that CBWFQ's percent-based bandwidth commands (bandwidth percent, priority percent) are calculated against the interface `bandwidth` setting, not the physical line rate. If an Ethernet interface retains its default bandwidth of 1000000 kbps (1 Gbps) while the actual WAN circuit is 50 Mbps, a voice class configured with `bandwidth percent 10` would reserve 100000 kbps instead of 5000 kbps. Without `bandwidth 50000` under the interface, the percentages do not map to the real link speed, so the voice class appears under-allocated even though the configuration is logically correct.
The voice class should use priority instead of bandwidth
Why it fails: Replacing `bandwidth` with `priority` for the voice class will not fix the underlying allocation problem. `priority` provides strict priority queueing for delay-sensitive traffic, but it still uses the interface `bandwidth` value to compute the policed rate when the `priority percent` keyword is used. Moreover, strict priority can starve other classes if traffic exceeds the priority policer, whereas the issue described is about incorrect absolute bandwidth reservation due to a wrong interface reference—not about latency or priority handling.
The video class should use bandwidth remaining percent
Why it fails: Moving the video class to `bandwidth remaining percent` would only change how the unused bandwidth is distributed after all classes receive their guaranteed minimums. It does not alter the absolute amount of bandwidth reserved for the voice class, which is incorrectly based on the default interface bandwidth. The voice class's `bandwidth percent` is still computed against the wrong reference value, so video's allocation method has no bearing on the voice under-allocation. The proper fix is to correct the interface bandwidth, not to reallocate leftover bandwidth.
The policy map is applied in the input direction
Why it fails: Applying the policy map in the input direction is unsupported for CBWFQ bandwidth guarantees; on Cisco IOS, the `bandwidth` and `priority` commands are only honored in the output direction. For ingress traffic, only policing (e.g., `police`) is available—bandwidth reservation and queuing are egress-only features. Even if the policy were applied outbound, the voice under-allocation would persist because the interface bandwidth reference is still incorrect. Additionally, the question describes a misallocation, not a directional limitation, so the answer must address the root cause: the missing `bandwidth 50000` statement.
Trap 1: Change the video traffic marking to DSCP AF41 and rely on…
This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Trap 2: Apply a service policy that uses a priority queue for voice only
Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Trap 3: Increase the number of queues to eight
Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
Modify the CoS-to-queue mapping using the 'mls qos srr-queue output cos-map' command
This command is correct because on Catalyst switches the default queue assignment for output traffic is based on the CoS value in the 802.1Q header. By modifying the CoS-to-queue map, you can explicitly assign voice (typically CoS 5) to a strict-priority queue and video (e.g., CoS 4) to a separate standard queue, thereby preventing inter-class contention. The command takes precedence over any default mapping and gives the engineer deterministic control over which hardware queue each marked packet uses.
Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping
Why it fails: This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Apply a service policy that uses a priority queue for voice only
Why it fails: Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Increase the number of queues to eight
Why it fails: Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
Trap 1: Remark all traffic to a single DSCP value at the access layer and…
Re-marking all traffic to a single DSCP value, such as DSCP 0, at the access layer removes the very differentiation QoS depends on. The core's priority queue would then contain every class of traffic, so voice packets no longer receive the strict priority treatment they need; either the queue overflows and drops voice, or you would have to also discard the EF markings that identify voice RTP. This breaks Cisco's end-to-end QoS model, which requires distinct DSCP per class to support per-hop behavior.
Trap 2: Apply QoS policies only at the core layer, ignoring markings from…
Applying QoS only at the core while ignoring access-layer markings is flawed because classification must happen as close to the source as possible, and the access switch is the trust boundary for IP phone DSCP. If the access switch is not configured to trust DSCP, it will reset packets to the default DSCP (often 0) on egress, so the core receives no meaningful markings to act on—it would need to reclassify every flow from raw packet inspection. Even if the core can infer QoS, the access layer still needs to police/trust at the edge, otherwise the markings are nonexistent when they arrive.
Trap 3: Use the distribution layer to reclassify traffic based on source…
Reclassifying traffic at the distribution layer by source MAC address of IP phones is impractical and fragile because it relies on static L2 bindings that break when phones are moved, replaced, or when MAC spoofing occurs, and it requires the distribution switch to know every phone MAC. DSCP trust is the industry-standard approach because it uses L3 markings already set by phones—like EF for voice—making the policy protocol-independent and scalable to large campuses, whereas MAC-based classification is CPU-intensive, non-standard, and does not align with Cisco's recommended trust boundary at the access port.
Configure the access switches to trust DSCP on ports connected to IP phones, and apply queuing policies on distribution and core switches that match the trusted markings.
Trusting DSCP on IP phone ports is the correct trust boundary because Cisco IP phones set Expedited Forwarding (EF, DSCP 46) for voice RTP; access switches should preserve this marking via 'mls qos trust dscp' rather than re-marking. With those markings intact, distribution and core switches can apply consistent queuing policies—strict priority for EF voice, class-based queuing for call signaling (CS3/AF31) and data—so voice quality is maintained end to end and the trust boundary stays at the access layer.
Remark all traffic to a single DSCP value at the access layer and apply priority queuing at the core.
Why it fails: Re-marking all traffic to a single DSCP value, such as DSCP 0, at the access layer removes the very differentiation QoS depends on. The core's priority queue would then contain every class of traffic, so voice packets no longer receive the strict priority treatment they need; either the queue overflows and drops voice, or you would have to also discard the EF markings that identify voice RTP. This breaks Cisco's end-to-end QoS model, which requires distinct DSCP per class to support per-hop behavior.
Apply QoS policies only at the core layer, ignoring markings from the access layer.
Why it fails: Applying QoS only at the core while ignoring access-layer markings is flawed because classification must happen as close to the source as possible, and the access switch is the trust boundary for IP phone DSCP. If the access switch is not configured to trust DSCP, it will reset packets to the default DSCP (often 0) on egress, so the core receives no meaningful markings to act on—it would need to reclassify every flow from raw packet inspection. Even if the core can infer QoS, the access layer still needs to police/trust at the edge, otherwise the markings are nonexistent when they arrive.
Use the distribution layer to reclassify traffic based on source MAC addresses of IP phones.
Why it fails: Reclassifying traffic at the distribution layer by source MAC address of IP phones is impractical and fragile because it relies on static L2 bindings that break when phones are moved, replaced, or when MAC spoofing occurs, and it requires the distribution switch to know every phone MAC. DSCP trust is the industry-standard approach because it uses L3 markings already set by phones—like EF for voice—making the policy protocol-independent and scalable to large campuses, whereas MAC-based classification is CPU-intensive, non-standard, and does not align with Cisco's recommended trust boundary at the access port.
Trap 1: Class-based weighted fair queuing (CBWFQ).
CBWFQ is a class-based scheduling mechanism that allocates guaranteed bandwidth to each configured class using weighted fair queueing. However, it does not provide a strict-priority queue, so voice packets are treated like any other class and can experience queuing delay or be dropped when the interface is congested. While it ensures minimum bandwidth for voice, it cannot enforce the strict latency and zero-drop guarantee that real-time traffic requires.
Trap 2: Weighted random early detection (WRED).
Weighted random early detection (WRED) drops packets probabilistically before congestion occurs, which directly violates the requirement that voice traffic must never be dropped. WRED is tempting because it is designed to manage congestion by selectively discarding lower-priority packets, and it would be correct for a data-only class where controlled drops are acceptable to avoid tail-drop. However, for a loss-sensitive voice class, a strict priority queue (LLQ) is required to guarantee zero drops.
Trap 3: First-in, first-out (FIFO) queuing.
FIFO is the simplest queuing mechanism, where packets are transmitted in the exact order they arrive with no traffic classification or priority treatment. Under FIFO, voice traffic is not distinguished from any other traffic, so if the queue fills up due to bursty data traffic, voice packets will suffer the same tail-drop as other packets. This makes it completely unsuitable for real-time services that demand low latency and zero packet loss.
Class-based weighted fair queuing (CBWFQ).
Why it fails: CBWFQ is a class-based scheduling mechanism that allocates guaranteed bandwidth to each configured class using weighted fair queueing. However, it does not provide a strict-priority queue, so voice packets are treated like any other class and can experience queuing delay or be dropped when the interface is congested. While it ensures minimum bandwidth for voice, it cannot enforce the strict latency and zero-drop guarantee that real-time traffic requires.
Low-latency queuing (LLQ).
LLQ combines class-based weighted fair queueing with a strict priority queue, allowing voice traffic to be placed in a dedicated priority queue that is served before all other queues. This guarantees that voice packets are always served first, providing low latency and eliminating drops for voice traffic even during congestion. To prevent the priority queue from starving other classes, LLQ typically applies a policer to limit the amount of traffic that can use the priority queue.
Weighted random early detection (WRED).
Why it fails: Weighted random early detection (WRED) drops packets probabilistically before congestion occurs, which directly violates the requirement that voice traffic must never be dropped. WRED is tempting because it is designed to manage congestion by selectively discarding lower-priority packets, and it would be correct for a data-only class where controlled drops are acceptable to avoid tail-drop. However, for a loss-sensitive voice class, a strict priority queue (LLQ) is required to guarantee zero drops.
First-in, first-out (FIFO) queuing.
Why it fails: FIFO is the simplest queuing mechanism, where packets are transmitted in the exact order they arrive with no traffic classification or priority treatment. Under FIFO, voice traffic is not distinguished from any other traffic, so if the queue fills up due to bursty data traffic, voice packets will suffer the same tail-drop as other packets. This makes it completely unsuitable for real-time services that demand low latency and zero packet loss.
Trap 1: The priority queue is not configured with a bandwidth statement.
This is incorrect because, in LLQ, the priority queue is always configured with a bandwidth statement via the `priority` command. A missing bandwidth statement would make the configuration invalid or cause the class to be treated as a normal class, not a priority queue. The drops in question are due to the implicit policer that is activated when the priority bandwidth is assigned, not because of a missing statement. Thus, the problem is traffic exceeding the configured bandwidth, not the absence of a bandwidth value.
Trap 2: The class-map is not matching voice traffic correctly.
This is not the cause. The scenario explicitly states that drops are occurring in the priority queue, which proves that voice traffic is being matched and placed into that queue. If the class-map were misconfigured, voice traffic would be classified into a different queue (such as the default class) and would not experience policer drops. The fact that the drops happen at the priority queue indicates the matching is working correctly; the issue lies in the policer's configured bandwidth threshold.
Trap 3: The router is using FIFO queuing instead of LLQ.
This is incorrect because LLQ is indeed in operation, as evidenced by the policer dropping excess traffic. FIFO queuing has no built-in policer; drops under FIFO occur only through tail drop when the interface buffer is full, not based on a configured bandwidth. The scenario describes drops specifically due to policing, which is a signature feature of LLQ's priority queue. Therefore, the queuing mechanism is correctly identified as LLQ, and the drops are not caused by using FIFO instead.
The priority queue is not configured with a bandwidth statement.
Why it fails: This is incorrect because, in LLQ, the priority queue is always configured with a bandwidth statement via the `priority` command. A missing bandwidth statement would make the configuration invalid or cause the class to be treated as a normal class, not a priority queue. The drops in question are due to the implicit policer that is activated when the priority bandwidth is assigned, not because of a missing statement. Thus, the problem is traffic exceeding the configured bandwidth, not the absence of a bandwidth value.
The priority queue has a built-in policer that drops traffic exceeding the configured bandwidth.
This is correct. In Low Latency Queuing (LLQ), the `priority` command with a bandwidth value creates both a strict priority queue and an implicit policer. This policer strictly limits the traffic served from the priority queue to the configured bandwidth; any voice traffic exceeding that rate is immediately dropped, rather than being queued. This mechanism prevents the priority queue from starving other queues, but it requires that the bandwidth be sized to handle voice bursts. Therefore, the drops are the expected behavior of the policer when the configured rate is too low for the incoming voice traffic.
The class-map is not matching voice traffic correctly.
Why it fails: This is not the cause. The scenario explicitly states that drops are occurring in the priority queue, which proves that voice traffic is being matched and placed into that queue. If the class-map were misconfigured, voice traffic would be classified into a different queue (such as the default class) and would not experience policer drops. The fact that the drops happen at the priority queue indicates the matching is working correctly; the issue lies in the policer's configured bandwidth threshold.
The router is using FIFO queuing instead of LLQ.
Why it fails: This is incorrect because LLQ is indeed in operation, as evidenced by the policer dropping excess traffic. FIFO queuing has no built-in policer; drops under FIFO occur only through tail drop when the interface buffer is full, not based on a configured bandwidth. The scenario describes drops specifically due to policing, which is a signature feature of LLQ's priority queue. Therefore, the queuing mechanism is correctly identified as LLQ, and the drops are not caused by using FIFO instead.
Examine the following configuration:
policy-map SHAPE_POLICY
class class-default
shape average 10000000 service-policy INNER_POLICY
What is the purpose of the nested service-policy (service-policy INNER_POLICY) under the shape command?
Trap 1: It applies the INNER_POLICY to traffic before shaping, which is not…
The inner policy is never applied before shaping in a valid hierarchical QoS configuration. In Cisco IOS, the child service-policy is attached to the parent's shape statement and is executed after the shaper has released packets, meaning the traffic first passes through the shaping mechanism and then through the child policy's classification and queuing. Applying a policy before shaping would require the child policy to be on the interface or in the parent's bandwidth statement, which is not how the shape command with service-policy is designed to work.
Trap 2: It is used to shape traffic twice, first at 10 Mbps and then again…
The inner policy does not perform a second shaping operation; it is typically configured for queuing (e.g., class-based weighted fair queueing) or policing, not shaping. The parent policy shapes at 10 Mbps, and the child policy manages the internal distribution of that shaped bandwidth among different traffic classes. If the inner policy were to shape again, it would unnecessarily delay traffic and create nested token buckets, but the actual configuration only allows one shaping layer at the parent level and uses the child for scheduling, not for another rate limit.
Trap 3: This configuration is invalid because service-policy cannot be…
Nesting a service-policy under the shape command is a valid and supported feature in Cisco IOS for implementing hierarchical QoS. This is explicitly allowed on platforms that support HQoS, and it is the standard way to combine a shaper with per-class queuing. The configuration is not invalid; rather, the order of operations is parent shaper first, then child policy, which is exactly what the command sequence 'shape average 10000000' followed by 'service-policy INNER_POLICY' produces.
It applies the INNER_POLICY to traffic after shaping, allowing per-class queuing within the shaped rate.
In hierarchical QoS (HQoS), the outer policy performs shaping at the parent level, and after the shaper has metered the traffic to the configured rate, the inner policy is applied to the shaped output. This allows the child policy to classify and queue traffic into multiple classes, all within the aggregate shaped bandwidth. The result is that each class gets its own queue and scheduling behavior, but the total output never exceeds the parent's shaped rate, so per-class queuing occurs inside the shaper's token bucket.
It applies the INNER_POLICY to traffic before shaping, which is not supported.
Why it fails: The inner policy is never applied before shaping in a valid hierarchical QoS configuration. In Cisco IOS, the child service-policy is attached to the parent's shape statement and is executed after the shaper has released packets, meaning the traffic first passes through the shaping mechanism and then through the child policy's classification and queuing. Applying a policy before shaping would require the child policy to be on the interface or in the parent's bandwidth statement, which is not how the shape command with service-policy is designed to work.
It is used to shape traffic twice, first at 10 Mbps and then again based on INNER_POLICY.
Why it fails: The inner policy does not perform a second shaping operation; it is typically configured for queuing (e.g., class-based weighted fair queueing) or policing, not shaping. The parent policy shapes at 10 Mbps, and the child policy manages the internal distribution of that shaped bandwidth among different traffic classes. If the inner policy were to shape again, it would unnecessarily delay traffic and create nested token buckets, but the actual configuration only allows one shaping layer at the parent level and uses the child for scheduling, not for another rate limit.
This configuration is invalid because service-policy cannot be nested under shape.
Why it fails: Nesting a service-policy under the shape command is a valid and supported feature in Cisco IOS for implementing hierarchical QoS. This is explicitly allowed on platforms that support HQoS, and it is the standard way to combine a shaper with per-class queuing. The configuration is not invalid; rather, the order of operations is parent shaper first, then child policy, which is exactly what the command sequence 'shape average 10000000' followed by 'service-policy INNER_POLICY' produces.
Trap 1: VRF can be used to replace VLANs for Layer 2 isolation.
VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.
Trap 2: In VRF-lite, path isolation is achieved using MPLS labels.
VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.
VRFs allow multiple customers to share the same physical infrastructure while keeping their traffic isolated.
VRFs provide logical separation at Layer 3 by maintaining independent routing and forwarding tables per customer on shared hardware. This satisfies the stem's path isolation requirement, letting overlapping address space coexist without leakage between tenants across the same physical service provider infrastructure.
In MPLS VPN, VRFs are combined with route targets to control route distribution between PE routers.
In MPLS VPN, route targets are extended BGP community attributes attached to VPNv4 routes, determining which VRFs import or export them. This controls route distribution between PE routers, satisfying the stem's requirement for combining VRFs with route targets.
VRF-aware features such as NAT, QoS, and ACLs can be applied per VRF to enforce path isolation policies.
VRF-aware NAT, QoS and ACLs operate within each routing table's forwarding context, so policy is enforced per tenant rather than globally. This satisfies the stem's path isolation requirement by keeping traffic separated end to end, letting each VRF carry independent filtering, marking and translation rules without leaking between customers.
VRF can be used to replace VLANs for Layer 2 isolation.
Why it fails: VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.
In VRF-lite, path isolation is achieved using MPLS labels.
Why it fails: VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.
Consider the following configuration snippet:
policy-map QOS_POLICY
class VOICE
priority percent 30
class VIDEO
bandwidth percent 20 queue-limit 50 packets
class class-default
fair-queue queue-limit 100 packets
What is the effect of this configuration?
Trap 1: The VOICE class traffic is always sent before other classes, and…
This option incorrectly assumes that excess priority traffic is reclassified and moved into the default class. In Cisco MQC, the priority command with a percent policer uses a token-bucket policer: conforming traffic is transmitted, and exceeding traffic is dropped immediately—there is no mechanism to transfer excess frames to class-default. The default class only receives traffic that was never matched by a user-defined class, not overflow from a priority class.
Trap 2: The VIDEO class traffic is treated with strict priority after the…
Only the VOICE class has the `priority` command in this policy, so it is the sole class that receives strict-priority treatment. VIDEO is configured with a bandwidth guarantee (e.g., `bandwidth percent 20`), which provides a minimum bandwidth allocation under congestion, not priority forwarding. Even if VIDEO had a priority command, it would be serviced after VOICE because VOICE is also a priority class; but here VIDEO lacks the priority keyword entirely.
Trap 3: The class-default uses Weighted Fair Queuing with a maximum queue…
The class-default does run fair-queue by default, but the statement that it has a maximum queue size of 100 packets is not part of the MQC policy shown; queue depth is governed by platform buffer settings, not a fixed 100-packet limit. More importantly, bandwidth is not shared equally among all classes: VOICE and VIDEO each have their own allocated bandwidth percentages, and class-default only receives the remaining bandwidth, which is then further divided by fair-queue among flows inside that class. VIDEO is guaranteed a fixed 20% of the interface bandwidth, not an equal share of the remaining bandwidth.
The VOICE class traffic is always sent before other classes, but if it exceeds 30% of the interface bandwidth, excess traffic is dropped.
The VOICE class is assigned strict priority through the `priority` command, so its packets are dequeued before any other class whenever the priority queue is non-empty. The `percent 30` keyword configures an aggregate policer that allows traffic up to 30% of the interface bandwidth and drops any excess immediately (conform-action transmit, exceed-action drop). This is a hard ceiling—excess voice traffic is not re-queued or forwarded, it is discarded on the spot.
The VOICE class traffic is always sent before other classes, and excess traffic beyond 30% is queued in the default class.
Why it fails: This option incorrectly assumes that excess priority traffic is reclassified and moved into the default class. In Cisco MQC, the priority command with a percent policer uses a token-bucket policer: conforming traffic is transmitted, and exceeding traffic is dropped immediately—there is no mechanism to transfer excess frames to class-default. The default class only receives traffic that was never matched by a user-defined class, not overflow from a priority class.
The VIDEO class traffic is treated with strict priority after the VOICE class.
Why it fails: Only the VOICE class has the `priority` command in this policy, so it is the sole class that receives strict-priority treatment. VIDEO is configured with a bandwidth guarantee (e.g., `bandwidth percent 20`), which provides a minimum bandwidth allocation under congestion, not priority forwarding. Even if VIDEO had a priority command, it would be serviced after VOICE because VOICE is also a priority class; but here VIDEO lacks the priority keyword entirely.
The class-default uses Weighted Fair Queuing with a maximum queue size of 100 packets, and all classes share the remaining bandwidth equally.
Why it fails: The class-default does run fair-queue by default, but the statement that it has a maximum queue size of 100 packets is not part of the MQC policy shown; queue depth is governed by platform buffer settings, not a fixed 100-packet limit. More importantly, bandwidth is not shared equally among all classes: VOICE and VIDEO each have their own allocated bandwidth percentages, and class-default only receives the remaining bandwidth, which is then further divided by fair-queue among flows inside that class. VIDEO is guaranteed a fixed 20% of the interface bandwidth, not an equal share of the remaining bandwidth.
Drag a concept onto its matching description — or click a concept then click the description.
Uses RSVP to signal per-flow reservations; Requires per-flow state in every router
Classifies traffic using DSCP markings; Scales well for large enterprise networks
No guarantees for delivery or delay
Trap 1: There is no difference; both commands allocate bandwidth based on…
The two commands draw from fundamentally different, non-overlapping pools. The 'bandwidth' command reserves a fixed amount of the total interface bandwidth (or a policy-map's declared interface bandwidth) for a class, whereas 'bandwidth remaining' calculates a percentage based only on the residual bandwidth that exists after the priority queue and all explicitly allocated 'bandwidth' amounts have been removed. Thus, a class using 'bandwidth remaining' is not competing for the same pool as one using 'bandwidth', so treating them as identical is technically false.
Trap 2: 'bandwidth' is used for output policies, while 'bandwidth…
Both 'bandwidth' and 'bandwidth remaining' are used in output policies, not input policies. In MQC, these commands are configured in class maps within a policy map that is attached in the output direction, where CBWFQ and LLQ scheduling decisions apply. Input policies rely on policing mechanisms like the 'police' command to limit or mark packets; 'bandwidth' and 'bandwidth remaining' are scheduling/reservation tools that only have meaning in the egress direction where queueing occurs.
Trap 3: 'bandwidth' guarantees a minimum rate, while 'bandwidth remaining'…
This option is incorrect because while 'bandwidth' does guarantee a minimum rate, claiming that 'bandwidth remaining' sets a maximum rate is false. 'bandwidth remaining' is a proportional guarantee, not a cap: it guarantees a class a specific share of the leftover bandwidth after priority queues are serviced, meaning the class can use as much as that share allows under congestion, but it does not impose a hard maximum like a policer's 'police' rate. Thus, 'bandwidth remaining' also provides a minimum bandwidth commitment, just from the residual pool rather than the total link.
There is no difference; both commands allocate bandwidth based on the total interface bandwidth.
Why it fails: The two commands draw from fundamentally different, non-overlapping pools. The 'bandwidth' command reserves a fixed amount of the total interface bandwidth (or a policy-map's declared interface bandwidth) for a class, whereas 'bandwidth remaining' calculates a percentage based only on the residual bandwidth that exists after the priority queue and all explicitly allocated 'bandwidth' amounts have been removed. Thus, a class using 'bandwidth remaining' is not competing for the same pool as one using 'bandwidth', so treating them as identical is technically false.
'bandwidth' allocates from the total bandwidth, while 'bandwidth remaining' allocates from the bandwidth left after priority queues.
This is the correct answer. The 'bandwidth' command, in a CBWFQ policy map, explicitly allocates a guaranteed rate from the total interface bandwidth, and that rate is reserved under congestion. In contrast, 'bandwidth remaining' specifies a percentage or proportion of the bandwidth that is left after the priority queue (for low-latency traffic) and after all explicit 'bandwidth' allocations have been satisfied. Therefore, 'bandwidth remaining' is a fair-sharing mechanism for the leftover, non-priority bandwidth rather than a reservation from the full link capacity.
'bandwidth' is used for output policies, while 'bandwidth remaining' is used for input policies.
Why it fails: Both 'bandwidth' and 'bandwidth remaining' are used in output policies, not input policies. In MQC, these commands are configured in class maps within a policy map that is attached in the output direction, where CBWFQ and LLQ scheduling decisions apply. Input policies rely on policing mechanisms like the 'police' command to limit or mark packets; 'bandwidth' and 'bandwidth remaining' are scheduling/reservation tools that only have meaning in the egress direction where queueing occurs.
'bandwidth' guarantees a minimum rate, while 'bandwidth remaining' sets a maximum rate.
Why it fails: This option is incorrect because while 'bandwidth' does guarantee a minimum rate, claiming that 'bandwidth remaining' sets a maximum rate is false. 'bandwidth remaining' is a proportional guarantee, not a cap: it guarantees a class a specific share of the leftover bandwidth after priority queues are serviced, meaning the class can use as much as that share allows under congestion, but it does not impose a hard maximum like a policer's 'police' rate. Thus, 'bandwidth remaining' also provides a minimum bandwidth commitment, just from the residual pool rather than the total link.
Consider the following configuration:
policy-map QUEUE_POLICY
class VOICE
priority level 1 police cir 1000000
class VIDEO
priority level 2 police cir 2000000
class class-default
fair-queue
What is the effect of using priority level 1 and priority level 2?
Trap 1: VOICE and VIDEO traffic are treated equally and share the priority…
Priority levels are not equal; level 1 is strictly ordered ahead of level 2. Traffic in different priority levels is placed into separate queues, not a shared priority bandwidth. Each level has its own policer, and the scheduler does not treat them as a single aggregate to be consumed together. The statement that they share priority bandwidth is therefore incorrect.
Trap 2: VIDEO traffic (level 2) is sent before VOICE traffic (level 1)…
The scheduling order is determined solely by the priority level, not by the configured police rate. A higher police rate does not elevate a packet's precedence; level 2 video is always scheduled after level 1 voice. If the voice policer admits less than its rate, the remaining strict-priority service is still reserved for voice, never for video. Therefore, video cannot be sent first because of a higher police rate.
Trap 3: This configuration is invalid because only one priority level is…
The configuration is not invalid. Cisco platforms like the ASR 1000 explicitly support multiple priority levels (up to several) to provide a hierarchy within the strict-priority scheduling. A single-priority-level system is a limitation of simpler platforms, but the syntax here is valid on those that support it. The presence of a police command under each priority level does not make the configuration illegal.
VOICE traffic (level 1) is always sent before VIDEO traffic (level 2), and both are policed.
In Cisco's hierarchical QoS, 'priority level 1' and 'priority level 2' create separate strict-priority queues. The scheduler empties level 1 before level 2, so voice is always sent before video, even if video's policed rate were higher. Both levels are independently policed to their configured rates; excess traffic is dropped or optionally re-marked. This is valid on platforms such as the ASR 1000 that support multiple priority levels.
VOICE and VIDEO traffic are treated equally and share the priority bandwidth.
Why it fails: Priority levels are not equal; level 1 is strictly ordered ahead of level 2. Traffic in different priority levels is placed into separate queues, not a shared priority bandwidth. Each level has its own policer, and the scheduler does not treat them as a single aggregate to be consumed together. The statement that they share priority bandwidth is therefore incorrect.
VIDEO traffic (level 2) is sent before VOICE traffic (level 1) because it has a higher police rate.
Why it fails: The scheduling order is determined solely by the priority level, not by the configured police rate. A higher police rate does not elevate a packet's precedence; level 2 video is always scheduled after level 1 voice. If the voice policer admits less than its rate, the remaining strict-priority service is still reserved for voice, never for video. Therefore, video cannot be sent first because of a higher police rate.
This configuration is invalid because only one priority level is allowed.
Why it fails: The configuration is not invalid. Cisco platforms like the ASR 1000 explicitly support multiple priority levels (up to several) to provide a hierarchy within the strict-priority scheduling. A single-priority-level system is a limitation of simpler platforms, but the syntax here is valid on those that support it. The presence of a police command under each priority level does not make the configuration illegal.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
No classification, single queue, packets served in order of arrival
Automatically classifies flows and provides fair queuing per flow
Allows creation of custom traffic classes with guaranteed bandwidth
Adds a strict priority queue within CBWFQ for delay-sensitive traffic
Multiple queues with strict priority servicing, lower queues starve if higher queues are non-empty
Trap 1: Random Early Detection (RED)
RED (Random Early Detection) is a congestion avoidance mechanism that monitors the average queue depth and probabilistically drops packets before the queue overflows. It does not classify traffic or reserve bandwidth, and voice packets are dropped just as readily as data packets when congestion develops, which directly degrades voice quality. RED is therefore a drop policy, not a queuing or scheduling mechanism, so it cannot provide the strict delay and loss guarantees that voice needs.
Trap 2: First In First Out (FIFO)
FIFO (First In First Out) creates a single shared queue and transmits packets in arrival order, applying no classification or differentiation whatsoever. Voice packets are therefore placed behind whatever bulk data, transactions, or overhead traffic arrived earlier; during congestion, latency and jitter grow unpredictably and the voice stream can be starved. Since FIFO cannot offer any priority or bandwidth guarantee to real-time flows, it is unsuitable for voice deployments that need consistent low-latency treatment.
Trap 3: Class-Based Weighted Fair Queuing (CBWFQ)
CBWFQ (Class-Based Weighted Fair Queuing) allocates a proportionate weight/bandwidth to each configured traffic class and schedules them fairly according to those weights, so it cannot guarantee a voice class an immediate service advantage. A voice class in CBWFQ still has to 'take its turn' alongside other classes' queues based on the weighted fair scheduler, and under overload the voice queue can experience queuing delay. It provides per-class bandwidth management but lacks the strict priority scheduling that real-time audio needs, which is why LLQ extends CBWFQ with an explicit priority queue.
Random Early Detection (RED)
Why it fails: RED (Random Early Detection) is a congestion avoidance mechanism that monitors the average queue depth and probabilistically drops packets before the queue overflows. It does not classify traffic or reserve bandwidth, and voice packets are dropped just as readily as data packets when congestion develops, which directly degrades voice quality. RED is therefore a drop policy, not a queuing or scheduling mechanism, so it cannot provide the strict delay and loss guarantees that voice needs.
Low Latency Queuing (LLQ)
LLQ (Low Latency Queuing) combines a strict-priority queue with CBWFQ: the priority queue is serviced first on every scheduling cycle, before any CBWFQ class queues, so voice is dequeued with minimal and deterministic delay. The priority queue can be policed to a configured rate to prevent a flood of priority traffic from starving the non-priority classes, but within the committed rate voice effectively experiences 'express lane' treatment. This strict-priority scheduling is exactly what makes LLQ the standard QoS queueing strategy for real-time voice traffic in an enterprise.
First In First Out (FIFO)
Why it fails: FIFO (First In First Out) creates a single shared queue and transmits packets in arrival order, applying no classification or differentiation whatsoever. Voice packets are therefore placed behind whatever bulk data, transactions, or overhead traffic arrived earlier; during congestion, latency and jitter grow unpredictably and the voice stream can be starved. Since FIFO cannot offer any priority or bandwidth guarantee to real-time flows, it is unsuitable for voice deployments that need consistent low-latency treatment.
Class-Based Weighted Fair Queuing (CBWFQ)
Why it fails: CBWFQ (Class-Based Weighted Fair Queuing) allocates a proportionate weight/bandwidth to each configured traffic class and schedules them fairly according to those weights, so it cannot guarantee a voice class an immediate service advantage. A voice class in CBWFQ still has to 'take its turn' alongside other classes' queues based on the weighted fair scheduler, and under overload the voice queue can experience queuing delay. It provides per-class bandwidth management but lacks the strict priority scheduling that real-time audio needs, which is why LLQ extends CBWFQ with an explicit priority queue.
Trap 1: The port trusts the CoS value of incoming packets.
Trusting CoS would require explicit interface configuration such as "mls qos trust cos" to preserve the 802.1p priority carried in the Ethernet header. The default switchport state is untrusted, meaning the switch does not honor any incoming CoS markings and instead forces all packets to a best-effort CoS value of 0, so this option is false.
Trap 2: The port trusts the DSCP value of incoming packets.
DSCP trust is an IP-layer behavior configured with "mls qos trust dscp" and can only apply to IP packets that already contain a DSCP field. In the default configuration, the switchport is untrusted and does not inspect the DSCP value for ingress classification; all traffic is re-marked with CoS 0, which is not the same as trusting DSCP, making this option incorrect.
Trap 3: The port trusts both CoS and DSCP values.
The default state of a switchport is untrusted, not a dual-trust mode for both Layer 2 CoS and Layer 3 DSCP values. Trusting both fields would require intentional configuration of trust policies, and even then the switch would only honor those fields according to its mapping tables; an unconfigured port overwrites both CoS and DSCP to 0, so this option is incorrect.
The port trusts the CoS value of incoming packets.
Why it fails: Trusting CoS would require explicit interface configuration such as "mls qos trust cos" to preserve the 802.1p priority carried in the Ethernet header. The default switchport state is untrusted, meaning the switch does not honor any incoming CoS markings and instead forces all packets to a best-effort CoS value of 0, so this option is false.
The port trusts the DSCP value of incoming packets.
Why it fails: DSCP trust is an IP-layer behavior configured with "mls qos trust dscp" and can only apply to IP packets that already contain a DSCP field. In the default configuration, the switchport is untrusted and does not inspect the DSCP value for ingress classification; all traffic is re-marked with CoS 0, which is not the same as trusting DSCP, making this option incorrect.
The port is untrusted and marks all incoming packets with CoS 0.
When QoS is globally enabled, all switchports default to an untrusted state, meaning they do not preserve any priority information carried in incoming frames. Every packet received on such a port is marked with CoS 0 (and correspondingly DSCP 0) before entering the switch fabric, so saying the port is untrusted and marks all packets with CoS 0 accurately describes the default behavior.
The port trusts both CoS and DSCP values.
Why it fails: The default state of a switchport is untrusted, not a dual-trust mode for both Layer 2 CoS and Layer 3 DSCP values. Trusting both fields would require intentional configuration of trust policies, and even then the switch would only honor those fields according to its mapping tables; an unconfigured port overwrites both CoS and DSCP to 0, so this option is incorrect.
Drag or tap steps into the slots.
Trap 1: Class-Based Weighted Fair Queuing (CBWFQ)
CBWFQ provides bandwidth guarantees to classes but does not offer strict priority. During congestion, CBWFQ queues are serviced in a weighted fair manner, which can introduce latency and jitter for VoIP. VoIP requires strict priority to ensure low latency, so CBWFQ alone is not sufficient.
Trap 2: Weighted Random Early Detection (WRED)
WRED is a congestion avoidance mechanism that drops packets based on queue thresholds to prevent tail drop. It does not provide priority queuing. While it can be used in conjunction with LLQ, WRED alone does not prioritize VoIP traffic; it merely manages congestion.
Trap 3: Traffic Shaping
Traffic shaping delays packets to smooth out bursts and conform to a specified rate. It does not provide priority queuing; instead, it can introduce additional delay. For VoIP, shaping is not appropriate as it can increase latency and jitter, which are detrimental to voice quality.
Class-Based Weighted Fair Queuing (CBWFQ)
Why it fails: CBWFQ provides bandwidth guarantees to classes but does not offer strict priority. During congestion, CBWFQ queues are serviced in a weighted fair manner, which can introduce latency and jitter for VoIP. VoIP requires strict priority to ensure low latency, so CBWFQ alone is not sufficient.
Weighted Random Early Detection (WRED)
Why it fails: WRED is a congestion avoidance mechanism that drops packets based on queue thresholds to prevent tail drop. It does not provide priority queuing. While it can be used in conjunction with LLQ, WRED alone does not prioritize VoIP traffic; it merely manages congestion.
Traffic Shaping
Why it fails: Traffic shaping delays packets to smooth out bursts and conform to a specified rate. It does not provide priority queuing; instead, it can introduce additional delay. For VoIP, shaping is not appropriate as it can increase latency and jitter, which are detrimental to voice quality.
Low Latency Queuing (LLQ)
LLQ combines CBWFQ with a strict priority queue. It allows VoIP traffic to be placed in a priority queue that is serviced before other queues, ensuring minimal delay and jitter. LLQ is the recommended mechanism for prioritizing real-time traffic like VoIP during congestion.
Trap 1: Class-Based Weighted Fair Queuing (CBWFQ)
CBWFQ provides weighted fair queuing for different classes but does not offer strict priority. It allocates bandwidth to each class based on configured weights, but during congestion, all classes are subject to the scheduler, and voice traffic could be delayed. CBWFQ is often used in conjunction with Low Latency Queuing to provide priority, but alone it does not meet the requirement.
Trap 2: Weighted Random Early Detection (WRED)
WRED is a congestion avoidance mechanism that randomly drops packets before the queue is full to prevent tail drop. It does not provide strict priority queuing. WRED is typically used for TCP traffic to avoid global synchronization, but it does not prioritize voice traffic. Voice traffic requires strict priority, which WRED cannot provide.
Trap 3: First-In, First-Out (FIFO) queuing
FIFO queuing processes packets in the order they arrive, with no prioritization. During congestion, voice packets could be delayed behind large data packets, causing jitter and poor voice quality. FIFO does not meet the requirement for strict priority and is not suitable for delay-sensitive traffic like voice.
Low Latency Queuing (LLQ)
LLQ provides strict priority queuing for delay-sensitive traffic such as voice. It combines priority queuing with CBWFQ. The priority queue is serviced first, and voice traffic is placed in this queue, ensuring it is transmitted before other traffic even during congestion. LLQ also includes a policer to limit the priority queue bandwidth, preventing starvation of other queues.
Class-Based Weighted Fair Queuing (CBWFQ)
Why it fails: CBWFQ provides weighted fair queuing for different classes but does not offer strict priority. It allocates bandwidth to each class based on configured weights, but during congestion, all classes are subject to the scheduler, and voice traffic could be delayed. CBWFQ is often used in conjunction with Low Latency Queuing to provide priority, but alone it does not meet the requirement.
Weighted Random Early Detection (WRED)
Why it fails: WRED is a congestion avoidance mechanism that randomly drops packets before the queue is full to prevent tail drop. It does not provide strict priority queuing. WRED is typically used for TCP traffic to avoid global synchronization, but it does not prioritize voice traffic. Voice traffic requires strict priority, which WRED cannot provide.
First-In, First-Out (FIFO) queuing
Why it fails: FIFO queuing processes packets in the order they arrive, with no prioritization. During congestion, voice packets could be delayed behind large data packets, causing jitter and poor voice quality. FIFO does not meet the requirement for strict priority and is not suitable for delay-sensitive traffic like voice.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Qos sessions
Every question in these sessions is drawn from the Qos domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Sharpen your 350-401 knowledge of Architecture.
Practise 350-401 questions linked to Virtualization.
Work through 350-401 questions on Infrastructure.
Sharpen your 350-401 knowledge of Network Assurance.
Security practice questions for 350-401.
Targeted 350-401 practice covering Automation.
Practise eBGP/iBGP peering, path attributes, route selection and BGP troubleshooting.
Practise OSPF area types, LSA types, neighbour states and multi-area design.
Practise EIGRP DUAL, metrics, stub routing and route redistribution.
Practise VLAN configuration, trunk negotiation and inter-VLAN routing.
Practise RSTP, MSTP, port roles and STP protection features.
Practise extended ACLs, CoPP rate-limiting and control-plane protection.
A free account saves results across sessions and highlights which topics need work.
Sign up free