How should you allocate BigQuery reservations for SLA and ad-hoc projects?

You have two projects where you run BigQuery jobs: • One project runs production jobs that have strict completion time SLAs. These are high priority jobs that must have the required compute resources available when needed. These jobs generally never go below a 300 slot utilization, but occasionally spike up an additional 500 slots. • The other project is for users to run ad-hoc analytical queries. This project generally never uses more than 200 slots at a time. You want these ad-hoc queries to be billed based on how much data users scan rather than by slot capacity. You need to ensure that both projects have the appropriate compute resources available. What should you do?

  1. Create a single Enterprise Edition reservation for both projects. Set a baseline of 300 slots. Enable autoscaling up to 700 slots.
  2. Create two reservations, one for each of the projects. For the SLA project, use an Enterprise Edition with a baseline of 300 slots and enable autoscaling up to 500 slots. For the ad-hoc project, configure on-demand billing. Source Reference Answer
  3. Create two Enterprise Edition reservations, one for each of the projects. For the SLA project, set a baseline of 300 slots and enable autoscaling up to 500 slots. For the ad-hoc project, set a reservation baseline of 0 slots and set the ignore idle slots flag to False.
  4. Create two Enterprise Edition reservations, one for each of the projects. For the SLA project, set a baseline of 800 slots. For the ad-hoc project, enable autoscaling up to 200 slots.

Community Votes

B
83%
D
17%

83% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the distinction between slot-based reservation billing and on-demand data-scan billing, and the interpretation of 'additional 500 slots' as autoscaling headroom on top of a 300-slot baseline.

The correct answer is B: create two reservations, using Enterprise Edition with a 300-slot baseline and 500-slot autoscaling for the SLA project, and on-demand billing for ad-hoc queries. Community consensus strongly supports B, with 83% of votes, because ad-hoc queries must be billed by data scanned, not slot capacity.

The most common wrong answer is D, which sets the SLA reservation baseline to 800 slots and gives the ad-hoc project autoscaling slots; this misreads 'additional 500 slots' as total required capacity, and incorrectly applies slot-based billing to ad-hoc queries instead of on-demand billing.

Community Discussion (13 comments)

raaad 👍 11 Selected: B
  • The SLA project gets a dedicated reservation with autoscaling to handle spikes, ensuring it meets its strict completion time SLAs. - The ad-hoc project uses on-demand billing, which means it will be billed based on the amount of data scanned rather than slot capacity, fitting the billing preference for ad-hoc queries.
JyoGCP 👍 5 Selected: B
Option B. Not D because "In Project-2, ad-hoc queries need to be billed based on how much data users scan rather than by slot capacity."
Abizi 👍 1 Selected: B
answer B, because of the pay as you go for the Adhoc projet
ToiToi 👍 2 Selected: B
100% B I work with BQ on a daily basis, did the transition from falt rate to editions last year, have been configuring this for so many customers. Billing for data analysed rather than slots is on demand - so no other option other than B makes sense.
SamuelTsch 👍 2 Selected: B
https://cloud.google.com/bigquery/docs/slots-autoscaling-intro#using_reservations_with_baseline_and_autoscaling_slots says clearly, "Autoscaling slots are only added after all of the baseline slots (and idle slots if applicable) are consumed."
CGS22 👍 3 Selected: B
Separate Reservations: This approach provides tailored resource allocation and billing models to match the distinct needs of each project. SLA Project Reservation: Enterprise Edition: Guarantees consistent slot availability for your production jobs. Baseline of 300 slots: Ensures resources are always available to meet your core usage at a predictable cost. Autoscaling up to 500 slots: Accommodates bursts in workload while controlling costs. Ad-hoc Project On-demand: On-demand billing: Charges based on data scanned, ideal for unpredictable and variable query patterns by your ad-hoc users.
chrissamharris 👍 1 Selected: D
Note, Option A states autoscale "up to" (not an additional) 500 slots, whereas the requirement is 800 slots. Making option D the only viable option.
potatoKiller 👍 3
"You want these ad-hoc queries to be billed based on how much data users scan rather than by slot capacity." So D is out. Choose B
hanoverquay 👍 1 Selected: D
500 (additional) +300 = 800, so answer is D
danisxp 👍 1 Selected: D
Considering the emphasis on strict completion time SLA's.I go with option D. However I think both B and D are not the best solution here.
Matt_108 👍 3 Selected: B
Option B - first project works well with dedicated reservation and autoscaling. The second one requires on demand billing, as per question requires.
ElenaL 👍 3 Selected: D
"These jobs generally never go below a 300 slot utilization, but occasionally spike up an additional 500 slots." -> if it spikes up an ADITIONAL 500 slots, on top of the regular 300, shouldn't we reserve at a minimum 800? open to explanations as to why this is not the case.
scaenruy 👍 3 Selected: B
B. Create two reservations, one for each of the projects. For the SLA project, use an Enterprise Edition with a baseline of 300 slots and enable autoscaling up to 500 slots. For the ad-hoc project, configure on-demand billing.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option B correctly separates the two workloads into dedicated reservations with different billing models. The SLA project needs a baseline of 300 slots to guarantee compute availability for its strict completion-time SLAs, and autoscaling up to 500 additional slots provides headroom for spikes without paying for unused capacity at all times. The ad-hoc project is configured with on-demand billing, which charges based on the amount of data scanned rather than slot capacity, exactly matching the requirement. This also allows each project's resource needs to be managed and billed independently.

Why the Other Options Are Wrong

Option A creates a single shared reservation for both projects, which cannot provide distinct billing for ad-hoc queries and risks the SLA project competing with ad-hoc workloads. Option C uses a reservation with baseline 0 and 'ignore idle slots' for ad-hoc, but this still uses slot-based billing, not data-scan billing. Option D sets the SLA baseline to 800 slots, which is unnecessary because the 300-slot baseline plus 500 autoscaling slots already covers the maximum demand; it also uses autoscaling for the ad-hoc project, which is slot-based and not aligned with the requirement to bill by data scanned.

Community Comment Notes

Comment [1] correctly explains that the SLA project receives a dedicated reservation with autoscaling to meet SLAs, while the ad-hoc project uses on-demand billing for pay-as-you-scan pricing. Comment [6] raises the concern about needing 800 slots total, but as comment [9] clarifies from the official documentation, autoscaling slots are added only after all baseline slots are consumed, so a 300 baseline plus 500 autoscale correctly provides the needed 800 slots. The community overwhelmingly supports B, with one commenter noting real-world experience configuring BigQuery reservations.

Official Reference

Exam Strategy

For BigQuery capacity questions, first identify the billing model required for each workload. If a question says 'billed by data scanned,' the answer must include on-demand billing or query pricing, not slot reservations. Then for reserved slots, always parse whether autoscaling is 'additional' slots on top of a baseline, and ensure the baseline covers typical usage while autoscaling covers spikes.

Related Analysis

← Back to PDE Study Guide