Attackers might try to silence AI cost and abuse alerts. Which control best protects the monitoring pipeline itself?
Select an answer to reveal the explanation.
Short Explanation
If one person can kill the siren, the thief wins. You need dual control on the monitoring and alerting config itself so alerts aren't quietly turned off — just controlling who can view dashboards or export log archives won't stop that. Requiring dual control to retain AI monitoring and alerting event history after the fact doesn't stop the mute either.
Full Explanation
Attackers who want to silence AI cost and abuse alerts will target the monitoring pipeline itself, so requiring dual control to change AI monitoring and alerting configurations best protects that pipeline. Dual control (two-person approval, change tickets plus peer review, or break-glass with monitoring) prevents a single compromised developer or malicious insider from muting detections that would reveal scrapers, prompt floods, or spend attacks. Municipal AI services need the same change discipline for alert rules that traditional SIEM content receives—otherwise visibility is theater until someone turns it off. Protecting configs, repos, and viewing access to dashboards is useful hygiene, but requiring dual control just to view dashboards does not prevent alert silencing, so monitoring-pipeline change control is part of detection engineering, not optional hygiene.
Requiring dual control to view AI monitoring and alerting dashboards fails because it protects read-only viewing, not the alerting path—an attacker who can still edit monitoring config alone can mute cost and abuse detections even if viewing requires approval. Requiring dual control to export AI monitoring and alerting log archives fails because it protects log export, not the alerting path—an attacker who cannot export archives can still silence the alerts that would reveal the attack by editing monitoring config alone. Requiring dual control to retain AI monitoring and alerting event history fails because retention preserves history after the fact but does nothing to stop the mute from taking effect—an attacker can still change the live alerting configuration before anyone reviews the retained history.
Exam caveat: Dual control must apply to the monitoring and alerting configuration itself, with approval required before a change takes effect—requiring dual control to export AI monitoring and alerting log archives alone, or only requiring dual control to retain AI monitoring and alerting event history after they happen, both leave the alert-muting path open.
Operational check: Require dual approval for AI monitoring/alerting configuration changes specifically, before they take effect; lock monitoring repos to reviewed PRs; require dual control to view AI monitoring and alerting dashboards as separate viewing hygiene without treating it as monitoring protection; alert on alert-rule deletions; and after false positives, tune rather than disable permanently.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.