The monitoring team wants to poll the new appliance for health metrics and proposes SNMP v2c with the read-only community string 'monitor' across the production LAN. What is the correct SNMP decision during management setup?

SNMP version selection during setup is a management-plane security decision, because the version determines how credentials cross the wire. Versions 1 and 2c send the community string unencrypted in every request, so anyone with path visibility on a shared production LAN can capture it; a guessable string on production infrastructure then turns passive visibility into active enumeration of the management plane. Version 3 replaces the shared plaintext with named users, message authentication that verifies the sender, and optional privacy that encrypts the payload — the correct posture on a LAN shared with production traffic even when the data read is 'only' metrics. The read-only defense fails by concept: read-only restricts what a captured credential authorizes, not whether the credential leaks at all, and captured strings still map devices and versions. Refusing SNMP inverts the requirement — polling is a normal, low-overhead monitoring pattern, while scripted GUI sessions add their own credentials and fragility. Unguessability alone fails twice: it does not prevent in-transit capture by anyone watching the path, and a production LAN is precisely the environment whose visibility cannot be assumed benign. Exam caveat: if v3 is adopted, record the chosen security level — authentication alone or authentication plus privacy — in the deployment documentation. Operational check: after configuration, run one poll from the monitoring server and confirm the exchange uses the intended v3 security level before metrics dashboards open.