To detect anomalous behavior by windowing and aggregating data over time and provide an interface for analysts to triage, which architecture is recommended?

• A. Cloud SQL + scheduled Cloud Run query + Pub/Sub notifications.
• B. Sink logs to BigQuery; Cloud Run functions to execute periodic jobs that generate normalized alerts to Pub/Sub; use log-based metrics; write alerts as SCC findings.
• C. Use log-based metrics with Cloud Monitoring alert policies sending emails.
• D. Aggregated log sinks to Cloud Storage with alerts on write events.

Answer: (B)

The key idea is to enable time-based anomaly detection with stored, queryable history and a single, actionable triage surface for analysts. Storing logs in a centralized analytical store lets you perform windowed calculations over moving timeframes (for example, 5-minute, hourly, or daily windows) to spot deviations from normal patterns. By using Cloud Run to run periodic jobs that compute these aggregates and emit standardized alerts to Pub/Sub, you create a consistent, scalable workflow that produces normalized alerts with the same structure regardless of the source data. This normalization is crucial for effective triage, because analysts can filter, correlate, and drill down using a common schema.

In addition, leveraging log-based metrics in Cloud Monitoring provides lightweight, near-real-time signal generation, but the more powerful capability here is the ability to express complex time-based detections over large histories in BigQuery. Writing alerts as Security Command Center findings gives analysts a centralized, familiar interface for reviewing, prioritizing, and coordinating responses, rather than scattering alerts across emails or disparate dashboards. This combination—structured long-term storage for flexible windowed analysis, a normalized alerting pipeline, and a centralized triage surface—best supports detecting anomalous behavior over time and enabling efficient analyst triage.

Other approaches fall short because they either rely on less scalable storage for heavy log data, lack flexible windowing and normalization, or don’t provide a unified, triage-friendly interface (for example, simple email alerts or storage-only pipelines without a centralized findings view).