CCNP Practice Question: Examine the following configuration: policy-map…

Answer analysis

Option-by-option breakdown

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

• ✓

  It applies the INNER_POLICY to traffic after shaping, allowing per-class queuing within the shaped rate.

  Why this is correct

  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's wrong here

  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's wrong here

  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's wrong here

  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.