Netflow practice questions

Drag and drop the following phases into the correct order to configure gRPC streaming telemetry subscription setup and then the NetFlow data path sequence.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: 1

This order incorrectly places the NetFlow export destination after the flow monitor has already been applied to the interface. A flow monitor in Flexible NetFlow must reference an exporter with a destination IP and port; applying the monitor before configuring the export destination means no records can be sent to a collector. Additionally, the gRPC telemetry subscription is set up after the monitoring features, whereas the correct sequence establishes the telemetry collector first to receive streamed data.

Trap 2: 1

The primary flaw is that gRPC telemetry subscription is saved for last, after NetFlow export destination and flow monitor configuration. Since the correct procedure starts with establishing the telemetry subscription to the collector, this option has the device attempting to create flow exporters before the telemetry receiver is even defined. By the time telemetry is configured, the NetFlow flow monitor is already active without a properly ordered streaming setup, leading to a mismatch between when data is collected and when collectors are ready.

Trap 3: 1

This sequence tries to apply the flow monitor to the interface before the flow monitor has been defined, which the Cisco IOS CLI will reject with a '% flow monitor does not exist' error. Although gRPC telemetry is placed before NetFlow export (partially matching the correct order), the fundamental define-then-apply rule for flow monitors is violated. The NetFlow export destination is also configured last, so even if the monitor existed, it would lack a destination to send records to.

A
1. Configure gRPC telemetry subscription 2. Configure NetFlow export destination 3. Define flow monitor 4. Apply flow monitor to interface
This order correctly follows the sequence: first set up the telemetry subscription to stream data, then configure NetFlow export to send flow records, define the flow monitor to specify what to collect, and finally apply it to the interface where traffic is monitored.
B
1. Define flow monitor 2. Apply flow monitor to interface 3. Configure gRPC telemetry subscription 4. Configure NetFlow export destination
Why wrong: This order incorrectly places the NetFlow export destination after the flow monitor has already been applied to the interface. A flow monitor in Flexible NetFlow must reference an exporter with a destination IP and port; applying the monitor before configuring the export destination means no records can be sent to a collector. Additionally, the gRPC telemetry subscription is set up after the monitoring features, whereas the correct sequence establishes the telemetry collector first to receive streamed data.
C
1. Configure NetFlow export destination 2. Define flow monitor 3. Apply flow monitor to interface 4. Configure gRPC telemetry subscription
Why wrong: The primary flaw is that gRPC telemetry subscription is saved for last, after NetFlow export destination and flow monitor configuration. Since the correct procedure starts with establishing the telemetry subscription to the collector, this option has the device attempting to create flow exporters before the telemetry receiver is even defined. By the time telemetry is configured, the NetFlow flow monitor is already active without a properly ordered streaming setup, leading to a mismatch between when data is collected and when collectors are ready.
D
1. Apply flow monitor to interface 2. Configure gRPC telemetry subscription 3. Define flow monitor 4. Configure NetFlow export destination
Why wrong: This sequence tries to apply the flow monitor to the interface before the flow monitor has been defined, which the Cisco IOS CLI will reject with a '% flow monitor does not exist' error. Although gRPC telemetry is placed before NetFlow export (partially matching the correct order), the fundamental define-then-apply rule for flow monitors is violated. The NetFlow export destination is also configured last, so even if the monitor existed, it would lack a destination to send records to.

Question 2hardmultiple choice

An administrator sees high interface utilization through SNMP graphs but wants to identify which conversations are responsible. Which addition best closes that visibility gap?

Trap 1: Another DHCP scope

A DHCP scope is a pool of IP addresses that a server hands out to clients; it controls address assignment, not traffic measurement. Adding another scope would only expand the number of leases available, and while it might indirectly change addressing, it would not reveal which applications or conversations fill the interface. The 'high utilization' observed via SNMP therefore remains an unexplained aggregate number, not a conversation detail.

Trap 2: A new STP priority

STP priority is a spanning-tree election value that determines which switch becomes the root and which redundant paths are placed in blocking state. Reconfiguring it can move traffic to a different physical path, but it offers zero visibility into existing flows. The administrator needs a flow-based telemetry source, not a topology-control parameter, to see the specific traffic causing high utilization.

Trap 3: A larger OSPF metric

OSPF metric (cost) is a routing parameter that influences shortest-path selection, not a tool for inspecting live traffic. Even with a larger metric on an interface, the administrator would only see route changes, never which source/destination pairs are consuming the interface's bandwidth. SNMP utilization counters are aggregate, so OSPF tuning cannot break down the utilization by conversation.

A
NetFlow
NetFlow (and similar flow export technologies) captures metadata for each IP conversation traversing the interface, including source/destination addresses, L4 ports, and byte counts. This allows the administrator to aggregate by host, application, or TCP/UDP port and immediately identify the top talkers driving the interface to high utilization. Unlike SNMP counters that show only aggregate usage, NetFlow correlates the utilization to specific flows.
B
Another DHCP scope
Why wrong: A DHCP scope is a pool of IP addresses that a server hands out to clients; it controls address assignment, not traffic measurement. Adding another scope would only expand the number of leases available, and while it might indirectly change addressing, it would not reveal which applications or conversations fill the interface. The 'high utilization' observed via SNMP therefore remains an unexplained aggregate number, not a conversation detail.
C
A new STP priority
Why wrong: STP priority is a spanning-tree election value that determines which switch becomes the root and which redundant paths are placed in blocking state. Reconfiguring it can move traffic to a different physical path, but it offers zero visibility into existing flows. The administrator needs a flow-based telemetry source, not a topology-control parameter, to see the specific traffic causing high utilization.
D
A larger OSPF metric
Why wrong: OSPF metric (cost) is a routing parameter that influences shortest-path selection, not a tool for inspecting live traffic. Even with a larger metric on an interface, the administrator would only see route changes, never which source/destination pairs are consuming the interface's bandwidth. SNMP utilization counters are aggregate, so OSPF tuning cannot break down the utilization by conversation.

Question 3hardScenario

You are connected to R1, a Cisco ISR 4331 router running IOS-XE. Your task is to enable SNMP v2c with community string 'public' (read-only) and 'private' (read-write), and configure SNMP v3 with a user 'admin' using SHA authentication (password 'Cisco123') and AES 128 encryption (password 'Cisco456'). Additionally, configure SNMP traps to be sent to a management server at 203.0.113.10 for both v2c and v3. Finally, enable NetFlow export to a collector at 203.0.113.20, using version 9. Verify your configuration using 'show snmp' and 'show ip cache flow'.

Exhibit

Current running-config of R1 (relevant sections):
!
hostname R1
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shut
!
interface GigabitEthernet0/1
 ip address 198.51.100.1 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 192.0.2.2
!
end

Trap 1: snmp-server community public snmp-server community…

This configuration is incorrect because it uses MD5 instead of SHA for SNMPv3 authentication and DES instead of AES 128 for encryption. Additionally, the community strings lack the RO and RW keywords, which are required to specify access levels.

Trap 2: snmp-server community public RO snmp-server community private…

This configuration fails because the SNMPv2c trap receiver at 203.0.113.10 is bound to the 'private' community string, which is the read-write (RW) community. The question explicitly requires a v2c trap host using the read-only (RO) community 'public' to match the monitoring station's read-only access. Sending traps with the RW community violates the least-privilege principle and would be rejected by a properly configured NMS that expects traps from the 'public' community. Additionally, specifying the v2c host with the wrong community string means the NMS may not authenticate the trap, so no alarms would be received.

Trap 3: snmp-server community public RO snmp-server community private…

The entire SNMP configuration is correct, including the v2c public trap host, v3 user 'admin' with SHA/AES-128, and the trap hosts, but NetFlow export is misconfigured by using version 5 instead of the required version 9. NetFlow version 5 does not support templates, so it cannot carry flexible field definitions or accommodate new flow record formats; version 9 is template-based and allows extensible, structured data export. The question explicitly mandates version 9 for the flow exporter, making version 5 an incorrect choice. Even though the destination 203.0.113.20 and port 2055 are correct, the wrong version breaks the expected flow data encoding and may be unreadable by the collector.

A
snmp-server community public RO snmp-server community private RW snmp-server user admin v3group v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
Correctly configures SNMP v2c communities with proper permissions, SNMP v3 user with the required group name (v3group), SHA authentication, and AES-128 encryption, enables traps for both versions with the correct target hosts, and sets NetFlow export to version 9.
B
snmp-server community public snmp-server community private snmp-server user admin v3 auth md5 Cisco123 priv des56 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
Why wrong: This configuration is incorrect because it uses MD5 instead of SHA for SNMPv3 authentication and DES instead of AES 128 for encryption. Additionally, the community strings lack the RO and RW keywords, which are required to specify access levels.
C
snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c private snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
Why wrong: This configuration fails because the SNMPv2c trap receiver at 203.0.113.10 is bound to the 'private' community string, which is the read-write (RW) community. The question explicitly requires a v2c trap host using the read-only (RO) community 'public' to match the monitoring station's read-only access. Sending traps with the RW community violates the least-privilege principle and would be rejected by a properly configured NMS that expects traps from the 'public' community. Additionally, specifying the v2c host with the wrong community string means the NMS may not authenticate the trap, so no alarms would be received.
D
snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 5
Why wrong: The entire SNMP configuration is correct, including the v2c public trap host, v3 user 'admin' with SHA/AES-128, and the trap hosts, but NetFlow export is misconfigured by using version 5 instead of the required version 9. NetFlow version 5 does not support templates, so it cannot carry flexible field definitions or accommodate new flow record formats; version 9 is template-based and allows extensible, structured data export. The question explicitly mandates version 9 for the flow exporter, making version 5 an incorrect choice. Even though the destination 203.0.113.20 and port 2055 are correct, the wrong version breaks the expected flow data encoding and may be unreadable by the collector.

Question 4hardScenario

You are connected to R1, a Cisco router running IOS-XE. Configure SNMP v2c with a read-only community string 'publicRW' (note: the string is intentionally misnamed for the task), and SNMP v3 with user 'admin' using MD5 authentication (password 'cisco123') and DES encryption (password 'cisco456'). Ensure SNMP traps for linkUp/linkDown are sent to the management server at 192.0.2.100. Additionally, configure NetFlow export to send version 9 flow records to 192.0.2.200 on UDP port 2055, and ensure that only inbound traffic on GigabitEthernet0/0 is monitored. Finally, verify your configuration using 'show snmp' and 'show ip cache flow'.

Exhibit

R1#show running-config | section snmp
snmp-server community publicRW RO
snmp-server location Datacenter
snmp-server contact admin@example.com
!
R1#show running-config | include ip flow
i
R1#show ip cache flow
No flow cache configured.

Trap 1: snmp-server community publicRW ro snmp-server user admin admin v3…

This configuration is missing the 'ip flow ingress' command on an interface, which is required to enable NetFlow data collection. Without it, no flow records will be exported, and 'show ip cache flow' will show no entries.

Trap 2: snmp-server community publicRW ro snmp-server user admin admin v3…

This configuration uses 'ip flow egress' instead of 'ip flow ingress'. While egress flow monitoring is valid, the task does not specify direction; however, ingress is more commonly used and the verification command 'show ip cache flow' expects ingress flows by default. More importantly, the task requires NetFlow export to work, and using egress may not capture the desired traffic.

Trap 3: snmp-server community publicRW ro snmp-server user admin admin v3…

This configuration uses 'ip flow monitor' which is a newer Flexible NetFlow command, but the task requires traditional NetFlow (version 9). The 'ip flow monitor' command requires a flow monitor configuration that is not provided, and it does not work with 'ip flow-export version 9' in the same way. The correct command for traditional NetFlow is 'ip flow ingress'.

A
snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9 interface GigabitEthernet0/0 ip flow ingress
This configuration correctly sets the SNMP v2c read-only community string 'publicRW', creates the SNMP v3 user with MD5 authentication and DES encryption, enables linkUp/linkDown traps, sends traps to 192.0.2.100 using v2c, configures NetFlow export to 192.0.2.200 on UDP 2055 with version 9, and applies NetFlow ingress on an interface. The 'show snmp' and 'show ip cache flow' commands will verify the settings.
B
snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9
Why wrong: This configuration is missing the 'ip flow ingress' command on an interface, which is required to enable NetFlow data collection. Without it, no flow records will be exported, and 'show ip cache flow' will show no entries.
C
snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9 interface GigabitEthernet0/0 ip flow egress
Why wrong: This configuration uses 'ip flow egress' instead of 'ip flow ingress'. While egress flow monitoring is valid, the task does not specify direction; however, ingress is more commonly used and the verification command 'show ip cache flow' expects ingress flows by default. More importantly, the task requires NetFlow export to work, and using egress may not capture the desired traffic.
D
snmp-server community publicRW ro snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456 snmp-server enable traps snmp linkdown linkup snmp-server host 192.0.2.100 traps version 2c publicRW ip flow-export destination 192.0.2.200 2055 ip flow-export version 9 interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input
Why wrong: This configuration uses 'ip flow monitor' which is a newer Flexible NetFlow command, but the task requires traditional NetFlow (version 9). The 'ip flow monitor' command requires a flow monitor configuration that is not provided, and it does not work with 'ip flow-export version 9' in the same way. The correct command for traditional NetFlow is 'ip flow ingress'.

Question 5hardmultiple choice

A network administrator notices that syslog messages from a core router are arriving at the syslog server with timestamps that are hours behind other devices. The router’s NetFlow exports also show incorrect start and end times for flows, making traffic analysis unreliable. The administrator verifies that all router interfaces are up and that the SNMP community strings on the router match the NMS.

Trap 1: The logging trap level is set to informational, so only…

Setting the logging trap level to informational actually allows all messages of severity informational and higher (levels 0–6) to be sent. Even if only emergencies were sent, their timestamps would still be accurate if the router’s clock is correct.

Trap 2: The SNMP v3 user’s privacy password is incorrect, causing the NMS…

SNMP v3 authentication and privacy settings control SNMP traps, which are separate from syslog messages. Syslog uses UDP port 514 and does not depend on SNMP v3 credentials. An SNMP v3 misconfiguration would affect trap delivery, not syslog timestamps or NetFlow exports.

Trap 3: The IP flow cache timeout is set too low, causing NetFlow…

The flow cache timeout determines how long an active flow is kept in the cache before it is exported. A lower timeout exports flows more frequently but does not alter the actual start or end times recorded in the flow records. The timestamps in NetFlow records come from the system clock, not the cache timer.

A
The logging trap level is set to informational, so only high-severity messages are sent with correct timestamps.
Why wrong: Setting the logging trap level to informational actually allows all messages of severity informational and higher (levels 0–6) to be sent. Even if only emergencies were sent, their timestamps would still be accurate if the router’s clock is correct.
B
The router’s NTP client is configured with an incorrect authentication key.
NTP can use authentication keys to verify server identity. If the client key does not match the server’s key, the router will not trust the time updates and will fail to synchronize. This leaves the router’s clock uncorrected, causing incorrect timestamps in syslog and NetFlow records.
C
The SNMP v3 user’s privacy password is incorrect, causing the NMS to reject syslog traps.
Why wrong: SNMP v3 authentication and privacy settings control SNMP traps, which are separate from syslog messages. Syslog uses UDP port 514 and does not depend on SNMP v3 credentials. An SNMP v3 misconfiguration would affect trap delivery, not syslog timestamps or NetFlow exports.
D
The IP flow cache timeout is set too low, causing NetFlow timestamps to appear skewed.
Why wrong: The flow cache timeout determines how long an active flow is kept in the cache before it is exported. A lower timeout exports flows more frequently but does not alter the actual start or end times recorded in the flow records. The timestamps in NetFlow records come from the system clock, not the cache timer.

Question 6mediummatching

Match each operations or assurance technology to its most accurate purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Centralized event and message reporting

Monitoring and management information exchange

Visibility into traffic flows and conversations

Clock synchronization for consistent timing

Trap 1: NetFlow - Device management; SNMP - Flow analysis; Syslog -…

It swaps the purposes of several technologies: NetFlow is not for device management, SNMP is not for flow analysis, Syslog is not for performance measurement, IP SLA is not for logging, SPAN is local not remote, and RSPAN is remote not local.

Trap 2: NetFlow - Logging; SNMP - Performance measurement; Syslog - Flow…

It misassigns each technology: NetFlow is not for logging, SNMP is not for performance measurement, Syslog is not for flow analysis, IP SLA is not for device management, SPAN is local not remote, and RSPAN is remote not local.

Trap 3: NetFlow - Performance measurement; SNMP - Logging; Syslog - Device…

It misassigns several technologies: NetFlow is not for performance measurement, SNMP is not for logging, Syslog is not for device management, and IP SLA is not for flow analysis. However, SPAN and RSPAN are correctly matched.

A
NetFlow - Flow analysis; SNMP - Device management; Syslog - Logging; IP SLA - Performance measurement; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring
Ly matches each technology to its primary purpose as defined in Cisco networking: NetFlow analyzes traffic flows, SNMP manages devices, Syslog provides logging, IP SLA measures performance, SPAN mirrors traffic locally, and RSPAN mirrors traffic remotely.
B
NetFlow - Device management; SNMP - Flow analysis; Syslog - Performance measurement; IP SLA - Logging; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring
Why wrong: It swaps the purposes of several technologies: NetFlow is not for device management, SNMP is not for flow analysis, Syslog is not for performance measurement, IP SLA is not for logging, SPAN is local not remote, and RSPAN is remote not local.
C
NetFlow - Logging; SNMP - Performance measurement; Syslog - Flow analysis; IP SLA - Device management; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring
Why wrong: It misassigns each technology: NetFlow is not for logging, SNMP is not for performance measurement, Syslog is not for flow analysis, IP SLA is not for device management, SPAN is local not remote, and RSPAN is remote not local.
D
NetFlow - Performance measurement; SNMP - Logging; Syslog - Device management; IP SLA - Flow analysis; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring
Why wrong: It misassigns several technologies: NetFlow is not for performance measurement, SNMP is not for logging, Syslog is not for device management, and IP SLA is not for flow analysis. However, SPAN and RSPAN are correctly matched.

Question 7hardmultiple choice

An operations team wants a monitoring platform to periodically read interface counters and CPU statistics from routers. Which technology is most closely associated with that requirement?

Trap 1: Syslog

Syslog is a logging protocol that transmits event messages and error notifications generated by network devices, such as configuration changes or interface flaps. Because it is push-based and asynchronous, it lacks the polling mechanism needed for routine metric collection and therefore does not suit a periodic monitoring platform.

Trap 2: NetFlow

NetFlow is designed to capture and export metadata about IP traffic flows, including source/destination addresses, ports, and protocol, to analyze network usage patterns. It does not provide general device health counters or periodic status polling, so it would be inappropriate for a monitoring platform focused on routine operational metrics.

Trap 3: Port security

Port security is a Layer 2 switch feature that restricts which MAC addresses can access a port to prevent unauthorized LAN access. It is a security enforcement mechanism, not a monitoring protocol or framework, and provides no facility for periodic collection of device statistics or health data.

A
SNMP
SNMP is the standard protocol for network monitoring platforms to periodically poll managed devices for operational data. It uses community strings or SNMPv3 credentials to read MIB objects such as interface counters, CPU load, and temperature, making it ideal for routine status collection and alerting on thresholds.
B
Syslog
Why wrong: Syslog is a logging protocol that transmits event messages and error notifications generated by network devices, such as configuration changes or interface flaps. Because it is push-based and asynchronous, it lacks the polling mechanism needed for routine metric collection and therefore does not suit a periodic monitoring platform.
C
NetFlow
Why wrong: NetFlow is designed to capture and export metadata about IP traffic flows, including source/destination addresses, ports, and protocol, to analyze network usage patterns. It does not provide general device health counters or periodic status polling, so it would be inappropriate for a monitoring platform focused on routine operational metrics.
D
Port security
Why wrong: Port security is a Layer 2 switch feature that restricts which MAC addresses can access a port to prevent unauthorized LAN access. It is a security enforcement mechanism, not a monitoring protocol or framework, and provides no facility for periodic collection of device statistics or health data.

Question 8hardmultiple choice

A network administrator wants to receive an immediate notification from a device when a significant event occurs, rather than polling the device repeatedly. Which SNMP feature is most associated with that requirement?

Trap 1: Syslog severity 7

Syslog severity 7 is a logging level used to indicate debug-level messages that are typically generated for troubleshooting and are not a notification mechanism. Syslog is a separate protocol from SNMP, used for system logging, and severity 7 messages are often verbose and not necessarily event-driven alerts. Even if a device sends syslog messages, this is not the SNMP trap mechanism, and the question specifically refers to the SNMP-based notification behavior.

Trap 2: DHCP relay

DHCP relay (ip helper-address) is a Layer 3 feature that forwards DHCP client broadcast requests to a DHCP server on another subnet, allowing clients to obtain IP configuration across network boundaries. It is entirely unrelated to SNMP and does not provide any event notification or alerting capability. A DHCP relay agent does not monitor device status or send unsolicited messages to a management station, so it cannot satisfy the requirement for an immediate device-triggered notification.

Trap 3: NetFlow exporters

NetFlow exporters are network devices configured to send flow records — metadata about traffic flows, such as source/destination IPs and port numbers — to a NetFlow collector for traffic analysis, capacity planning, or security forensics. These exports are periodic or based on flow expiration, not unsolicited event alerts from the device. Therefore, NetFlow is designed for visibility into traffic patterns rather than the immediate, event-driven notification that SNMP traps provide.

A
SNMP traps
An SNMP trap is an unsolicited, event-driven message that a managed device sends directly to a network management station (NMS) to alert it of a fault, status change, or security incident. Unlike SNMP polling, which requires the NMS to request information, traps are pushed immediately when the triggering event occurs, enabling real-time notification without waiting for a poll cycle. This is exactly the behavior described by the requirement to receive an immediate notification from a device.
B
Syslog severity 7
Why wrong: Syslog severity 7 is a logging level used to indicate debug-level messages that are typically generated for troubleshooting and are not a notification mechanism. Syslog is a separate protocol from SNMP, used for system logging, and severity 7 messages are often verbose and not necessarily event-driven alerts. Even if a device sends syslog messages, this is not the SNMP trap mechanism, and the question specifically refers to the SNMP-based notification behavior.
C
DHCP relay
Why wrong: DHCP relay (ip helper-address) is a Layer 3 feature that forwards DHCP client broadcast requests to a DHCP server on another subnet, allowing clients to obtain IP configuration across network boundaries. It is entirely unrelated to SNMP and does not provide any event notification or alerting capability. A DHCP relay agent does not monitor device status or send unsolicited messages to a management station, so it cannot satisfy the requirement for an immediate device-triggered notification.
D
NetFlow exporters
Why wrong: NetFlow exporters are network devices configured to send flow records — metadata about traffic flows, such as source/destination IPs and port numbers — to a NetFlow collector for traffic analysis, capacity planning, or security forensics. These exports are periodic or based on flow expiration, not unsolicited event alerts from the device. Therefore, NetFlow is designed for visibility into traffic patterns rather than the immediate, event-driven notification that SNMP traps provide.

Question 9hardScenario

You are connected to R1, a Cisco ISR 4321 running IOS-XE. Configure SNMPv2c with a read-only community string 'public' and SNMPv3 with user 'admin' using SHA authentication and AES encryption. Ensure SNMP traps are sent to the management server at 203.0.113.10. Additionally, configure NetFlow export to destination 203.0.113.20 on UDP port 2055 using version 9. Verify your configuration with appropriate show commands. The current running-config is incomplete; you must add the missing commands.

Exhibit

R1#show running-config | section snmp|ip flow
!
! No SNMP or NetFlow configuration currently exists
! Only the following lines are present:
!
snmp-server community public RO
!

Trap 1: snmp-server community public ro snmp-server user admin snmp-group…

This configuration fails because the snmp-server host command for trap destinations is written for SNMPv3 with 'auth' but then gives 'public' as the final parameter. In SNMPv3, a community string is never used; the host command must reference the configured SNMPv3 security name (such as 'admin') rather than 'public'. The NetFlow version and SNMPv2c community are correct, but this invalid trap-host line prevents the NMS from receiving authenticated traps.

Trap 2: snmp-server community public ro snmp-server user admin snmp-group…

The SNMPv3 user in this option is created with MD5 for authentication and DES 56-bit for privacy, but the security requirements demand SHA and AES 128. MD5 and DES are legacy algorithms that are weaker and are not acceptable when a stronger SHA/AES policy is specified. Because the user's credentials do not match the required algorithms, the SNMPv3 configuration is nonconformant even though the trap host and NetFlow v9 lines are correct.

Trap 3: snmp-server community public ro snmp-server user admin snmp-group…

Here the SNMP commands are all correct, but the NetFlow export version is set to 5 instead of version 9. NetFlow v5 uses a fixed format with no template support, while v9 sends template records that allow flexible field definitions, IPv6, and MPLS metadata. Since the requirement explicitly specifies version 9, specifying version 5 means the device cannot properly export the required NetFlow data.

A
snmp-server community public ro snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco snmp-server host 203.0.113.10 traps version 2c public ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
This is the only option that is completely valid: the SNMPv2c read-only community allows basic NMS polling, the SNMPv3 user is properly configured with SHA authentication and AES 128 privacy, and the trap destination uses SNMPv2c with the matching 'public' community string. The NetFlow configuration exports with version 9, the template-based version required. Together, these commands satisfy the SNMP security and NetFlow version requirements without any syntax or semantic error.
B
snmp-server community public ro snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco snmp-server host 203.0.113.10 traps version 3 auth public ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
Why wrong: This configuration fails because the snmp-server host command for trap destinations is written for SNMPv3 with 'auth' but then gives 'public' as the final parameter. In SNMPv3, a community string is never used; the host command must reference the configured SNMPv3 security name (such as 'admin') rather than 'public'. The NetFlow version and SNMPv2c community are correct, but this invalid trap-host line prevents the NMS from receiving authenticated traps.
C
snmp-server community public ro snmp-server user admin snmp-group v3 auth md5 cisco priv des56 cisco snmp-server host 203.0.113.10 traps version 2c public ip flow-export destination 203.0.113.20 2055 ip flow-export version 9
Why wrong: The SNMPv3 user in this option is created with MD5 for authentication and DES 56-bit for privacy, but the security requirements demand SHA and AES 128. MD5 and DES are legacy algorithms that are weaker and are not acceptable when a stronger SHA/AES policy is specified. Because the user's credentials do not match the required algorithms, the SNMPv3 configuration is nonconformant even though the trap host and NetFlow v9 lines are correct.
D
snmp-server community public ro snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco snmp-server host 203.0.113.10 traps version 2c public ip flow-export destination 203.0.113.20 2055 ip flow-export version 5
Why wrong: Here the SNMP commands are all correct, but the NetFlow export version is set to 5 instead of version 9. NetFlow v5 uses a fixed format with no template support, while v9 sends template records that allow flexible field definitions, IPv6, and MPLS metadata. Since the requirement explicitly specifies version 9, specifying version 5 means the device cannot properly export the required NetFlow data.

Question 10hardmultiple choice

A monitoring system already collects Syslog and SNMP data. The network team now wants visibility into which applications or host conversations are driving link utilization. What is the strongest addition?

Trap 1: Another SSID

Another SSID is wrong because an SSID is simply the name of a wireless LAN and is used by clients to identify and connect to a particular wireless network. Creating a second SSID might segment wireless clients onto different VLANs or policies, but it does not produce flow-level data about traffic utilization. Since the monitoring gap is about traffic visibility, adding a network name does not address the need for flow analytics.

Trap 2: PortFast

PortFast is wrong because it is a Spanning Tree Protocol (STP) feature that allows a switch port to transition immediately from blocking to forwarding, bypassing the listening and learning states. Its purpose is to speed up convergence on ports connected to end devices, not to monitor or measure network traffic. PortFast has no ability to record flow information, so enabling it would not provide the traffic-usage details the monitoring system lacks.

Trap 3: A larger wildcard mask

A larger wildcard mask is wrong because wildcard masks are used by ACLs to define which packet headers match a permit or deny statement. Changing the wildcard mask only alters the range of IP addresses to which the ACL is applied; it does not generate traffic analytics or flow records. ACLs themselves are stateless filters, not monitoring tools, so expanding a wildcard mask has no effect on visibility into traffic usage.

A
NetFlow
NetFlow is correct because it captures metadata about traffic flows — including source/destination IPs, ports, and protocol — and exports that data to a collector for analysis. This gives the monitoring system detailed, flow-level visibility into who is talking to whom and how much bandwidth each conversation uses, which syslog and SNMP alone cannot provide. NetFlow complements existing syslog and SNMP data by focusing on network traffic patterns rather than device logs or interface counters.
B
Another SSID
Why wrong: Another SSID is wrong because an SSID is simply the name of a wireless LAN and is used by clients to identify and connect to a particular wireless network. Creating a second SSID might segment wireless clients onto different VLANs or policies, but it does not produce flow-level data about traffic utilization. Since the monitoring gap is about traffic visibility, adding a network name does not address the need for flow analytics.
C
PortFast
Why wrong: PortFast is wrong because it is a Spanning Tree Protocol (STP) feature that allows a switch port to transition immediately from blocking to forwarding, bypassing the listening and learning states. Its purpose is to speed up convergence on ports connected to end devices, not to monitor or measure network traffic. PortFast has no ability to record flow information, so enabling it would not provide the traffic-usage details the monitoring system lacks.
D
A larger wildcard mask
Why wrong: A larger wildcard mask is wrong because wildcard masks are used by ACLs to define which packet headers match a permit or deny statement. Changing the wildcard mask only alters the range of IP addresses to which the ACL is applied; it does not generate traffic analytics or flow records. ACLs themselves are stateless filters, not monitoring tools, so expanding a wildcard mask has no effect on visibility into traffic usage.

Question 11hardScenario

You are connected to R1. Configure SNMPv3 with authentication (SHA) and encryption (AES-128) for user 'monitor' in group 'AdminGroup', and also configure SNMPv2c read-only community string 'cisco123' to send traps to the management server at 192.0.2.100. Additionally, configure NetFlow on interface GigabitEthernet0/0 to export flow data to 198.51.100.50 using version 9. Verify your configuration using the appropriate show commands.

Exhibit

R1#show running-config | section snmp
snmp-server community public RO
snmp-server community private RW
!
R1#show running-config | include flow-export
no ip flow-export destination
no ip flow-export version
!
R1#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.0.0.1        YES NVRAM  up                    up
GigabitEthernet0/1     203.0.113.1     YES NVRAM  up                    up
Loopback0              192.0.2.1       YES NVRAM  up                    up
!

Trap 1: snmp-server group AdminGroup v3 auth read AdminView; snmp-server…

This is incorrect because the SNMPv3 group is configured with 'auth' instead of 'priv'. The 'auth' keyword only requires authentication, not encryption. The question specifies both authentication (SHA) and encryption (AES-128), so the group must use 'priv' to allow encryption.

Trap 2: snmp-server group AdminGroup v3 priv read AdminView; snmp-server…

This configuration fails because the SNMPv3 user is bound to DES (priv des 56) instead of the required AES-128 encryption. Although the group is correctly set to priv, the user-level 'priv' parameter specifies the encryption algorithm, and DES is a legacy, weaker cipher that does not meet the stated AES-128 requirement. In Cisco IOS, the correct syntax for AES-128 would be 'priv aes 128', ensuring the user's traffic is encrypted with the mandated standard.

Trap 3: snmp-server group AdminGroup v3 priv read AdminView; snmp-server…

This is incorrect because NetFlow export version is set to 5 instead of version 9. The question explicitly requires version 9. Version 5 is an older format that does not support flexible field definitions and templates.

A
snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress
This configuration correctly creates an SNMPv3 group with priv access, creates the user with SHA authentication and AES-128 encryption, sets the SNMPv2c read-only community, sends traps to the manager, and enables NetFlow version 9 on the interface. The verification commands would show the SNMP configuration and NetFlow flow cache.
B
snmp-server group AdminGroup v3 auth read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress
Why wrong: This is incorrect because the SNMPv3 group is configured with 'auth' instead of 'priv'. The 'auth' keyword only requires authentication, not encryption. The question specifies both authentication (SHA) and encryption (AES-128), so the group must use 'priv' to allow encryption.
C
snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv des 56 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress
Why wrong: This configuration fails because the SNMPv3 user is bound to DES (priv des 56) instead of the required AES-128 encryption. Although the group is correctly set to priv, the user-level 'priv' parameter specifies the encryption algorithm, and DES is a legacy, weaker cipher that does not meet the stated AES-128 requirement. In Cisco IOS, the correct syntax for AES-128 would be 'priv aes 128', ensuring the user's traffic is encrypted with the mandated standard.
D
snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 5; ip flow ingress
Why wrong: This is incorrect because NetFlow export version is set to 5 instead of version 9. The question explicitly requires version 9. Version 5 is an older format that does not support flexible field definitions and templates.

Read the full DHCP explanation →

Question 12hardmultiple choice

A switch has DHCP snooping enabled, but users still experience IP-to-MAC spoofing attacks. Which additional feature should be considered to help address that specific problem?

Trap 1: PortFast

PortFast is a Spanning Tree Protocol (STP) enhancement that allows a switch port to transition directly to the forwarding state, bypassing the listening and learning states, to accelerate device boot-up in access ports. It has no mechanism to inspect or validate ARP messages, so it cannot resolve the IP-to-MAC mismatch caused by ARP spoofing; it only shortens the STP convergence time for end devices.

Trap 2: EtherChannel

EtherChannel bundles multiple physical links into one logical link, providing load balancing and link redundancy at Layer 2, but it does not inspect or validate ARP packets. The IP-to-MAC binding issue described is an ARP spoofing problem, which EtherChannel cannot address because it operates purely at the link aggregation level, not at the protocol security layer.

Trap 3: NetFlow

NetFlow is a flow-based accounting and monitoring tool that collects metadata about IP traffic, such as source/destination addresses and ports, enabling traffic analysis and anomaly detection post-facto. It does not actively intercept or validate ARP requests/replies, so it cannot prevent the ARP cache poisoning that causes incorrect IP-to-MAC mappings.

A
PortFast
Why wrong: PortFast is a Spanning Tree Protocol (STP) enhancement that allows a switch port to transition directly to the forwarding state, bypassing the listening and learning states, to accelerate device boot-up in access ports. It has no mechanism to inspect or validate ARP messages, so it cannot resolve the IP-to-MAC mismatch caused by ARP spoofing; it only shortens the STP convergence time for end devices.
B
Dynamic ARP Inspection
Dynamic ARP Inspection (DAI) is a security feature on switches that intercepts all ARP requests and replies on untrusted ports and validates them against the DHCP snooping binding table. If the IP-to-MAC mapping in an ARP packet does not match the binding table, DAI drops the packet, thereby preventing ARP poisoning attacks. Additionally, DAI can rate-limit ARP packets to mitigate ARP-based denial-of-service attacks, making it the precise solution for the user's IP-to-MAC issue.
C
EtherChannel
Why wrong: EtherChannel bundles multiple physical links into one logical link, providing load balancing and link redundancy at Layer 2, but it does not inspect or validate ARP packets. The IP-to-MAC binding issue described is an ARP spoofing problem, which EtherChannel cannot address because it operates purely at the link aggregation level, not at the protocol security layer.
D
NetFlow
Why wrong: NetFlow is a flow-based accounting and monitoring tool that collects metadata about IP traffic, such as source/destination addresses and ports, enabling traffic analysis and anomaly detection post-facto. It does not actively intercept or validate ARP requests/replies, so it cannot prevent the ARP cache poisoning that causes incorrect IP-to-MAC mappings.

Question 13mediummultiple choice

A team wants to know which internal hosts are sending the most traffic to a specific data center subnet. Which technology is most directly associated with that visibility goal?

Trap 1: Syslog

This is wrong because Syslog focuses on event and message reporting.

Trap 2: DHCP

This is wrong because DHCP assigns host configuration and does not provide traffic-flow analysis.

Trap 3: PortFast

This is wrong because PortFast is an STP edge-port feature.

A
NetFlow
This is correct because NetFlow is designed to provide traffic-flow visibility.
B
Syslog
Why wrong: This is wrong because Syslog focuses on event and message reporting.
C
DHCP
Why wrong: This is wrong because DHCP assigns host configuration and does not provide traffic-flow analysis.
D
PortFast
Why wrong: This is wrong because PortFast is an STP edge-port feature.

Question 14hardScenario

You are connected to R1 via the console. SNMP v2c community strings (public RO, private RW) are already configured. The network has a management server at 10.1.1.100 and a NetFlow collector at 10.1.1.200. Configure SNMP traps to the management server for link status changes. Also configure NetFlow on interface GigabitEthernet0/0 to export version 9 to the collector, with a source interface of Loopback0 (10.255.255.1/32).

Exhibit

R1#show running-config | section snmp|flow
Building configuration...

Current configuration : 1234 bytes
!
snmp-server community public RO
snmp-server community private RW
!
! No trap or NetFlow configuration exists
!
interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
interface Loopback0
 ip address 10.255.255.1 255.255.255.255
!
end

Trap 1: snmp-server host 10.1.1.200 version 2c private snmp-server enable…

This configuration is incorrect because the trap destination is set to the NetFlow collector (10.1.1.200) instead of the management server (10.1.1.100), and the NetFlow export destination is set to the management server instead of the collector. Additionally, NetFlow should be configured as ingress, not egress.

Trap 2: snmp-server host 10.1.1.100 version 2c private snmp-server enable…

This configuration uses the read-write community string 'private' for SNMP traps instead of the read-only 'public'. While the trap destination and NetFlow settings are correct, the community string must match the read-only community for traps.

Trap 3: snmp-server host 10.1.1.100 version 2c public snmp-server enable…

This configuration is almost correct but fails because it specifies NetFlow version 5 (`ip flow-export destination 10.1.1.200 2055 version 5`) instead of the explicitly required version 9. NetFlow v5 uses a fixed record format that lacks the flexibility and extensibility of v9's template-based structure, so it cannot support advanced features such as MPLS or IPv6 flow records. The SNMP trap destination, community string "public", link trap settings, export source Loopback0, and `ip flow ingress` are all correct; the sole defect is the incorrect NetFlow export version, which would prevent the collector from receiving the required v9 flow data.

A
snmp-server host 10.1.1.100 version 2c public snmp-server enable traps snmp linkdown linkup ip flow-export destination 10.1.1.200 2055 ip flow-export version 9 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow ingress
This configuration is correct because it sends SNMPv2c traps to the management server at 10.1.1.100 using the read-only community string "public", and it explicitly enables only the required linkdown and linkup traps with the `snmp-server enable traps snmp linkdown linkup` command. NetFlow is exported to the collector at 10.1.1.200 on UDP port 2055 using version 9, which is the required template-based export format. The export source is set to Loopback0 for a stable IP address, and `ip flow ingress` on GigabitEthernet0/0 monitors inbound traffic as demanded by the question.
B
snmp-server host 10.1.1.200 version 2c private snmp-server enable traps ip flow-export destination 10.1.1.100 2055 version 9 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow egress
Why wrong: This configuration is incorrect because the trap destination is set to the NetFlow collector (10.1.1.200) instead of the management server (10.1.1.100), and the NetFlow export destination is set to the management server instead of the collector. Additionally, NetFlow should be configured as ingress, not egress.
C
snmp-server host 10.1.1.100 version 2c private snmp-server enable traps ip flow-export destination 10.1.1.200 2055 version 9 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow ingress
Why wrong: This configuration uses the read-write community string 'private' for SNMP traps instead of the read-only 'public'. While the trap destination and NetFlow settings are correct, the community string must match the read-only community for traps.
D
snmp-server host 10.1.1.100 version 2c public snmp-server enable traps snmp linkdown linkup ip flow-export destination 10.1.1.200 2055 version 5 ip flow-export source Loopback0 interface GigabitEthernet0/0 ip flow ingress
Why wrong: This configuration is almost correct but fails because it specifies NetFlow version 5 (`ip flow-export destination 10.1.1.200 2055 version 5`) instead of the explicitly required version 9. NetFlow v5 uses a fixed record format that lacks the flexibility and extensibility of v9's template-based structure, so it cannot support advanced features such as MPLS or IPv6 flow records. The SNMP trap destination, community string "public", link trap settings, export source Loopback0, and `ip flow ingress` are all correct; the sole defect is the incorrect NetFlow export version, which would prevent the collector from receiving the required v9 flow data.