Professional Security Operations Engineer — Practice Questions and Mock Exam

The Health Hub exposes the 95th percentile of the delta between Last Event Time (when the event occurred at source) and Last Ingested (when SecOps received it). A high delta suggests pipeline latency within the SecOps ingestion path, while a normal delta may indicate the source is pushing older or historical data (ref: docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). This metric directly answers whether ingestion delay is a pipeline issue or a source-side issue. Why not the others? Total Ingested Logs count measures volume, not latency. Config Last Updated helps correlate configuration changes with failures but doesn't measure delay. Parser errors per hour indicate parsing health, not ingestion timing. The Last Event Time vs. Last Ingested delta is the definitive latency diagnostic.

In YARA-L 2.0, zero values (empty strings, 0, false) are NOT automatically filtered for all fields. The Rules Engine implicitly filters zero values only for placeholders in the match section; other event fields require explicit exclusion with != "" (ref: docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Without $e.principal.user.userid != "", omitted userid fields default to "" and create false positive matches. This is a documented best practice for reducing false positives. Why not the others? Automatic filtering does NOT apply universally — only match section placeholders get implicit zero-value exclusion (ref: docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Moving a field to the outcome section doesn't prevent matching on empty values in events. The nocase modifier changes case sensitivity, not null handling.

To detect log source failures, create a Cloud Monitoring alert policy using the Chronicle Collector > Ingestion > Total ingested log count (or Total ingested log size) metric with a Metric absence condition. This triggers when no data is received for a specified duration (ref: docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). The documented setup: select the ingestion metric, group by collector_id, set Rolling window up to 1 hour, and configure Metric absence as the condition type with a trigger absence time. Why not the others? Pub/Sub backlog monitors queue depth, not SecOps-specific ingestion. Compute Engine CPU dropping to zero is unreliable and doesn't directly indicate log flow stoppage. Cloud Logging entries/second measures Cloud Logging throughput, not SecOps ingestion health specifically.