350-401 · topic practice
Practise ENCOR 350-401 Rest Apis And Data Models practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
Rest Apis And Data Models questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
Device hostname, vendor, model, OS version, serial number
Interface name, description, IP address, status, speed
BGP neighbor IP, remote AS, state, uptime
LLDP neighbor device ID, port ID, platform
Power supply, fan, temperature status
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
Retrieve running configuration and state data
Retrieve configuration from a specific datastore
Modify the target configuration datastore
Confirm a candidate configuration as the new running config
Prevent other NETCONF sessions from altering a datastore
Trap 1: The destination session on the central switch is configured with…
The destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.
Trap 2: The source sessions on the remote switches are configured with…
A valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.
Trap 3: The RSPAN VLAN is not created as a remote SPAN VLAN; it must be…
Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.
The trunk ports between the switches do not have the RSPAN VLAN (999) in their allowed VLAN list.
The trunk ports between the switches do not have the RSPAN VLAN (999) in their allowed VLAN list. This is the root cause because RSPAN relies on a dedicated VLAN to carry mirrored traffic across the Layer 2 fabric. Even if the VLAN is active on each switch, an ISL or 802.1Q trunk will prune or drop any VLAN not explicitly permitted in its allowed list. Since the default allowed list typically includes only VLANs 1-1005, a higher VLAN such as 999 may be silently omitted. Without VLAN 999 allowed on every trunk in the path, the mirrored frames never reach the destination switch, so the analyzer sees no traffic.
The destination session on the central switch is configured with 'monitor session 2 destination remote vlan 999' instead of 'monitor session 2 destination interface Gi1/0/1'.
Why it fails: The destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.
The source sessions on the remote switches are configured with 'monitor session 1 source vlan 100' but the destination is not set to 'remote vlan 999'.
Why it fails: A valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.
The RSPAN VLAN is not created as a remote SPAN VLAN; it must be configured with 'remote-span' command.
Why it fails: Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.
Given the following SNMPv3 configuration on a Cisco IOS-XE router:
snmp-server group ADMIN v3 priv write ADMINVIEW snmp-server user admin ADMIN v3 auth sha cisco123 priv aes 128 cisco456 snmp-server view ADMINVIEW iso included
What is missing or incorrect in this configuration?
Trap 1: The SNMPv3 user 'admin' must also specify an engine ID for the…
In SNMPv3, the engine ID is used to identify the SNMP engine for key derivation, but the user configuration does not require an explicit engine ID. Cisco IOS automatically associates the user with the router's local engine ID when none is specified. An engine ID is only mandatory when creating a user for a remote engine (e.g., for proxy) or when matching a user to a non-default engine. Therefore, the statement that 'admin' must specify an engine ID is incorrect.
Trap 2: The privacy password 'cisco456' must be at least 8 characters long.
Cisco IOS SNMPv3 does not enforce a minimum password length for the privacy (encryption) password; it accepts passwords of any length, including short ones. Although security best practices recommend a minimum of eight characters to prevent brute-force attacks, there is no such hard requirement in the CLI. The router will not reject 'cisco456' on the basis of length alone, so the statement is false. Note that some Cisco documentation suggests a minimum of 8 for stronger security, but it is not enforced.
Trap 3: The group 'ADMIN' must be configured with a read view to allow SNMP…
Incorrect. A read view is not required for this configuration. The group 'ADMIN' is configured with a write view only, which is sufficient for SNMP set operations. If SNMP get operations are needed, a read view would be necessary, but it is not a mandatory missing piece in the current setup.
The SNMPv3 user 'admin' must also specify an engine ID for the router.
Why it fails: In SNMPv3, the engine ID is used to identify the SNMP engine for key derivation, but the user configuration does not require an explicit engine ID. Cisco IOS automatically associates the user with the router's local engine ID when none is specified. An engine ID is only mandatory when creating a user for a remote engine (e.g., for proxy) or when matching a user to a non-default engine. Therefore, the statement that 'admin' must specify an engine ID is incorrect.
The view 'ADMINVIEW' includes the entire ISO tree, which might be too permissive for a restricted write view.
The view command 'iso included' in Cisco IOS SNMP configuration includes the entire ISO OID subtree (1.3.6.1), which covers all MIB objects accessible via SNMP. For a write view intended to be restricted, this is overly permissive because it grants write access to virtually any managed object, including critical system parameters. This defeats the purpose of VACM (View-Based Access Control Model) restriction, making it a security flaw. Hence, the configuration should use a more specific subtree, such as 'system' or 'interfaces', to limit the write scope.
The privacy password 'cisco456' must be at least 8 characters long.
Why it fails: Cisco IOS SNMPv3 does not enforce a minimum password length for the privacy (encryption) password; it accepts passwords of any length, including short ones. Although security best practices recommend a minimum of eight characters to prevent brute-force attacks, there is no such hard requirement in the CLI. The router will not reject 'cisco456' on the basis of length alone, so the statement is false. Note that some Cisco documentation suggests a minimum of 8 for stronger security, but it is not enforced.
The group 'ADMIN' must be configured with a read view to allow SNMP get operations.
Why it fails: Incorrect. A read view is not required for this configuration. The group 'ADMIN' is configured with a write view only, which is sufficient for SNMP set operations. If SNMP get operations are needed, a read view would be necessary, but it is not a mandatory missing piece in the current setup.
Trap 1: The voice class should use priority instead of bandwidth
Replacing `bandwidth` with `priority` for the voice class will not fix the underlying allocation problem. `priority` provides strict priority queueing for delay-sensitive traffic, but it still uses the interface `bandwidth` value to compute the policed rate when the `priority percent` keyword is used. Moreover, strict priority can starve other classes if traffic exceeds the priority policer, whereas the issue described is about incorrect absolute bandwidth reservation due to a wrong interface reference—not about latency or priority handling.
Trap 2: The video class should use bandwidth remaining percent
Moving the video class to `bandwidth remaining percent` would only change how the unused bandwidth is distributed after all classes receive their guaranteed minimums. It does not alter the absolute amount of bandwidth reserved for the voice class, which is incorrectly based on the default interface bandwidth. The voice class's `bandwidth percent` is still computed against the wrong reference value, so video's allocation method has no bearing on the voice under-allocation. The proper fix is to correct the interface bandwidth, not to reallocate leftover bandwidth.
Trap 3: The policy map is applied in the input direction
Applying the policy map in the input direction is unsupported for CBWFQ bandwidth guarantees; on Cisco IOS, the `bandwidth` and `priority` commands are only honored in the output direction. For ingress traffic, only policing (e.g., `police`) is available—bandwidth reservation and queuing are egress-only features. Even if the policy were applied outbound, the voice under-allocation would persist because the interface bandwidth reference is still incorrect. Additionally, the question describes a misallocation, not a directional limitation, so the answer must address the root cause: the missing `bandwidth 50000` statement.
The interface bandwidth command is not set to 50000 kbps
The root cause is that CBWFQ's percent-based bandwidth commands (bandwidth percent, priority percent) are calculated against the interface `bandwidth` setting, not the physical line rate. If an Ethernet interface retains its default bandwidth of 1000000 kbps (1 Gbps) while the actual WAN circuit is 50 Mbps, a voice class configured with `bandwidth percent 10` would reserve 100000 kbps instead of 5000 kbps. Without `bandwidth 50000` under the interface, the percentages do not map to the real link speed, so the voice class appears under-allocated even though the configuration is logically correct.
The voice class should use priority instead of bandwidth
Why it fails: Replacing `bandwidth` with `priority` for the voice class will not fix the underlying allocation problem. `priority` provides strict priority queueing for delay-sensitive traffic, but it still uses the interface `bandwidth` value to compute the policed rate when the `priority percent` keyword is used. Moreover, strict priority can starve other classes if traffic exceeds the priority policer, whereas the issue described is about incorrect absolute bandwidth reservation due to a wrong interface reference—not about latency or priority handling.
The video class should use bandwidth remaining percent
Why it fails: Moving the video class to `bandwidth remaining percent` would only change how the unused bandwidth is distributed after all classes receive their guaranteed minimums. It does not alter the absolute amount of bandwidth reserved for the voice class, which is incorrectly based on the default interface bandwidth. The voice class's `bandwidth percent` is still computed against the wrong reference value, so video's allocation method has no bearing on the voice under-allocation. The proper fix is to correct the interface bandwidth, not to reallocate leftover bandwidth.
The policy map is applied in the input direction
Why it fails: Applying the policy map in the input direction is unsupported for CBWFQ bandwidth guarantees; on Cisco IOS, the `bandwidth` and `priority` commands are only honored in the output direction. For ingress traffic, only policing (e.g., `police`) is available—bandwidth reservation and queuing are egress-only features. Even if the policy were applied outbound, the voice under-allocation would persist because the interface bandwidth reference is still incorrect. Additionally, the question describes a misallocation, not a directional limitation, so the answer must address the root cause: the missing `bandwidth 50000` statement.
Trap 1: Change the video traffic marking to DSCP AF41 and rely on…
This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Trap 2: Apply a service policy that uses a priority queue for voice only
Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Trap 3: Increase the number of queues to eight
Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
Modify the CoS-to-queue mapping using the 'mls qos srr-queue output cos-map' command
This command is correct because on Catalyst switches the default queue assignment for output traffic is based on the CoS value in the 802.1Q header. By modifying the CoS-to-queue map, you can explicitly assign voice (typically CoS 5) to a strict-priority queue and video (e.g., CoS 4) to a separate standard queue, thereby preventing inter-class contention. The command takes precedence over any default mapping and gives the engineer deterministic control over which hardware queue each marked packet uses.
Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping
Why it fails: This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Apply a service policy that uses a priority queue for voice only
Why it fails: Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Increase the number of queues to eight
Why it fails: Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
Drag or tap steps into the slots.
Consider this VLAN configuration on a Cisco switch:
vlan 10
name Sales
vlan 20
name Engineering
interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20
What is missing if the switch needs to carry VLAN 30 traffic on this trunk?
Trap 1: The trunk must be configured as an access port for VLAN 30.
Configuring the interface as an access port forces it to carry exactly one untagged VLAN, typically the native VLAN, and it strips 802.1Q tags from all frames. That would break the fabric's need to transport multiple VLANs with tags intact, so VLAN 30 could not be forwarded across the link alongside other VLANs. An access port cannot serve as a multi-VLAN trunk in SD-Access, and it would also disrupt the VXLAN/VLAN mapping at the edge.
Trap 2: The native VLAN must be changed to VLAN 30.
Changing the native VLAN to VLAN 30 only alters which VLAN is carried untagged on the trunk; it does not add VLAN 30 to the allowed list nor make it available for tagged traffic. Additionally, native VLAN mismatch can trigger CDP errors and spanning-tree inconsistences, but even a perfectly matched native VLAN does not permit other VLANs to traverse the link. The correct fix is to create VLAN 30 and add it to the allowed list, not to shift the native VLAN.
Trap 3: The switchport mode must be changed to dynamic desirable.
Switching the trunk mode to dynamic desirable invokes DTP to negotiate the link mode, but DTP does not influence which VLANs are permitted on the trunk or what exists in the VLAN database. The interface is already operating as a trunk, so the problem is not negotiation but the absence of VLAN 30 from the allowed list and local VLAN database. In fact, dynamic desirable can cause the link to become an access port if the peer is set to dynamic auto or does not respond, making the issue worse.
VLAN 30 must be created and added to the allowed VLAN list on the trunk.
On an 802.1Q trunk, each VLAN must first exist in the switch's local VLAN database and then be explicitly included in the allowed VLAN list on the trunk interface. Without both steps, the switch filters frames for VLAN 30, even if the VLAN is defined elsewhere in the SD-Access fabric. The edge node must have a consistent local VLAN-to-SGT mapping, and traffic will be dropped in hardware if the VLAN is not present and permitted.
The trunk must be configured as an access port for VLAN 30.
Why it fails: Configuring the interface as an access port forces it to carry exactly one untagged VLAN, typically the native VLAN, and it strips 802.1Q tags from all frames. That would break the fabric's need to transport multiple VLANs with tags intact, so VLAN 30 could not be forwarded across the link alongside other VLANs. An access port cannot serve as a multi-VLAN trunk in SD-Access, and it would also disrupt the VXLAN/VLAN mapping at the edge.
The native VLAN must be changed to VLAN 30.
Why it fails: Changing the native VLAN to VLAN 30 only alters which VLAN is carried untagged on the trunk; it does not add VLAN 30 to the allowed list nor make it available for tagged traffic. Additionally, native VLAN mismatch can trigger CDP errors and spanning-tree inconsistences, but even a perfectly matched native VLAN does not permit other VLANs to traverse the link. The correct fix is to create VLAN 30 and add it to the allowed list, not to shift the native VLAN.
The switchport mode must be changed to dynamic desirable.
Why it fails: Switching the trunk mode to dynamic desirable invokes DTP to negotiate the link mode, but DTP does not influence which VLANs are permitted on the trunk or what exists in the VLAN database. The interface is already operating as a trunk, so the problem is not negotiation but the absence of VLAN 30 from the allowed list and local VLAN database. In fact, dynamic desirable can cause the link to become an access port if the peer is set to dynamic auto or does not respond, making the issue worse.
Trap 1: Class-based weighted fair queuing (CBWFQ).
CBWFQ is a class-based scheduling mechanism that allocates guaranteed bandwidth to each configured class using weighted fair queueing. However, it does not provide a strict-priority queue, so voice packets are treated like any other class and can experience queuing delay or be dropped when the interface is congested. While it ensures minimum bandwidth for voice, it cannot enforce the strict latency and zero-drop guarantee that real-time traffic requires.
Trap 2: Weighted random early detection (WRED).
Weighted random early detection (WRED) drops packets probabilistically before congestion occurs, which directly violates the requirement that voice traffic must never be dropped. WRED is tempting because it is designed to manage congestion by selectively discarding lower-priority packets, and it would be correct for a data-only class where controlled drops are acceptable to avoid tail-drop. However, for a loss-sensitive voice class, a strict priority queue (LLQ) is required to guarantee zero drops.
Trap 3: First-in, first-out (FIFO) queuing.
FIFO is the simplest queuing mechanism, where packets are transmitted in the exact order they arrive with no traffic classification or priority treatment. Under FIFO, voice traffic is not distinguished from any other traffic, so if the queue fills up due to bursty data traffic, voice packets will suffer the same tail-drop as other packets. This makes it completely unsuitable for real-time services that demand low latency and zero packet loss.
Class-based weighted fair queuing (CBWFQ).
Why it fails: CBWFQ is a class-based scheduling mechanism that allocates guaranteed bandwidth to each configured class using weighted fair queueing. However, it does not provide a strict-priority queue, so voice packets are treated like any other class and can experience queuing delay or be dropped when the interface is congested. While it ensures minimum bandwidth for voice, it cannot enforce the strict latency and zero-drop guarantee that real-time traffic requires.
Low-latency queuing (LLQ).
LLQ combines class-based weighted fair queueing with a strict priority queue, allowing voice traffic to be placed in a dedicated priority queue that is served before all other queues. This guarantees that voice packets are always served first, providing low latency and eliminating drops for voice traffic even during congestion. To prevent the priority queue from starving other classes, LLQ typically applies a policer to limit the amount of traffic that can use the priority queue.
Weighted random early detection (WRED).
Why it fails: Weighted random early detection (WRED) drops packets probabilistically before congestion occurs, which directly violates the requirement that voice traffic must never be dropped. WRED is tempting because it is designed to manage congestion by selectively discarding lower-priority packets, and it would be correct for a data-only class where controlled drops are acceptable to avoid tail-drop. However, for a loss-sensitive voice class, a strict priority queue (LLQ) is required to guarantee zero drops.
First-in, first-out (FIFO) queuing.
Why it fails: FIFO is the simplest queuing mechanism, where packets are transmitted in the exact order they arrive with no traffic classification or priority treatment. Under FIFO, voice traffic is not distinguished from any other traffic, so if the queue fills up due to bursty data traffic, voice packets will suffer the same tail-drop as other packets. This makes it completely unsuitable for real-time services that demand low latency and zero packet loss.
Drag or tap steps into the slots.
Trap 1: Configure a separate flow monitor for each customer interface and…
Creating a separate flow monitor per customer interface assumes each customer has its own interface, but the question states they share a single interface (e.g., an MPLS VPN), so there are no distinct per-customer interfaces to attach monitors to. Even if you tried to apply multiple monitors to the same interface, each monitor without a filter would capture identical traffic, and exporting to different collectors would double the export bandwidth while still not separating the flows. This approach adds operational complexity and does not solve the core problem of flow attribution on the shared link.
Trap 2: Use NetFlow v9 export with the 'match ipv4 source address' field…
NetFlow v9 export using only the source IP address as the identifying key fails when customers use overlapping private address space, such as RFC 1918 10.x addresses inside different VRFs. The collector would merge flows that share a source IP, making it impossible to tell which customer generated them, and the actual destination and port may also be identical. VRF or VLAN context is the only reliable way to disambiguate customers in a shared infrastructure; source IP alone is insufficient.
Trap 3: Enable SNMP interface polling to track per-customer traffic…
SNMP interface polling reads cumulative counters like ifInOctets and ifOutOctets for the entire shared interface every polling interval, so it provides only aggregate bandwidth utilization with no per-flow or per-customer visibility. NetFlow is specifically designed to record individual flows with timestamps, IP addresses, protocols, and ports, whereas SNMP cannot tell you which customer's TCP session contributed to the byte count. Moreover, polling at 5-minute intervals misses short-lived flows and provides no attribution on a multi-tenant link.
Define a custom flow record that includes the 'match ipv4 vlan' or 'match ipv4 vrf' field to identify each customer's traffic, and apply a single flow monitor on the shared interface.
A custom flow record built with Flexible NetFlow can reference the VRF name or VLAN tag alongside the standard 5-tuple, so flows from different customers sharing the same physical interface are tagged at the source router. Because the flow monitor is attached to the shared interface, it captures all traffic in a single pass, and the collector uses the VRF/VLAN key to separate per-customer statistics. This eliminates reliance on IP uniqueness and scales to many VPNs or VLANs without needing a separate monitor per tenant.
Configure a separate flow monitor for each customer interface and export to different collectors.
Why it fails: Creating a separate flow monitor per customer interface assumes each customer has its own interface, but the question states they share a single interface (e.g., an MPLS VPN), so there are no distinct per-customer interfaces to attach monitors to. Even if you tried to apply multiple monitors to the same interface, each monitor without a filter would capture identical traffic, and exporting to different collectors would double the export bandwidth while still not separating the flows. This approach adds operational complexity and does not solve the core problem of flow attribution on the shared link.
Use NetFlow v9 export with the 'match ipv4 source address' field only, and rely on the collector to separate by source IP.
Why it fails: NetFlow v9 export using only the source IP address as the identifying key fails when customers use overlapping private address space, such as RFC 1918 10.x addresses inside different VRFs. The collector would merge flows that share a source IP, making it impossible to tell which customer generated them, and the actual destination and port may also be identical. VRF or VLAN context is the only reliable way to disambiguate customers in a shared infrastructure; source IP alone is insufficient.
Enable SNMP interface polling to track per-customer traffic statistics.
Why it fails: SNMP interface polling reads cumulative counters like ifInOctets and ifOutOctets for the entire shared interface every polling interval, so it provides only aggregate bandwidth utilization with no per-flow or per-customer visibility. NetFlow is specifically designed to record individual flows with timestamps, IP addresses, protocols, and ports, whereas SNMP cannot tell you which customer's TCP session contributed to the byte count. Moreover, polling at 5-minute intervals misses short-lived flows and provides no attribution on a multi-tenant link.
Trap 1: The gRPC server is configured with the wrong port number.
The gRPC server being configured with the wrong port would prevent the collector from establishing a connection or receiving any data, but the scenario states the server is running, which implies the port is correctly configured. In practice, if the port were wrong, the collector would see connection failures or nothing at all distinct from a subscription problem. Since the server is up, this option cannot explain the issue.
Trap 2: The collector is not listening on the same IP address as configured…
If the collector were listening on a different IP than configured on the router, the router would send telemetry packets to an unresponsive address, resulting in no data delivery. However, the scenario explicitly states the collector is reachable, meaning the IP address matches and packets are successfully delivered. A reachable collector rules out IP address mismatch as the cause of zero data flow.
Trap 3: The telemetry data is encoded in GPB, but the collector expects…
Encoding format mismatch (GPB vs JSON) would not prevent telemetry data from being sent; it would only cause the collector to fail when parsing or decoding the received messages. The symptom here is that no data is sent at all, which points to a pre-streaming failure like a missing subscription. Thus, an encoding mismatch is a plausible parsing problem but not the reason for complete absence of telemetry traffic.
No telemetry subscription is configured on the router for the desired data paths.
In model-driven telemetry, a subscription is a required configuration construct that binds the desired YANG data paths (e.g., interfaces, CPU/memory stats) to a destination collector. Even if the gRPC server is operational and the collector is reachable, no telemetry data is streamed until a subscription is created and active on the router. This is the root cause because the symptom is a complete absence of data, not malformed or dropped data.
The gRPC server is configured with the wrong port number.
Why it fails: The gRPC server being configured with the wrong port would prevent the collector from establishing a connection or receiving any data, but the scenario states the server is running, which implies the port is correctly configured. In practice, if the port were wrong, the collector would see connection failures or nothing at all distinct from a subscription problem. Since the server is up, this option cannot explain the issue.
The collector is not listening on the same IP address as configured on the router.
Why it fails: If the collector were listening on a different IP than configured on the router, the router would send telemetry packets to an unresponsive address, resulting in no data delivery. However, the scenario explicitly states the collector is reachable, meaning the IP address matches and packets are successfully delivered. A reachable collector rules out IP address mismatch as the cause of zero data flow.
The telemetry data is encoded in GPB, but the collector expects JSON.
Why it fails: Encoding format mismatch (GPB vs JSON) would not prevent telemetry data from being sent; it would only cause the collector to fail when parsing or decoding the received messages. The symptom here is that no data is sent at all, which points to a pre-streaming failure like a missing subscription. Thus, an encoding mismatch is a plausible parsing problem but not the reason for complete absence of telemetry traffic.
Trap 1: vManage
vManage is the centralized management plane of the SD-WAN fabric, providing the GUI for configuration, monitoring, and analytics. It does not perform initial device authentication; rather, it relies on vBond to validate device certificates and introduce the device to the overlay. During onboarding, vManage is contacted only after vBond has established trust, making it a downstream consumer of vBond's authentication, not the authenticator itself.
Trap 2: vSmart
vSmart is the control plane component responsible for distributing OMP routes and enforcing centralized policy across the SD-WAN overlay. However, it cannot authenticate a new device because it has no prior trust relationship with the device's identity; vBond performs that initial authentication and then informs vSmart about the newly validated device. vSmart's role is to exchange routing information after the secure channel is established via vBond, so it is dependent on vBond's orchestration, not the initiator of it.
Trap 3: vEdge
vEdge is a data plane router that forwards user traffic at branch or campus sites, and it is itself a tenant of the overlay rather than a controller. It does not authenticate or orchestrate other devices; instead, it is the device that gets authenticated by vBond during its own onboarding process. The vEdge's function is to implement the policies and routes learned from vSmart, so its role is entirely separate from the authentication orchestration performed by vBond.
vManage
Why it fails: vManage is the centralized management plane of the SD-WAN fabric, providing the GUI for configuration, monitoring, and analytics. It does not perform initial device authentication; rather, it relies on vBond to validate device certificates and introduce the device to the overlay. During onboarding, vManage is contacted only after vBond has established trust, making it a downstream consumer of vBond's authentication, not the authenticator itself.
vSmart
Why it fails: vSmart is the control plane component responsible for distributing OMP routes and enforcing centralized policy across the SD-WAN overlay. However, it cannot authenticate a new device because it has no prior trust relationship with the device's identity; vBond performs that initial authentication and then informs vSmart about the newly validated device. vSmart's role is to exchange routing information after the secure channel is established via vBond, so it is dependent on vBond's orchestration, not the initiator of it.
vBond
vBond is the orchestrator and the first point of contact for any device attempting to join the SD-WAN overlay. It authenticates devices by verifying their serial numbers and certificates against the configured credentials, and then provides the authenticated device with the IP addresses of vManage and vSmart. This mutual authentication ensures that only trusted devices can participate, and without vBond, no device can complete the initial handshake to join the fabric.
vEdge
Why it fails: vEdge is a data plane router that forwards user traffic at branch or campus sites, and it is itself a tenant of the overlay rather than a controller. It does not authenticate or orchestrate other devices; instead, it is the device that gets authenticated by vBond during its own onboarding process. The vEdge's function is to implement the policies and routes learned from vSmart, so its role is entirely separate from the authentication orchestration performed by vBond.
Trap 1: VTP pruning has removed VLAN 10 from the trunk.
VTP pruning would remove VLAN 10 from the trunk's allowed list only when no active access port exists for that VLAN on the downstream switch, and this would be visible with show interface trunk. If VLAN 10 still appears in the allowed list on the trunk, pruning has not occurred; the failure is due to the VLAN not being defined in the VLAN database on one switch. VTP pruning cannot remove a VLAN from the database itself—it only controls which VLANs are permitted on specific trunk links.
Trap 2: The native VLAN is mismatched.
A native VLAN mismatch appears on an 802.1Q trunk when the two ends are configured with different untagged VLAN IDs. This condition triggers CDP error messages and can put the trunk into an inconsistent state, but it affects only untagged traffic on the native VLAN, not a tagged VLAN such as VLAN 10. Since the problem is specific to VLAN 10 and other VLANs are presumably passing, native VLAN mismatch is not a valid explanation.
Trap 3: Spanning Tree Protocol is blocking VLAN 10 on the trunk.
While STP can block a VLAN on a trunk in PVST+ or Rapid PVST+, it does so only when a loop or redundant path exists for that VLAN. A single trunk link without an alternative path is not placed in a blocking state for one VLAN, and the port would remain forwarding for all other VLANs. Additionally, STP blocking would not hide a missing VLAN database entry—it would still show VLAN 10 as defined but in a discarding state, which is not the situation described.
VLAN 10 is not created in the VLAN database on one of the switches.
VLAN 10 must exist in the local VLAN database on both switches before traffic can cross an 802.1Q trunk. If one switch lacks VLAN 10, that switch will not forward tagged frames for that VLAN, even though the trunk interface is administratively up and the VLAN is in the allowed list. The switch will not create the VLAN dynamically unless VTP is in server mode and advertises it, so the missing database entry is the root cause.
VTP pruning has removed VLAN 10 from the trunk.
Why it fails: VTP pruning would remove VLAN 10 from the trunk's allowed list only when no active access port exists for that VLAN on the downstream switch, and this would be visible with show interface trunk. If VLAN 10 still appears in the allowed list on the trunk, pruning has not occurred; the failure is due to the VLAN not being defined in the VLAN database on one switch. VTP pruning cannot remove a VLAN from the database itself—it only controls which VLANs are permitted on specific trunk links.
The native VLAN is mismatched.
Why it fails: A native VLAN mismatch appears on an 802.1Q trunk when the two ends are configured with different untagged VLAN IDs. This condition triggers CDP error messages and can put the trunk into an inconsistent state, but it affects only untagged traffic on the native VLAN, not a tagged VLAN such as VLAN 10. Since the problem is specific to VLAN 10 and other VLANs are presumably passing, native VLAN mismatch is not a valid explanation.
Spanning Tree Protocol is blocking VLAN 10 on the trunk.
Why it fails: While STP can block a VLAN on a trunk in PVST+ or Rapid PVST+, it does so only when a loop or redundant path exists for that VLAN. A single trunk link without an alternative path is not placed in a blocking state for one VLAN, and the port would remain forwarding for all other VLANs. Additionally, STP blocking would not hide a missing VLAN database entry—it would still show VLAN 10 as defined but in a discarding state, which is not the situation described.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Rest Apis And Data Models sessions
Every question in these sessions is drawn from the Rest Apis And Data Models domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Sharpen your 350-401 knowledge of Architecture.
Practise 350-401 questions linked to Virtualization.
Work through 350-401 questions on Infrastructure.
Sharpen your 350-401 knowledge of Network Assurance.
Security practice questions for 350-401.
Targeted 350-401 practice covering Automation.
Practise eBGP/iBGP peering, path attributes, route selection and BGP troubleshooting.
Practise OSPF area types, LSA types, neighbour states and multi-area design.
Practise EIGRP DUAL, metrics, stub routing and route redistribution.
Practise VLAN configuration, trunk negotiation and inter-VLAN routing.
Practise RSTP, MSTP, port roles and STP protection features.
Practise extended ACLs, CoPP rate-limiting and control-plane protection.
A free account saves results across sessions and highlights which topics need work.
Sign up free