A county cloud operations desk wants early warning when audit API calls and VPC flow patterns look abnormal across multi-cloud accounts. Which approach best supports detecting suspicious activity?
Select an answer to reveal the explanation.
Short Explanation
Waiting for someone to file a ticket is like waiting for the fire alarm after the building is already smoky. SIEM-style dashboards that watch audit trails and network events catch weird spikes before the help desk lights up. County clouds generate tons of breadcrumbs—use them.
Full Explanation
A county cloud operations desk that needs early warning when audit API calls and VPC flow patterns look abnormal across multi-cloud accounts should aggregate those cloud audit and network events into SIEM-like views that highlight anomalies. Continuous collection of control-plane audit telemetry and data-plane flow data is what turns raw provider logs into detection for suspicious activity against civic accounts. Reviewing firewall rule spreadsheets once per year during the budget cycle is a compliance hygiene task, not near-real-time intrusion detection. Relying only on end-user complaint tickets waits until citizens or staff already feel impact. Disabling cloud audit logging to reduce storage cost during quiet months removes the evidence stream that investigators and automated detectors need. Exam caveat: enabling logs is necessary but not sufficient—retention, correlation, alerting thresholds, and playbooks complete the municipal detection capability; SIEM-style aggregation is the analysis layer, not a replacement for preventive controls. Operational check: verify audit trails and flow logs are on in every account, confirm events land in the central view within the expected delay, fire a test anomaly alert, and ensure on-call can start an investigation from a civic account without waiting for a help-desk ticket. Document which multi-cloud sources feed the SIEM in the operations runbook.