A security policy requires that SNMP polling of perimeter devices authenticate each message and encrypt its payload, and that SNMPv2c community strings be retired. Which configuration meets the requirement?
Select an answer to reveal the explanation.
Short Explanation
SNMPv3 has three security dials: noAuthNoPriv, authNoPriv, and authPriv. Only authPriv gives you both a verified sender and a scrambled payload. Don't get tricked by authNoPriv, which sounds secure but still sends your data in the clear.
Full Explanation
SNMPv3 replaces community strings with the user-based security model. Each user belongs to a group, and the group's security level determines protection: noAuthNoPriv matches on a username with no authentication and no encryption, authNoPriv adds message authentication using a hash-based algorithm, and authPriv adds both authentication and privacy, meaning the payload is encrypted. Because the requirement names both per-message authentication and payload encryption, only authPriv satisfies it. authNoPriv proves the message came from a valid user and was not altered, but any observer on the path can still read values such as interface descriptions and configuration details. noAuthNoPriv offers neither property and is essentially a username-based equivalent of a community string. SNMPv2c with long community strings and an ACL limits who can poll, but the community travels in clear text with every message and there is no payload encryption, and the requirement explicitly retires v2c. Exam caveat: the authentication and privacy algorithms are configured per user, so choose strong ones; a weak legacy cipher still meets authPriv on paper but not the intent of a hardening benchmark. Operational check: configure the group with the priv level, create users with authentication and privacy passwords, poll from the manager using matching credentials, and capture a packet to confirm the PDU contents are encrypted.