Network sensors in front of cloud workloads detect exploit traffic and can block matching attack patterns. Which controls fill those detect and block roles?
Select an answer to reveal the explanation.
Short Explanation
IDS is the smoke alarm that notices exploit traffic; IPS is the sprinkler that can stop it midstream. Together they watch (and sometimes block) bad patterns aimed at cloud workloads. Paper quizzes, homepage banners, and tape alone do not inspect live packets.
Full Explanation
Intrusion detection and prevention systems monitor network or host traffic for exploit patterns; IDS detects/alerts while IPS can block matching attack traffic. Sensors in front of cloud workloads that detect exploit traffic and can block matching patterns fill those IDS/IPS roles for municipal defenses. They add runtime threat controls beyond static questionnaires.
Only monthly paper vulnerability questionnaires provide no runtime network inspection. Static marketing banners on the citizen portal homepage are not intrusion controls. Offline tape backups without traffic analysis address recovery, not inline exploit detection/blocking.
Exam caveat: IDS vs IPS distinction (detect vs block) is classic exam material; placement (network vs host) and signature/anomaly methods may also appear. IPS false positives can deny legitimate traffic—tune carefully.
Operational check: enable IDS/IPS or cloud threat detection equivalent on citizen-facing segments, verify alerts fire on test signatures in non-prod, decide block vs alert modes per tier, and integrate alerts into the SOC queue. Review weekly hits affecting municipal applications.
Feed IDS/IPS high-fidelity alerts into the same incident process used for vuln exploitation tickets, so municipal responders treat active exploit traffic with the same seriousness as critical CVE backlog items.