A retail analytics platform runs two kinds of work against a single BigQuery Enterprise edition reservation: hourly analyst dashboards that must return within a few seconds, and large nightly transformation jobs that build reporting tables and can tolerate delays of up to several hours but must never be cancelled. During busy periods the nightly jobs and the dashboards compete for the same slots, and the dashboards slow down or fail with resource errors. The platform owner wants the nightly work to step back when the reservation is busy and wait its turn, while preserving low-latency capacity for the dashboards, without buying additional baseline slots. Which TWO workload-organisation choices, taken together, manage the job priority and the cost as required? (Select TWO.)
- ASubmit the nightly transformation jobs as interactive jobs so they execute immediately, then schedule them to start an hour before the dashboards so they finish before the analyst window opens.
- BMove the dashboards and the nightly jobs onto separate on-demand projects so each is billed per byte scanned, removing the shared reservation and therefore the contention between the two workloads entirely.
- CSubmit the nightly transformation jobs as batch jobs so BigQuery queues them when the reservation is fully utilised and runs them when capacity frees up, instead of having them contend with interactive dashboards. Correct
- DSet the reservation's baseline slots higher so the nightly jobs always have dedicated capacity, and leave the dashboards to autoscale above that baseline whenever they need more slots.
- EKeep the dashboards as interactive jobs on the reservation so they are served immediately and can autoscale to meet their latency target while the queued nightly work waits. Correct
Why A is wrong: Running the heavy transformations as interactive jobs is tempting because they would start without queuing, but interactive jobs compete directly for slots and would still collide with any dashboards that overlap, and scheduling earlier does not stop the contention when runs overrun their window.
Why B is wrong: Splitting onto on-demand pricing does isolate the workloads, but it abandons the reservation the team is paying for, makes cost unpredictable for large nightly scans, and the requirement is to organise work within the existing reservation rather than leave Editions pricing.
Why C is correct: Classifying the tolerant nightly work as batch jobs makes BigQuery hold them in a queue rather than fail or compete when the reservation is saturated, so they yield to interactive demand and run once slots are free, which is exactly the step-back behaviour the dashboards need.
Why D is wrong: Raising the baseline would guarantee capacity, but it directly contradicts the constraint of not buying additional baseline slots and would increase committed cost rather than reorganising the existing work around priority.
Why E is correct: Leaving the dashboards classified as interactive means they are admitted and served without queuing and can draw on autoscaled slots to hit their latency target, which pairs with batching the nightly jobs so the two workloads no longer compete for the same capacity.