After prioritizing vulnerabilities on a parks recreation API, what remediation outcomes are appropriate for the operations and security teams?
Select an answer to reveal the explanation.
Short Explanation
Once you know which leaks matter, you patch the pipe, put a temporary clamp on it, or write down why you are living with the drip. Silent ignore, reboot superstition, or posting the scan are not remediation.
Full Explanation
After prioritization, remediation outcomes for a parks recreation API are to patch, mitigate, or formally accept residual risk with documentation—then track closure to completion. That closed-loop discipline ensures citizen-facing APIs do not accumulate unmarked risk and that accepted risks remain visible to governance rather than disappearing from dashboards.
Ignoring every finding without records to keep dashboards green falsifies posture. Only rebooting hypervisors does not clear application CVEs in guest software. Publishing the raw scan to the public website in place of fixing anything can aid attackers and does not constitute remediation.
Exam caveat: risk acceptance is a valid outcome when documented with owner, expiry, and rationale—not silent ignore. Mitigation (WAF rule, disable feature) can buy safety when patches lag.
Operational check: for each prioritized finding, record the chosen treatment, implement patch or control, re-scan to verify or attach acceptance paperwork, and update the parks service risk register. Review accepted risks on a calendar until closed or refreshed.
Municipal security governance should sample closed parks-API tickets to confirm that “patched,” “mitigated,” and “accepted” labels each have matching evidence, preventing dashboard greenwashing while citizen recreation services remain exposed.