Free 350-801 Practice Test Questions 2026

EF AND AF41

Explanation
Cisco Auto-QoS uses Differentiated Services Code Point (DSCP) markings to classify voice and video traffic so that switches can apply appropriate queuing and forwarding policies. For interactive voice, Cisco uses Expedited Forwarding (EF), while interactive video uses Assured Forwarding 41 (AF41). These markings help minimize delay and packet loss for real-time communications. Cisco's AutoQoS documentation explicitly identifies EF for interactive voice and AF41 for interactive video.

Correct Option:

A. EF AND AF41

- EF (DSCP 46): Used for interactive voice traffic. It receives priority treatment to minimize latency, jitter, and packet loss.

- AF41 (DSCP 34): Used for interactive video, including video conferencing. It receives preferential forwarding treatment while allowing bandwidth to be shared with other traffic classes.

Both values are standard Cisco QoS markings for these traffic types.

Incorrect Options

- B. EF AND AF21:
EF is correct for voice, but AF21 is generally associated with transactional or interactive data traffic, not interactive video.

- C. EF AND CS3:
EF is correct for voice, but CS3 is commonly used for telephony signaling rather than interactive video.

- D. EF AND CS6:
EF is correct for voice, but CS6 is associated with network control and routing traffic, not interactive video.

Reference
- Cisco AutoQoS Configuration Guide — identifies the DSCP values used for interactive voice and video.

Option A

Explanation
This question refers to DNS SRV records and how their Priority and Weight fields determine which server a client contacts first. The exhibit is needed to compare the existing SRV records for the three servers.

The matching version of this Cisco 350-801 practice question asks how to ensure that server1.sample.com is always contacted first. Its published answer is D (Priority = 5, Weight = 70), rather than A.

Correct Option:

A — as provided in your question
You have marked A as the answer, but I cannot verify that it is correct without seeing the actual exhibit and its current SRV record values.

The key DNS SRV rules are:

- Priority: Lower numerical values are preferred. A client tries servers with the lowest priority value first.

- Weight: When multiple records have the same priority, weight influences the probability of selecting each server. A higher weight gives that server a greater share of selections; it does not guarantee that it is always contacted first.

Therefore, to guarantee that server1.sample.com is preferred over the other two servers, configure it with a lower priority value than both alternatives.

Incorrect Options

- B. Priority = 10, Weight = 5:
Does not guarantee first contact if another server has a lower priority.

- C. Priority = 10, Weight = 10:
Equal priority and weight do not guarantee that this server is contacted first.

- D. Priority = 5, Weight = 70:
Would be preferred over servers with priority 10, assuming those are the other records. This is the published answer to the matching question, but the exhibit should be checked to confirm.

Reference
- RFC 2782 — A DNS RR for specifying the location of services (DNS SRV)

SIP trunk

route pattern

Explanation
In Cisco Unified Communications Manager (CUCM), on-net/off-net call classification identifies calls as internal to the organization (OnNet) or external (OffNet). This classification is configured using the Call Classification setting on trunks and route patterns. Cisco documentation confirms that SIP trunks can be classified as OnNet or OffNet and that route patterns can independently classify outgoing calls.

Correct Options: A and D

A. SIP trunk
A SIP trunk connects CUCM to another SIP-based system or call-control domain. Its Call Classification setting can identify incoming calls as OnNet or OffNet. This helps CUCM apply the appropriate call-handling and transfer restrictions.

D. Route pattern
A route pattern matches dialed digits and determines how CUCM routes outgoing calls. Its Call Classification field can be set to OnNet or OffNet. For example, a route pattern used to reach the public telephone network (PSTN) can be classified as OffNet.

Incorrect Options

- B. CTI route point:
Provides a virtual device endpoint for applications using Computer Telephony Integration. It is not a required component for configuring on-net/off-net classification.

- C. Route group:
Groups gateways or trunks to provide routing paths. It is part of call routing, but call classification is configured on the trunk or route pattern.

- E. SIP route patterns:
This is not the relevant CUCM configuration component for this feature. The required component is the standard Route Pattern, which includes the Call Classification setting.

Reference
- Cisco CUCM Feature Configuration Guide — External Call Transfer Restrictions

When using media flow-through, the call signaling and media are passed through the
Cisco Unified Border Element

When using media flow-around. the call signaling goes through the Cisco Unified Border
Element, but media * not passed through it

Explanation
Cisco Unified Border Element (CUBE) supports two media handling modes: media flow-through and media flow-around. The main difference is whether the Real-Time Transport Protocol (RTP) media stream passes through CUBE or travels directly between the endpoints.

In both modes, SIP call signaling passes through CUBE. The difference is the media path, which affects bandwidth usage, network topology, and media anchoring.

Correct Options: A and C

- A. Media flow-through:
Both call signaling and media packets pass through CUBE. CUBE terminates and re-originates the RTP media stream, enabling functions such as media address hiding and transcoding when supported.

- C. Media flow-around:
SIP signaling passes through CUBE, but RTP media flows directly between the endpoints, bypassing CUBE. This can reduce CUBE's media-processing load.

Incorrect Options

- B. Incorrect because it describes flow-around, not flow-through.

- D. Incorrect because signaling still passes through CUBE in flow-around mode.

- E. Incorrect because it says media does not pass through CUBE during flow-through; that is the opposite of how flow-through works.

Reference
- Cisco Unified Border Element Configuration Guide — Media Path

For each device pod. configure a route group to use a» a Local Route Group for that
device pool

Explanation
The Local Route Group (LRG) feature in Cisco Unified Communications Manager (CUCM) allows administrators to use a common route pattern configuration across multiple sites while selecting the appropriate local gateway based on the calling device's device pool.

Instead of creating separate route patterns for each location, CUCM resolves the Local Route Group through the device pool associated with the calling device. This simplifies multi-site call routing and reduces configuration duplication.

Correct Option:

D. For each device pod, configure a route group to use as a Local Route Group for that device pool
The intended configuration is to associate a route group with the Local Route Group setting in each device pool. Each site can then use its own local gateway or trunk while sharing the same route patterns.

For example:

- Headquarters device pool: Local Route Group points to the headquarters gateway route group.

- Branch device pool: Local Route Group points to the branch gateway route group.

When a user places an external call, CUCM uses the calling device's device pool to determine which route group to use.

Incorrect Options

- A. Route lists organize route groups for call routing, but configuring a route group for each route list does not enable the Local Route Group feature.

- B. Route patterns can use the Local Route Group as their destination, but this alone does not configure the site-specific route group mapping.

- C. Route groups do not have a checkbox that enables the Local Route Group feature for individual route groups. The association is made through the device pool configuration.

Reference
- Cisco Unified Communications Manager Feature Configuration Guide

\+.! Route pattern

Explanation
Cisco Unified Communications Manager (CUCM) supports E.164 numbering, an international telephone numbering format in which numbers begin with a plus sign (+) followed by the country code and subscriber number.

To route calls using E.164 numbers, CUCM can use a route pattern that matches the leading plus sign and the remaining digits. The backslash (\) is used to escape the plus sign in the route-pattern expression so it is treated as a literal character rather than a special symbol.

Correct Option:

B. \+.! Route Pattern
The \+.! route pattern matches dialed numbers beginning with a literal +, followed by any character (.) and any remaining sequence (!). - \+ — matches the literal plus sign.

- . — matches one digit.

- ! — matches any additional sequence of digits.

This pattern allows CUCM to route calls dialed in E.164 format without requiring a separate route pattern for every international number.

Incorrect Options

- A. /+.! Route Pattern:
The forward slash does not escape the plus sign in the required CUCM route-pattern syntax.

- C. \+.! Translation Pattern:
A translation pattern modifies or transforms a dialed number; it does not directly select the outgoing route in the same way a route pattern does.

- D. \+1.[2-9]XX[2-9]XXXXXXX Called Party Transformation Pattern:
This is a more specific number-transformation expression for North American numbering, not a general E.164 routing pattern.

Reference:
- Cisco Unified Communications Manager Feature Configuration Guide

Option B

Explanation
This question tests bandwidth management on Cisco Unified Border Element (CUBE). The engineer must support five concurrent outbound voice calls over a link with only 160 kbps available while preserving voice quality.

The key is to choose a bandwidth-efficient codec and configure CUBE's call admission control (CAC) or bandwidth limits appropriately. Codec selection determines the media bandwidth required per call, including RTP, UDP, IP, and Layer 2 overhead. The total must fit within the link's available capacity.

Correct Option:

B. Configure codec ilbc mode 20

The relevant dial-peer configuration includes:

The iLBC codec at 20 ms packetization uses approximately 31 kbps per call over IPv4, including RTP, UDP, and IP headers. Five calls therefore require approximately \(5 \times 31 = 155\) kbps, fitting within the nominal 160-kbps budget before additional Ethernet overhead. This is why iLBC is the intended answer among the listed choices.

Incorrect Options

- A. No explicit codec:
Without a codec restriction, the negotiated codec may require more bandwidth than the link can support for five simultaneous calls. The configuration does not explicitly optimize codec selection for the constrained link.

- C. codec aacld:
AAC-LD is designed for high-quality, low-delay audio applications, but it is not the intended bandwidth-efficient codec for this scenario. Its bandwidth depends on the negotiated media parameters.

- D. codec mp4a-latm:
This identifies an AAC transport format, not the intended iLBC voice configuration. It does not provide the expected low-bandwidth voice solution for this question.

Reference
- Cisco Unified Border Element — Codec Configuration

_cuplogin._tcp.cisco.com pointing to a record of IM&P

_cisco-uds._tcp.cisco.com pointing to a record of Cisco Unified CM

Explanation
For on-premises Cisco Jabber Service Discovery, DNS SRV records allow Jabber clients to locate the required Cisco Unified Communications services automatically. The two records in this question are _cuplogin._tcp for Cisco Unified Presence/IM and Presence and _cisco-uds._tcp for Cisco Unified Communications Manager (CUCM). SRV records point to hostnames that have corresponding DNS address records; they do not point directly to IP addresses.

Correct Option

A. _cuplogin._tcp.cisco.com pointing to a record of IM&P
This SRV record helps Jabber locate the Cisco Unified Presence or IM and Presence server. The target should be the server's fully qualified domain name (FQDN), which is resolved separately through DNS—not the server's IP address entered directly in the SRV record.

B. _cisco-uds._tcp.cisco.com pointing to a record of Cisco Unified CM
This SRV record allows Jabber to discover Cisco Unified Communications Manager (CUCM), retrieve service profiles, and identify the appropriate services for the user. For on-premises deployments, Cisco documents _cisco-uds._tcp and _cuplogin._tcp as relevant internal DNS service-discovery records.

Incorrect Options

- C. Incorrect because _cuplogin uses _tcp, not _tls, and the SRV record should target a hostname rather than an IP address.

- D. Incorrect because _cisco-uds uses _tcp, not _tls, and its SRV target should be a hostname.

- E. Incorrect because _xmpp._tls is not one of the two required service-discovery records in this question.

Reference
- Cisco, Jabber DNS Configuration Guide — Service (SRV) Records

RSVP-enabled locations

location-based CAC

Explanation
Call Admission Control (CAC) in Cisco Unified Communications Manager (CUCM) prevents voice and video calls from consuming more WAN bandwidth than is available. In full-mesh or complex network topologies, CUCM supports two relevant approaches: location-based CAC and RSVP-enabled locations. Location-based CAC tracks configured bandwidth between locations, while RSVP-based CAC uses resource reservations to account for network resources along the call path.

Correct Options

B. RSVP-enabled locations
RSVP-enabled locations provide topology-aware CAC. CUCM works with RSVP agents in the network to request and maintain bandwidth reservations for calls. This approach is useful in full-mesh and other complex topologies, including networks with multiple paths or links, because it can account for available resources along the route rather than relying only on static bandwidth accounting.

C. Location-based CAC
Location-based CAC assigns endpoints to configured locations and tracks bandwidth available for calls between them. Administrators configure bandwidth limits for locations, and CUCM uses those limits when admitting calls. Although it is less topology-aware than RSVP, it remains a supported CAC approach and can be used in full-mesh deployments when the network design and bandwidth assumptions permit it.

Incorrect Options

- A. Device Pool:
A device pool groups common CUCM device settings, such as region, date/time group, and calling search space. It can associate devices with configuration that influences call handling, but it is not itself a CAC mechanism.

- D. Audio Codec Preference List:
Codec preference lists determine the preferred codecs for audio or video negotiation. They can influence bandwidth consumption, but they do not perform CAC or reserve WAN bandwidth.

- E. Physical location:
Physical location describes where devices or network resources are situated. CUCM implements location-based CAC through configured logical locations and bandwidth settings, not through a standalone CAC method called “physical location.”

Reference
- Cisco CUCM System Configuration Guide — Call Admission Control Overview

Set service parameter 'Block OffNet to OffNet Transfer' to False

Explanation
The question asks for the first step in implementing cluster-wide toll-fraud prevention for incoming calls in Cisco Unified Communications Manager (CUCM). The supplied answer is A, which matches an online version of this exam question. However, Cisco's official documentation states that the service parameter Block OffNet to OffNet Transfer must be set to True to block transfers between two external destinations. Therefore, the supplied answer appears inconsistent with the documented behavior of the parameter.

Correct Option

A. Set service parameter Block OffNet to OffNet Transfer to False — expected exam answer, but technically questionable.
The exam answer key identifies A as the first step. False is the default value and permits transfers between external (OffNet) devices. If the objective is to prevent toll fraud by blocking external-to-external call transfers, Cisco's documented setting is True, not False.

Incorrect Options

- B. Configure blocking for inbound calls based on caller ID. This is not the initial step for the documented OffNet-to-OffNet transfer restriction feature.

- C. Set System Remote Access Blocked Numbers to True. This is not the service parameter Cisco documents for restricting external-to-external call transfers.

- D. Set Block OffNet to OffNet Transfer to True. This is the technically correct setting to block external-to-external transfers, even though the supplied exam key marks A as correct.

Reference
- Cisco, External Call Transfer Restrictions — CUCM Release 15

The transcoder resource Is missing.

Explanation

The correct answer is A. The transcoder resource is missing.

In Cisco Unified Communications Manager (CUCM), an Ad Hoc conference may fail when the conference bridge and a participant use incompatible audio codecs. For example, if the conference bridge supports G.711 while the remote phone supports only G.729, CUCM requires a transcoder to convert between the codecs. Without an available and properly configured transcoder, the phone may display “Cannot Complete Conference Call.”

Correct Option

A. The transcoder resource is missing.
A transcoder converts media between different codecs, enabling participants with incompatible codec capabilities to join the same conference. In this scenario, the transcoder allows the G.729 remote phone to communicate with a conference bridge using G.711. The transcoder must be configured, registered, and available to CUCM through the appropriate media resource configuration.

Incorrect Options

- B. The remote phone does not have the conference feature assigned.
This could cause conference problems in a different scenario, but it does not explain the codec incompatibility described in the intended question.

- C. A software conference bridge is not assigned.
A software conference bridge may be used for Ad Hoc conferencing, but assigning one alone does not resolve a codec mismatch between G.711 and G.729.

- D. A Media Termination Point is missing.
An MTP provides media termination and interworking functions for certain call scenarios. It is not the appropriate resource to solve a codec mismatch; a transcoder is required.

Reference
- Cisco, Troubleshooting Guide for Cisco Unified Communications Manager — Services Issues

The voice packets are classified by the phone, and the classification is accepted.

Explanation
The correct answer is B. The voice packets are classified by the phone, and the classification is accepted.

The Cisco 8845 IP Phone marks its voice traffic with Quality of Service (QoS) values, typically DSCP EF (46) for voice media and appropriate Layer 2 CoS values. At the QoS trust boundary, the access-layer switch trusts these markings when the switch port is configured to trust the phone. This preserves the phone's classification so voice traffic receives appropriate priority across the network.

Correct Option

B. The voice packets are classified by the phone, and the classification is accepted.
Cisco IP phones can mark voice packets before they reach the access switch. When the switch is configured to trust the phone's QoS markings, it accepts the classification rather than re-marking the traffic. Cisco documents that the 8845 supports Layer 3 QoS marking, so trusting DSCP is an appropriate configuration when the network design permits it.

Incorrect Options

- A. The voice packets are not trusted, and the access layer switch reclassifies the packets. This describes an untrusted endpoint or a switch port configured not to trust the phone's markings.

- C. The phone and access layer switch negotiate the classification of packets. CDP can help the switch identify a Cisco IP phone and apply trusted-boundary behavior, but the phone and switch do not negotiate each packet's QoS classification.

- D. Cisco UCM determines how the voice packets are classified. CUCM manages call control and device configuration, but packet-level QoS markings are applied by the endpoint and handled by network devices.

Reference
- Cisco, Solved: 8845 Video Phone Auto QoS — Cisco Community