A city CISO notices staff calling every firewall rule 'detective.' Which statement correctly contrasts a blocking firewall rule with a SIEM alert that only notifies after traffic has already occurred?

Preventive controls stop or reduce the chance that an unwanted action succeeds before it completes; detective controls identify and signal activity after it occurs or while it remains observable. A city firewall rule that drops unauthorized traffic is preventive because the deny action itself blocks the flow from succeeding. A SIEM alert that only notifies after matching events land in logs is detective: it surfaces what already happened so analysts can investigate. The contrast is about when and how the control acts, not whether the product can write logs.

Saying both are detective because any technology that uses logs must be detective collapses the type axis into a logging feature. Logging supports detection and accounting, but a blocking rule's primary security effect is prevention. Calling the firewall rule corrective because someone opens an incident ticket after a block misreads corrective controls: corrective work remediates or restores after harm (rebuilds, patches applied post-incident, restoration from backup). A standing deny rule is not that remediation. Treating the SIEM alert as preventive because analysts might later stop future attacks confuses a detective signal with downstream response; the alert itself does not prevent the matching event that already occurred.

Exam caveat: Security+ expects you to classify the control as deployed, not the hypothetical future use of its output. "Might help later" does not convert detective into preventive.

Operational check: in municipal runbooks, document firewall denies as preventive network controls and SIEM use-cases as detective monitoring. When tuning, verify that critical block rules actually drop traffic and that alerts fire on the right fields—then separately define response playbooks that turn detections into corrective or containment actions.