BigQuery cost control comes up on the Associate Cloud Engineer exam in a small set of distinct patterns. This article covers the three things you need to know. Custom quotas, the on-demand vs flat-rate pricing distinction (which Google now packages as editions), and dry runs for estimating query cost before running.
It does not cover the deep economics of slot reservations, autoscaling slot policies, or cross-project billing. Those matter in a real BigQuery deployment but are not what the ACE exam tests.
BigQuery has historically had two pricing models for query compute. On-demand and flat-rate.
On-demand pricing charges you based on the bytes processed by each query. Run a query that scans 1 TB, you pay for 1 TB. Run no queries, you pay nothing for compute (you still pay for storage). This is the default and it works well for unpredictable or low-volume workloads.
Flat-rate pricing is the alternative. You pay a fixed monthly amount in exchange for a reserved pool of "slots", which are BigQuery's unit of compute. You can run as many queries as you want against your reserved slots without additional per-query charges. This is better when you have a predictable, high-volume workload and want a flat, predictable bill.
Google has rebranded flat-rate pricing as "BigQuery editions". There are now three tiers. Standard, Enterprise, and Enterprise Plus. They differ in features (security, governance, cross-region capabilities) and in what kinds of slot commitments are available. For the Associate Cloud Engineer exam, the high-level distinction between on-demand and flat-rate (now editions) is what matters more than the tier names.
Quotas are how you put a hard cap on BigQuery spending or usage. You set a custom query quota, and BigQuery refuses to run queries that would exceed it.
Quotas can be set at the user level or the project level. User-level quotas prevent one person from blowing through the whole budget on a single bad query. Project-level quotas cap total spend across everyone using that project. Both are useful, and they stack.
The most common quota in practice is "maximum bytes billed per day" at the project level. It is the safety net that prevents a runaway query or an automated job gone wrong from generating a five-figure bill. If you only remember one thing about quotas for the exam, it is that they exist as a guardrail and they are configurable per user or per project.
A dry run is a way to ask BigQuery "if I ran this query, how much data would it process?" without actually running it. The dry run returns the byte estimate. You then decide whether to proceed.
This matters because BigQuery's on-demand pricing is based on bytes processed. A query that scans the wrong table or forgets a partition filter can scan terabytes when you expected gigabytes. The dry run catches that before you incur the charge.
From the bq CLI:
bq query --dry_run --use_legacy_sql=false \
'SELECT * FROM `my_project.my_dataset.my_table` WHERE date = "2026-01-01"'The output tells you how many bytes the query would process. The BigQuery web UI shows the same estimate in real time as you type, next to the Run button.
The Associate Cloud Engineer exam presents these three controls in distinct scenarios. The scenarios are usually pretty clean.
If a scenario describes a team that wants to prevent any single user from accidentally racking up a huge bill, the answer is custom quotas at the user level. If the concern is total project spend, project-level quotas are the answer.
If a scenario describes a team with predictable, high-volume query workloads who wants cost predictability, the answer is flat-rate pricing (or BigQuery editions in the newer phrasing). If a scenario describes a team that wants to estimate the cost of a query before running it, the answer is a dry run.
If you see "predictable monthly bill" plus "high query volume" in a scenario, think flat-rate. If you see "estimate before running", think dry run. If you see "prevent overspending", think quotas.
Quotas, flat-rate pricing, and dry runs are cost control mechanisms. They are different from query optimization techniques like partitioning, clustering, or rewriting queries to scan less data. The ACE exam mostly tests the cost control mechanisms, not query optimization. If a question gives you the option of partitioning a table to reduce future query cost versus setting a quota to prevent overspending, read the question carefully. Both can be correct depending on what is being asked.
BigQuery has three levers for cost control on the Associate Cloud Engineer exam. Custom quotas put a hard cap on usage at the user or project level. Flat-rate pricing (now editions) trades the per-query model for a predictable monthly bill backed by reserved slots. Dry runs let you preview how much data a query would process before you commit to running it.
Match the lever to the problem. Quotas for guardrails. Flat-rate for predictability at high volume. Dry runs for one-off estimation.
My Associate Cloud Engineer course covers all three in the BigQuery section, plus how they connect to the on-demand pricing model and the BigQuery admin console.
