CCNP Practice Question: A network team is designing QoS for a…

Answer analysis

Option-by-option breakdown

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

• ✓

  Implement hierarchical QoS (HQoS) with a parent policy shaping per-tenant traffic and a child policy applying class-based weighted fair queuing (CBWFQ) for each tenant's applications.

  Why this is correct

  HQoS uses a two-level policy map: the parent policy shapes each tenant's aggregate traffic to its contracted bandwidth (e.g., via a shape statement applied to a class that matches the tenant), while the child policy, attached to that parent class, runs CBWFQ to schedule the tenant's application classes. This nesting decouples per-tenant rate enforcement from intra-tenant scheduling, giving both bandwidth isolation between tenants and fair treatment for different applications inside each tenant. Because shaping at the parent level acts as a per-tenant token bucket, no tenant can burst beyond its allowance, and the child policy's queue weights ensure no single application monopolizes the tenant's share.

• ✗

  Use a single level of CBWFQ on all interfaces, classifying traffic by tenant using VLANs.

  Why it's wrong here

  A single-level CBWFQ policy on each interface, using VLANs to classify tenants, is fundamentally a scheduling mechanism—it assigns queue weights but does not limit the aggregate bandwidth that any one tenant can consume. Even with separate classes per VLAN, a tenant with heavy UDP or bursty traffic can dominate its class queue and effectively consume more than its fair share, since CBWFQ only provides relative weighting, not a hard rate cap. Without an outer shaping or policing construct (like the parent policy in HQoS), there is no per-tenant rate limit, so tenants can still starve each other's low-priority traffic.

• ✗

  Apply strict priority queuing for all mission-critical traffic across all tenants.

  Why it's wrong here

  Strict priority queuing for all mission-critical traffic across all tenants collapses their high-priority flows into a single strict-priority queue that always services before all other queues. Consequently, any tenant that floods this priority queue with traffic will cause starvation not only to best-effort traffic but also to other tenants' critical traffic, because the PQ has no per-tenant fairness mechanism or rate limiting. This approach also lacks bandwidth enforcement: there is no shaping or policing at the tenant level, so one tenant's priority traffic can consume the entire interface bandwidth and monopolize the link.

• ✗

  Configure separate physical interfaces for each tenant and apply independent QoS policies.

  Why it's wrong here

  Dedicating separate physical interfaces to each tenant and applying independent QoS policies is technically feasible in a small setup but scales poorly: it multiplies port, cabling, and module costs, and adds significant operational overhead for configuration and monitoring. It also eliminates the benefits of statistical multiplexing, because an idle tenant's unused interface capacity cannot be dynamically reallocated to a busy tenant on another interface, since each is physically isolated. HQoS on a shared interface achieves the same per-tenant separation dynamically through parent-level shaping and child-level CBWFQ, without requiring extra hardware or wasting capacity.