350-401 Practice Question: Examine this SNMP configuration snippet from a…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  SNMP read requests from any host in the 192.168.1.0/24 network using community 'MyComm' will be accepted.

  Why this is correct

  The access-list 10 is used as a source IP filter that permits exactly the 192.168.1.0/24 subnet, and this ACL is explicitly associated with the community string 'MyComm' through an SNMP server command (e.g., snmp-server community MyComm RO 10). Because the RO (read-only) keyword is present, only read operations such as GET, GETNEXT, and GETBULK are allowed; write operations like SET are silently rejected even for hosts in the permitted network. Therefore, any device in 192.168.1.0/24 that supplies the correct community string can successfully perform SNMP reads, while all other sources are implicitly denied by the ACL's implicit deny rule.

• ✗

  SNMP read and write requests from 192.168.1.0/24 using community 'MyComm' will be accepted.

  Why it's wrong here

  This statement is wrong because the community string 'MyComm' is configured with the RO (read-only) option, not RW (read-write). Even though hosts in 192.168.1.0/24 are permitted by access-list 10 to use this community, they are only authorized to issue read requests. SNMP write operations (SET, SETBULK) require read-write permission, which is not granted here, so any attempt to modify device configuration or set MIB variables will fail with a noAccess or notWritable error. Thus, the combination of the ACL and RO designation separates source authorization from permission level, and write is never allowed.

• ✗

  Only SNMP requests from the 192.168.1.0/24 network are allowed, regardless of community string.

  Why it's wrong here

  This statement incorrectly implies that the ACL alone restricts all SNMP traffic based solely on source IP, independent of the community string. In Cisco IOS, an ACL is not applied globally to all SNMP requests; it is bound to a specific community string, as in `snmp-server community MyComm RO 10`. The access-list 10 only filters which source addresses are allowed to use the community 'MyComm'. Other configured communities (if any) have their own separate community string and may have different or no ACL restrictions, so SNMP requests from 192.168.1.0/24 with a different community string would not be evaluated by this ACL at all. The community string is a mandatory authentication credential, and the ACL applies only after the correct community is presented.

• ✗

  The access-list 10 is incomplete; it needs a deny statement to block other traffic.

  Why it's wrong here

  Access-list 10 is not incomplete; every standard IP access-list has an implicit deny any at the end, so any source IP that is not explicitly permitted is automatically denied. This is exactly how the ACL works when applied to the SNMP community: only hosts in 192.168.1.0/24 are explicitly permitted, and all other sources are implicitly denied without needing a separate deny statement. In fact, adding an explicit deny statement at the end would be redundant and have no operational effect. The only requirement is that the ACL contains the necessary permit statements for the desired sources, which it does, so the configuration is fully valid and functional.

Go deeper

Related to this question