Two weeks after launching a new online license renewal feature, how should the city assess software security effectiveness?
Select an answer to reveal the explanation.
Short Explanation
New features are shiny—and attackers notice shiny. After launch, watch for exploit probes and weird traffic aimed at that license renewal path. Post-release monitoring tells you whether the security work actually held up in the wild.
Full Explanation
Two weeks after launching an online license renewal feature, software security effectiveness is assessed in part by monitoring for exploit attempts and anomalous use targeting that feature—failed auth spikes, parameter tampering, unusual geographies, WAF blocks, and abuse of new endpoints. Post-release monitoring validates whether controls hold under real adversarial and accidental pressure and feeds rapid response when a novel path appears. New features are freshly mapped by attackers; watching them is how the city learns whether design and test assumptions survive contact with the internet.
Assuming zero risk because a single unit test passed ignores integration, abuse cases, and production configuration drift; one unit test is not residual-risk zero.
Deleting WAF logs to free disk space destroys the evidence needed to assess attacks against the new feature and harms investigations.
Disabling authentication to reduce help-desk tickets expands anonymous abuse and fraud on license renewals—the opposite of security effectiveness.
Exam caveat: post-deployment monitoring and feedback into the SDLC are Domain 8 sustainment ideas—effectiveness is observed, not assumed. Operational check: tag new feature routes in SIEM/WAF analytics, set anomaly alerts for the first release window, review findings in a short operational retrospective, and file defects back into the backlog with owners.