A network engineer notices that an NMS at 10.1.1.200 cannot poll a router that has SNMPv2c configured with community string 'public'. What is causing this issue?
The community string 'public' has an access control list applied that restricts source addresses to 10.1.1.100 only. When the NMS at 10.1.1.200 sends an SNMP poll, the router checks the source IP against the ACL bound to the community string; because 10.1.1.200 is not permitted, the router silently discards the request. This explains why the NMS receives no response, even though the community string matches and the SNMP agent is running.
Why this answer
SNMPv2c community strings can be restricted by an access control list (ACL) that specifies which source IP addresses are allowed to poll the router. If the ACL only permits host 10.1.1.100, then the NMS at 10.1.1.200 will be denied access even though the community string 'public' is correct. This is a common configuration for security, but it prevents polling from unauthorized hosts.
Exam trap
Cisco often tests the misconception that SNMP community strings are the only authentication mechanism, leading candidates to overlook the ACL restriction that can silently block polling from specific hosts.
Why the other options are wrong
Many believe SNMP requires an additional global command to start; on Cisco IOS, a community string entry enables the agent.
Polling failures are often attributed to community string errors, but when the string matches, an ACL restriction produces identical symptoms.
Candidates may assume the agent must be bound to an interface, but Cisco IOS SNMP agents respond on any interface unless limited by an ACL or VRF.