SkillTestPro | CCNP Collaboration 350-801 CLCOR Practice Test 30

CCNP Collaboration 350-801 CLCOR Practice Test 30 (Hard) - Configuring LLQ - Class Maps, Policy Maps, and Service Policies

CCNP Collaboration Exam Questions

1 / 10

Which configuration object on a Cisco IOS XE device is used to define the traffic classification criteria (such as matching a specific DSCP value or access list) that will later be referenced by a QoS policy?

A feature that defines the device's rack mounting position

A feature that defines the device's console banner message

A class map

A feature that defines the device's power supply redundancy configuration

A feature that defines the device's fan speed profile

A feature that defines the device's chassis LED color scheme

2 / 10

Which configuration object on a Cisco IOS XE device defines the actual QoS treatment (such as bandwidth allocation, priority queuing, or marking) to apply to traffic matched by one or more class maps?

A feature that defines the device's power cable color

A feature that defines the device's console port baud rate

A feature that defines the device's rack unit height

A feature that defines the device's SNMP community string

A policy map

A feature that defines the device's chassis fan noise level

3 / 10

Which policy map action specifically implements Low Latency Queuing (LLQ) by guaranteeing a strict-priority queue with a defined bandwidth allocation for latency-sensitive traffic such as voice?

A command that changes the device's console banner message for traffic matching that class

A command that changes the device's rack mounting position for traffic matching that class

A command that changes the device's chassis LED color for traffic matching that class

A command that changes the device's power supply brand for traffic matching that class

The 'priority' command applied to a class within the policy map, establishing a strict-priority queue with a specified bandwidth guarantee

A command that changes the device's fan speed for traffic matching that class

4 / 10

Which step applies a previously configured policy map to actual traffic flowing through a specific interface on an IOS XE device?

Applying a service policy (using the 'service-policy' command) to the interface in the appropriate direction (inbound or outbound)

Changing the interface's auto-negotiation speed and duplex setting with no relation to QoS, in a properly maintained environment, in most deployment scenarios

Changing the interface's spanning-tree port priority with no relation to QoS

Changing the interface's port security MAC address limit with no relation to QoS

Changing the interface's cable management bracket position

Changing the interface's physical port color coding label

5 / 10

Which class map matching criterion would be most appropriate for classifying voice RTP media traffic that has already been marked with an appropriate DSCP value (such as EF) upstream?

A match statement matching the specific DSCP value (such as EF) already applied to the voice media traffic

A match statement matching the color of the cable connecting the device to the network, based on standard platform behavior

A match statement matching the console banner message configured on the device

A match statement matching the brand of the device's power supply

A match statement matching the physical rack position of the device

A match statement matching the font used in the device's configuration file comments

6 / 10

Which outcome would occur if an LLQ priority class is configured with an insufficient bandwidth allocation for the actual volume of voice traffic expected on a given link?

During periods of high call volume, voice packets exceeding the configured priority bandwidth could be dropped or delayed, potentially causing choppy audio or call quality degradation despite LLQ being configured

The router would automatically reboot to apply a corrected bandwidth allocation

The priority class would automatically expand its bandwidth allocation on demand with no configuration change required, which is not the standard approach, which is rarely the correct choice, which is not the standard approach

The priority class would automatically borrow bandwidth from unrelated non-voice traffic classes with no limit

The router would automatically increase the physical interface's link speed to compensate

The router would automatically disable LLQ entirely and revert to best-effort queuing for all traffic

7 / 10

Which troubleshooting step would be appropriate if voice calls continue to experience choppy audio even though a policy map with a priority class for voice has been configured and verified as syntactically correct?

Verify that the service policy has actually been applied to the correct interface and in the correct direction, and confirm using show policy-map interface output that voice traffic is actually being matched and receiving the intended priority treatment

Immediately replace the router's hardware as the first troubleshooting step

Assume LLQ is a deprecated feature no longer supported by IOS XE

Assume the issue is caused by the phase of the moon

Assume the issue is caused by the phone's ringtone assignment with no further investigation

Assume the issue is unrelated to service policy application and only check the office's lighting, under typical configuration conditions, regardless of the platform version in use, which is not the standard approach, regardless of the platform version in use

8 / 10

Which combination of configuration steps would be necessary to correctly implement LLQ for voice traffic on an IOS XE WAN interface, from classification through to actual enforcement?

Only change the interface's port security MAC address limit with no class map, policy map, or service policy configuration at all

Only change the interface's cable management bracket position with no class map, policy map, or service policy configuration at all

Define a class map matching voice traffic (such as by DSCP EF), define a policy map applying the priority command with an appropriate bandwidth guarantee to that class, and apply the policy map to the WAN interface using the service-policy command in the correct direction

Only change the interface's physical port color coding label with no class map, policy map, or service policy configuration at all

Only change the interface's auto-negotiation speed and duplex setting with no class map, policy map, or service policy configuration at all, regardless of the platform version in use, in most deployment scenarios, which does not align with best practices, under normal operating conditions

Only change the interface's spanning-tree port priority with no class map, policy map, or service policy configuration at all

9 / 10

Which statement accurately explains why class maps, policy maps, and service policies are configured as three distinct steps rather than a single combined configuration command on IOS XE devices?

Class maps, policy maps, and service policies are simply three different names for the exact same identical configuration step with no distinction, under normal operating conditions, though this is not generally recommended, in most deployment scenarios, which is not the standard approach, though this is not generally recommended

Class maps alone can fully define bandwidth allocation and priority treatment without any policy map being required

Only one of class maps, policy maps, or service policies is ever actually required to implement any QoS policy on IOS XE

Configuring all three of class maps, policy maps, and service policies together always causes a configuration conflict

Service policies alone can fully define traffic classification without any class map being required

Separating classification (class map), treatment definition (policy map), and application (service policy) allows the same class map or policy map to be reused across multiple policies or interfaces without redefining the classification or treatment logic each time, improving configuration modularity and consistency

10 / 10

Which statement accurately explains why verifying actual traffic match counts and priority queue statistics (such as via show policy-map interface) is an essential final step after configuring LLQ, rather than assuming a syntactically correct configuration guarantees correct behavior?

Verification of actual traffic matching is only relevant during the initial installation of a device and never afterward

Syntactic correctness always guarantees correct runtime behavior for any IOS XE QoS configuration with no exception

Verifying traffic match counts and queue statistics is purely a cosmetic administrative step with no bearing on actual call quality, based on standard platform behavior, under normal operating conditions, under typical configuration conditions, which is rarely the correct choice, which is not the standard approach, though this is not generally recommended

A syntactically valid configuration can still fail to achieve the intended effect due to issues such as incorrect classification criteria, the policy being applied in the wrong direction, or the wrong interface being targeted, so confirming actual matched traffic and queue behavior validates that the configuration is functioning as designed

Show policy-map interface output only displays the device's chassis temperature with no relevance to QoS verification

Verification of actual traffic matching is only necessary for policies that do not include a priority command

Your score is

The average score is 0%