Snmp practice questions

DNS: Assigns IP addresses dynamically to devices on a network

Why wrong: Dynamic IP assignment is the job of DHCP (Dynamic Host Configuration Protocol), which leases IP addresses, subnet masks, default gateways, and other parameters to clients for a set duration. DNS is a peer-to-peer name-resolution service that stores resource records; it has no mechanism for leasing or reclaiming IP addresses. So, attributing dynamic address assignment to DNS is incorrect because that service belongs exclusively to DHCP.

DNS: Synchronizes time across network devices

Why wrong: Precise time synchronization across network devices is handled by NTP (Network Time Protocol), which distributes Coordinated Universal Time (UTC) to maintain accurate clocks for log correlation, authentication, and timestamping. DNS handles only name-to-address (and related) queries, and it has no protocol operations for reading or setting device clocks. Therefore, DNS cannot serve as a time-synchronization protocol.

DNS: Manages and monitors network devices

Why wrong: Managing and monitoring network devices—such as polling CPU, memory, interface status, and generating alerts—is the function of SNMP (Simple Network Management Protocol), whose managed objects are defined in MIBs. DNS is strictly a resolution service that translates names to IP addresses as part of application-layer lookups; it does not collect device metrics or perform management operations. Describing DNS as a network management protocol is inaccurate because that role belongs to SNMP.

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.

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.

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.

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.

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.

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.

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.

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.

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'.

Syslog is used to assign IP addresses dynamically to endpoints

Why wrong: Dynamic IP address assignment is performed by DHCP, which leases addresses from a configured pool and delivers client options like subnet mask and gateway, not by syslog. Syslog is purely an observability protocol used to forward log messages, and it has no mechanism or role in network address allocation, so this option incorrectly conflates a logging service with DHCP.

Syslog entries replace SNMP counters for interface statistics

Why wrong: Syslog is event-driven and reports discrete occurrences such as interface errors or configuration changes, while SNMP continuously tracks cumulative counters like bytes transmitted, packets dropped, and CRC errors from the MIB. These serve different purposes: SNMP provides quantitative traffic statistics for capacity planning and performance monitoring, whereas syslog delivers qualitative event notifications, so syslog cannot substitute for SNMP counters.

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.

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.

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.

Requiring manual threshold configuration for every monitored metric

Why wrong: Requiring manual threshold configuration for every monitored metric is the antithesis of machine learning training. Traditional threshold-based systems, like those that alarm when CPU usage exceeds 80% or when packets per second exceed a fixed value, are static and fail to adapt to changing network conditions. Manually setting thresholds for thousands of metrics is operationally unsustainable, creates brittle rules, and cannot capture complex multivariate correlations. In contrast, ML models automatically learn dynamic thresholds and relationships from historical data, removing the need for per-metric engineering.

Training exclusively on synthetic data generated by simulation tools

Why wrong: Training exclusively on synthetic data generated by simulation tools is insufficient for production network security ML. While synthetic traffic can provide large volumes of labeled data and cover rare attack scenarios, real-world traffic contains a long tail of legitimate protocols, application-specific quirks, encryption patterns, and user behaviors that simulators rarely reproduce faithfully. A model trained solely on synthetic data will exhibit domain shift, meaning it will perform poorly when deployed against actual network telemetry. Therefore, synthetic data is used only as a supplement or pre-training step, not as the sole training corpus.

Relying solely on SNMP polling intervals to detect anomalies

Why wrong: Relying solely on SNMP polling intervals to detect anomalies limits the temporal resolution and feature depth available to an ML model. SNMP polling typically occurs every 5–15 minutes and only exposes coarse counters like interface utilization, packet counts, or error rates, which can conceal short-lived attacks such as port scans or single-packet exploits. Such polling provides no flow-level or packet-level context, such as TCP flags, payload patterns, or conversation endpoints, which are essential for detecting sophisticated intrusions. Modern ML-based NIDS instead ingest streaming telemetry like NetFlow, IPFIX, or full packet capture to enable real-time, fine-grained anomaly detection.

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.

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.

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.

SNMPv2c is not enabled on the router.

Why wrong: Configuring the SNMP community string 'public' via the snmp-server community command implicitly enables the SNMP agent for SNMPv1 and SNMPv2c on the router; no separate 'enable' command is required. Because the question states the community string is configured, the SNMPv2c agent is active and listening, so a lack of enablement cannot be the cause of the NMS's failed polls. The issue must instead lie in how the community is restricted, not in whether the agent version is enabled.

The NMS is using the wrong community string.

Why wrong: The NMS is not using the wrong community string; both the router and the NMS have been configured with 'public' as the SNMP community. A community string mismatch would cause the router to drop the request with an authentication failure, but the scenario explicitly states that the community is correctly set. Therefore, the failure must be caused by a filtering mechanism, such as an ACL applied to the community, rather than a mismatch.

The router's SNMP agent is not listening on the interface facing 10.1.1.200.

Why wrong: By default, the Cisco IOS SNMP agent listens on all IP interfaces and does not restrict its operation to a specific interface unless configured with the snmp-server interface command. The problem statement does not indicate any interface-specific SNMP configuration, so the agent is reachable on the interface facing 10.1.1.200. Since the agent is listening globally, this option cannot explain why the NMS at 10.1.1.200 gets no response while 10.1.1.100 would succeed.

SNMP

Why wrong: SNMP is a UDP-based protocol that manages network devices by reading and writing MIB objects, but it is fundamentally oriented toward monitoring and simple metric collection. Its SET operations lack transactional safety, configuration rollback, or standardized YANG data models, so it cannot reliably support the validation and rollback needed for automated closed-loop remediation. Thus, while SNMP can alert an AI agent to a fault, it is not the tool for applying structured configuration changes.

CLI scripting

Why wrong: CLI scripting, such as Expect or pexpect, automates network devices by sending text commands and parsing screen output, but it is brittle and platform-specific because it depends on exact command syntax and output formatting. It lacks machine-readable data models, structured RPC semantics, and transactional rollback, so any network change can fail silently or leave the device in an inconsistent state. Consequently, CLI scripting is not a robust or scalable mechanism for an AI-driven closed-loop remediation system.

Syslog

Why wrong: Syslog is a one-way logging protocol that transmits event messages from network devices to a collector; it cannot accept or execute configuration commands from a management system. It is useful for detecting faults and providing audit trails, but it does not provide any RPC mechanism for changing device state. Therefore, while syslog may feed data into a closed-loop detector, it is entirely incapable of carrying out automated remediation actions.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Configure the interface with `switchport mode trunk`

Why wrong: A trunk port is designed to carry tagged frames for multiple VLANs simultaneously, typically between switches or to a router that supports 802.1Q tagging. An end host does not usually tag its traffic; if the switchport is set to trunk, the host's untagged frames would be placed in the native VLAN, potentially causing VLAN mismatch, broadcast isolation, and security issues. Therefore trunk mode is not appropriate for a simple end-host connection.

Configure the interface with `switchport mode dynamic desirable`

Why wrong: Dynamic desirable is a Dynamic Trunking Protocol (DTP) mode that actively tries to negotiate a trunk with the connected neighbor. Because an ordinary end host does not generate DTP frames, the port will either remain in access mode after a failed negotiation or, if the host is actually another switch, it could unexpectedly form a trunk, defeating security best practices. This non-deterministic negotiation-based behavior makes it unsuitable for a dedicated end-host port, which should be explicitly forced into access mode.

Configure the interface with `no switchport`

Why wrong: The 'no switchport' command on a multilayer switch converts the interface from a Layer 2 switching port into a routed port that operates at Layer 3, requiring an IP address to forward packets. This eliminates the ability to assign the port to a VLAN and disables normal Ethernet switching, which is not what an end host needs. The port would no longer bridge traffic as a standard access port, and the host would be unable to communicate on the VLAN unless the routed configuration is intentionally desired.

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.

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.

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.

ip access-list extended FILTER permit tcp 192.168.1.0 0.0.0.255 any eq 80 permit tcp 192.168.1.0 0.0.0.255 any eq 443 permit ip 192.168.2.0 0.0.0.255 any interface g0/0 ip access-group FILTER out

Why wrong: This is incorrect because the ACL is applied outbound on G0/0. Traffic from 192.168.1.0/24 enters R1 through G0/0, so an inbound ACL on G0/0 filters it before routing. An outbound ACL on G0/0 would filter traffic leaving that interface, which is traffic destined to the 192.168.1.0/24 subnet, not traffic from it.

ip access-list extended FILTER permit tcp 192.168.1.0 0.0.0.255 any eq 80 permit tcp 192.168.1.0 0.0.0.255 any eq 443 permit ip 192.168.2.0 0.0.0.255 any interface g0/1 ip access-group FILTER in

Why wrong: This is incorrect because the ACL is applied inbound on G0/1, which is the interface facing the 192.168.2.0/24 subnet. Traffic from 192.168.1.0/24 enters R1 through G0/0, not G0/1. Applying the ACL on G0/1 would filter traffic from 192.168.2.0/24, which should be permitted without restriction, and would not filter traffic from 192.168.1.0/24 at all.

ip access-list extended FILTER permit tcp 192.168.1.0 0.0.0.255 any eq 80 permit tcp 192.168.1.0 0.0.0.255 any eq 443 permit ip 192.168.2.0 0.0.0.255 any interface g0/0 ip access-group FILTER in interface g0/1 ip access-group FILTER in

Why wrong: This is incorrect because the same ACL is applied inbound on both G0/0 and G0/1. While the ACL permits all traffic from 192.168.2.0/24, applying it on G0/1 is unnecessary and could cause confusion. More importantly, the ACL does not include an explicit deny for traffic from 192.168.1.0/24 other than HTTP/HTTPS; the implicit deny at the end of the ACL will block that traffic, but applying the ACL on G0/1 would also block any traffic from 192.168.2.0/24 that is not IP (though unlikely). The requirement is to apply the ACL only on the interface facing the internal subnets, which is typically one interface per subnet. Applying it on both interfaces is not required and may lead to misconfiguration.

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.

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.

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.

Syslog

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

DHCP

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

PortFast

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