After the library district patches a critical web server CVE, management asks how the team will prove the fix worked. Which validation activity is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Closing the ticket is not the same as proving the bolt is tight—run the scanner again (or an equivalent check) and see the finding go away. Validation means evidence, not hope or a marketing note.
Full Explanation
Validation after remediation proves the library-district web server no longer presents the critical CVE. Rescanning the host with the same authenticated vulnerability profile—or an equivalent configuration/version check—provides objective evidence that the patch landed, services restarted correctly, and the signature is gone. That closes the vulnerability-management loop for management and auditors instead of relying on hope.
Assuming success because the change ticket closed confuses process completion with technical verification; tickets can close on incomplete or failed deploys. Vendor marketing email is not host-specific evidence. Skipping validation to avoid new findings deliberately blinds the program and can leave the citizen-facing library service still vulnerable.
Exam caveat: validation is a defined phase after remediation. A clean change record is necessary for change control but insufficient for vulnerability closure. If the finding persists, reopen remediation rather than marking risk accepted by accident.
Operational check: after the patch window, run a targeted authenticated scan against the host, confirm the CVE ID is absent, spot-check package versions, update the ticket with scan evidence, and only then report the item closed to management.