A county IT team needs a repeatable way to find missing patches and known weaknesses on the public web farm before citizens notice outages. Which vulnerability-management activity best identifies those known issues?

Authenticated vulnerability scanning is the municipal identification engine for known weaknesses: credentials let the scanner inventory installed packages, missing patches, and CVE signatures on the public web farm the way a garage inspects every vehicle instead of guessing from the curb. Reviewing those findings starts the vulnerability-management lifecycle—prioritize, remediate, validate—before citizens encounter broken portals or attackers exploit unpatched stacks. Unauthenticated surface scans still help, but authenticated coverage is what repeatedly surfaces configuration and patch gaps inside the OS and application layers that matter for county uptime.

Waiting for help-desk tickets about slow pages is reactive citizen reporting, not vulnerability identification. Outages and performance complaints arrive after impact, and tickets rarely map cleanly to CVEs or missing patches. Disabling load-balancer logging removes visibility that would support incident detection and forensics; it does not discover weaknesses and actively harms security operations. Publishing a maintenance press release is communications work that neither enumerates CVEs nor proves hosts are patched.

Exam caveat: identification is only the first phase—scanning without ownership, SLAs, and rescan validation leaves risk on citizen-facing services. Do not confuse vulnerability scanning with penetration testing; the scanner finds known issues at scale, while exploit validation is a separate authorized activity.

Operational check: confirm scan credentials are vaulted and least-privilege, schedules cover every web-farm node after change windows, false positives are triaged, and critical findings open tickets with owners before the next public release.