Where to Map a New QoS Class to a Queue in vManage?

300-415 By islever Editorial Last updated Sep 23, 2026

Short answer

A Configure the new QoS class-to-hardware-queue mapping in the Local Policy Lists page of vManage, then apply the QoS map to the WAN interface.

Question

The application team is getting ready to deploy a new business-critical application to the network. To protect the traffic, the network team must add another queue to the QoS map and then deploy the map to the fabric. Which configuration step must be completed prior to adding the queue to the QoS map and applying it?

The relationship between the new QoS class and the hardware queue must be configured from the "lists" page of the Local Policy section of vManage. The QoS map is then applied to the WAN interface. Correct Answer
The relationship between the new QoS class and the hardware queue must be configured from the "lists" page of the Local Policy section of vManage. The QoS map is then applied to the service-side interface.
The relationship between the new QoS class and the hardware queue must be configured from the "lists" page of the Centralized Policy section of vManage. The QoS map is then applied to the service-side interface.
The relationship between the new QoS class and the hardware queue must be configured from the "lists" page of the Centralized Policy section of vManage. The QoS map is then applied to the WAN interface.

Key Takeaways

The question tests whether you know that a QoS class-to-hardware-queue mapping is configured as a Local Policy list in vManage and that the resulting QoS map is applied to the WAN interface; the common trap is treating it as a Centralized Policy list or attaching it to the service-side interface.

In Cisco SD-WAN, adding a QoS queue requires mapping the forwarding class to a hardware output queue in the Local Policy Lists page before the QoS map can be applied. This page establishes why option A is correct: the mapping is a localized policy list operation and the QoS map is attached to the WAN interface.

Common mistake: The most common wrong answer is C (or its central-policy variant D), because learners assume the queue mapping is fabric-wide. In Cisco SD-WAN, the class-to-queue relationship is hardware-specific and therefore belongs in the Local Policy lists, not Centralized Policy.

Expert Analysis

Why the Answer Is Correct

Option A is correct because the SD-WAN QoS workflow starts in the Local Policy section of vManage. Before a new queue can be used, the forwarding class (QoS class) must be mapped to a hardware output queue from Configuration > Policies > Custom Options > Lists under Localized Policy; this class-to-queue relationship tells the WAN edge which egress queue to use. The QoS map itself is then deployed to the WAN interface (typically VPN0), because that is the transport-facing egress point where scheduling, shaping, and congestion control protect business-critical traffic. This matches the Cisco SD-WAN design where QoS maps are localized and interface-specific, not part of the centralized fabric policy.

Why the Other Options Are Wrong

Options C and D place the class-to-queue list under the Centralized Policy section, which is wrong: centralized policies distribute fabric-wide constructs such as topology, VPN membership, and application-aware routing, while the class-to-hardware-queue list is a per-device Local Policy list. Option B has the correct Local Policy location but applies the QoS map to the service-side interface; service-side interfaces face the LAN or service VPN, so attaching the WAN QoS map there does not schedule traffic toward the transport. Option D also gets the WAN interface right but still fails because it uses the Centralized Policy section for the list. Therefore only A combines the correct Local Policy list location with the correct WAN interface application point.

Community Comment Notes

The commenters overwhelmingly chose A, and their reasoning aligns with the official workflow. Networkchamp87 reasoned that it "would be a local policy so that rules out C,D" and that QoS is applied on the WAN interface because that is where the bottleneck is. Gycu summarized it as "QOS is created in Local policies and needs to be applied on the WAN interface," while Raynecore quoted the vManage path: "select Lists under Localized Policy" and "Select a required queue from the Queue drop-down." mikidvd51 dissented by asking why WAN and why Local, arguing that WAN traffic is IPsec-encrypted and that a new app may span many routers. The exam doctrine still favors A: SD-WAN QoS scheduling happens on the WAN-side egress before encryption, and the class-to-queue mapping is platform-specific, so it remains a Local Policy operation even when the application is deployed fabric-wide. hamidreza0010 also confirmed A, and Stanleymahamadi's bare "Correct « D »" has no supporting rationale that overrides the documented Local Policy/WAN interface workflow.

Exam Strategy

In vManage QoS scenarios, first separate per-device hardware settings (Local Policy: class-to-queue, QoS map) from fabric-wide intent (Centralized Policy: topology, app-route). Then ask which interface faces the WAN transport, usually VPN0/WAN, because that is where egress scheduling and the QoS map are attached.

Frequently Asked Questions

Why is the class-to-queue mapping done in Local Policy instead of Centralized Policy?

Queue mapping ties a forwarding class to a platform-specific hardware queue, so it is a per-device Local Policy list; Centralized Policy is for fabric-wide intent like topology and app-route.

Why is the QoS map applied to the WAN interface rather than the service-side interface?

The WAN interface (VPN0) is the transport egress where congestion and scheduling occur, so SD-WAN QoS maps are attached there; service-side QoS is LAN-facing and does not protect WAN transport.

More 300-415 FAQ →

Community Votes

100%

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

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 6

Networkchamp87 👍 3 Answered A

Logically approaching this answer; -It would be a local policy so that rules out C,D -You would apply the QoS on the WAN interface 99% of the time in any network as that where the bottle neck will be.
Gycu 👍 2 Answered A

A is correct. QOS is created in Local policies and needs to be applied on the WAN interface.
Raynecore 👍 1 Answered A

Map Each Forwarding Class to an Output Queue From the Cisco SD-WAN Manager menu, choose Configuration > Policies. From the Custom Options drop-down, select Lists under Localized Policy. Select the Class Map from the list types. Click the New Class List. The Class List pop-up page is displayed. Enter a name for the class. Select a required queue from the Queue drop-down list. Click Save. Repeat the last three steps to add more class lists as required. https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/qos/ios-xe-17/qos-book-xe/forwarding-qos.html#Cisco_Concept.dita_aa3e0d07-462e-463f-8f45-681f38f61ab0
mikidvd51 👍 1 Answered C

Why A ? - Why on WAN interface? WAN interface (VPN0) traffic is being IPsec encrypted. Only QOS overall traffic shaping can be applied out there. - Why Local policy? When app is being deployed on wide client network. Not to one router only.
hamidreza0010 👍 1

A is the correct answer. The policy must be applied to the WAN interface, and it should be a local policy, not a centralized policy.

Show 1 more comment

Stanleymahamadi 👍 1

Correct « D »

Reader comments & corrections

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

Practice All 300-415 Questions

Access 120 questions with complete answers and detailed explanations.

View Full 300-415 Practice Test →

← Back to 300-415 Study Guide