350-401 Practice Question: Configures SNMPv3 on a Cisco router for secure…

Answer analysis

Option-by-option breakdown

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

• ✗

  The SNMPv3 user is not associated with the group correctly.

  Why it's wrong here

  This fault is not the cause because the configuration explicitly associates user 'admin' with the SNMPv3 group 'ADMIN' using the 'snmp-server user admin ADMIN v3' command, and that group is defined with the 'priv' security level to permit both authentication and encryption. The group-to-user mapping therefore provides the exact auth (SHA) and privacy (AES) privileges that the host command is requesting, so the user linkage is correct. The failure would still occur even with a perfectly valid group association, pointing to a different root cause.

• ✓

  The NMS must be configured with the router's SNMP engine ID.

  Why this is correct

  The NMS must be provisioned with the router's local SNMP engine ID because SNMPv3 user-based authentication (USM) derives each user's authentication and privacy keys by hashing the passphrase together with the authoritative engine ID. Without the correct engine ID, the NMS calculates a different localized key than the router, so the HMAC validation fails and the router silently discards the request after sending it with 'noAuth' or the NMS sees an authentication failure. Even if the username, passwords, and AES settings are identical, a mismatched engine ID always breaks SNMPv3 authentication, making this the necessary corrective action.

• ✗

  The 'priv' keyword in the host command should be 'auth' instead.

  Why it's wrong here

  The keyword 'priv' in the 'snmp-server host' command is actually correct because the SNMPv3 user 'admin' is configured with both authentication and privacy (AES), and 'priv' tells the router to send notifications that are both authenticated and encrypted. Replacing it with 'auth' would only request authentication without encryption, which would not align with the user's security level and could even cause the NMS to reject the notification as having the wrong security level. Thus this change would be a regression, not a fix.

• ✗

  The AES encryption key must be exactly 16 characters.

  Why it's wrong here

  This is not the reason for the problem because SNMPv3 AES key lengths are flexible: RFC 3826 defines AES-128 with a 128-bit (16-byte) key, while later standards support AES-192 and AES-256, so a 16-character limit is not mandatory. Furthermore, the configured 'priv aes 128' cipher in the user command specifies AES-128, and the actual key is derived from the passphrase using a key derivation function that includes the engine ID, not from the literal length of a typed key. The authentication failure persists regardless of the passphrase or key length, confirming that the engine ID mismatch is the issue.

Go deeper

Related to this question