A data platform team runs interactive analytics on a single BigQuery Enterprise edition reservation that has autoscaling enabled up to a high maximum. Last week an unreviewed analyst query joined two very large tables without a filter, drove the reservation to its maximum slot ceiling for over an hour, and inflated the daily bill before anyone noticed. The team wants an observability setup that both detects sustained slot saturation early and surfaces the specific jobs responsible so a runaway query can be caught and cancelled before it consumes a full hour of autoscaled capacity. Which TWO observability steps, taken together, best detect and help prevent this kind of runaway workload? (Select TWO.)
- ACreate a Cloud Logging sink that exports all BigQuery data access audit logs to Cloud Storage with a 400-day retention policy, so the team has a durable archive to review when a future billing anomaly is reported.
- BLower the BigQuery maximum bytes billed quota for the project to a value below the largest legitimate query, so any query scanning more data than that is rejected before it can run and consume slots.
- CBuild a Cloud Monitoring alerting policy on the BigQuery slots allocated metric for the reservation that fires when allocated slots stay near the configured maximum for a sustained window, notifying the on-call channel. Correct
- DSchedule a daily query against the INFORMATION_SCHEMA.JOBS view that emails a ranked list of yesterday's most expensive jobs, so the team can identify and follow up with the analyst who ran the heaviest query.
- EQuery the INFORMATION_SCHEMA.JOBS_BY_PROJECT view filtered to currently running jobs ordered by slot milliseconds consumed, so on-call can identify the live job dominating the reservation and cancel it. Correct
Why A is wrong: A long-retention audit log archive is useful for forensic review, but it is a passive store that no one inspects until after an anomaly is already reported, so it neither detects sustained saturation early nor helps cancel a query mid-run.
Why B is wrong: Setting maximum bytes billed can cap a single oversized scan, but a value low enough to block the runaway join would also reject many legitimate large queries, and bytes scanned is a poor proxy for slot saturation on a reservation, so it does not reliably target the problem.
Why C is correct: An alerting policy on the reservation slot usage metric in Cloud Monitoring detects sustained saturation against the maximum in near real time and pages the team while the workload is still running, which is the early-warning half of catching a runaway query before it consumes a full hour.
Why D is wrong: A daily ranked report does correctly surface heavy jobs from INFORMATION_SCHEMA, but it runs after the fact on yesterday's data, so it identifies the culprit a day late rather than while the runaway query is still cancellable.
Why E is correct: Querying JOBS_BY_PROJECT for jobs in the running state ordered by slot consumption surfaces the specific live job saturating the reservation, which is exactly the information on-call needs to cancel the runaway query before it runs for an hour, complementing the saturation alert.