A 311 platform needs to notice if GenAI service roles suddenly pull unusually large volumes of resident case data. Which monitoring approach best supports that data-security goal?
Select an answer to reveal the explanation.
Short Explanation
Bulk grabs look like someone photocopying the whole filing cabinet at 2 a.m.—you want a motion light, not next year’s audit binder. CloudWatch anomalies on GenAI roles give 311 that motion light.
Full Explanation
Monitoring CloudWatch for anomalous bulk data-access patterns from GenAI roles and alerting operators best supports the 311 platform’s goal of noticing sudden large pulls of resident case data. GenAI service roles that call S3, databases, or APIs should emit volume and error metrics; alarms on unusual GetObject counts, bytes transferred, or query fan-out give near-real-time signal when a compromised bot, runaway agent loop, or malicious prompt drives exfiltration-scale reads of case files.
Turning off CloudWatch metrics to reduce noise during storms and elections removes visibility exactly when 311 load—and attacker opportunity—may peak. Reviewing access only during annual audits provides no near-real-time detection of bulk pulls; exfiltration can complete months before the next audit. Allowing unlimited GetObject loops as long as the FM eventually answers the resident prioritizes answer completion over data-security telemetry and ignores volume as a threat signal.
Exam caveat: data security for GenAI includes monitoring the data plane around FM roles, not only content filters on prompts. AIP-style questions often expect CloudWatch (or equivalent) anomaly/alerting on bulk access as the operational control.
Operational check: define baseline read volumes for 311 GenAI roles, create CloudWatch alarms for sustained spikes, route pages to the municipal SOC or platform on-call, test with a synthetic bulk-read drill, and document suppressions so storm-related load does not silently disable detection.