Monitoring BigQuery Slot Usage and Query Quotas for the PDE Exam

One of the more practical sections of the Professional Data Engineer exam tests whether you actually know how to keep an eye on BigQuery compute. It is not enough to remember that slots exist or that reservations are a thing. The exam pushes on whether you can pick the right metric, the right quota, and the right pricing posture for a given workload. I want to walk through how I prepare candidates for this material, because it tends to show up in scenario questions that look easy until you realize two of the four answers are technically valid.

The core idea is that BigQuery compute is measured in slots, and slots are a finite resource you either pay for on-demand or reserve in advance. Either way, you need visibility into what your project is consuming so you can right-size your reservations and catch runaway queries before they shock the bill.

Slot metrics in Cloud Monitoring

Cloud Monitoring exposes several BigQuery slot metrics, and the exam expects you to know which one answers which question. The four that come up most often are:

• slots/allocated tracks slot usage broken out by project, reservation, and job type. This is the broad lens, useful when you want one chart that shows everything at once.
• slots/allocated_for_project rolls usage up to the project level. Use this when you want a single number per project without further breakdown.
• slots/allocated_for_project_and_job_type splits usage by project and job type, so you can see whether your slot consumption is dominated by queries, load jobs, or something else.
• slots/allocated_for_reservation shows slot usage inside a specific reservation. This is the one you reach for when you want to know if a reservation is sized correctly.

A common exam framing is something like: a team wants to know whether their production reservation is underutilized. The right metric is slots/allocated_for_reservation, not the project-level one, because the project-level metric will include any on-demand work that is happening outside the reservation.

INFORMATION_SCHEMA for query-level detail

Cloud Monitoring is great for trend lines, but when you need per-job detail you go to the INFORMATION_SCHEMA views. The ones to know are JOBS_BY_PROJECT, JOBS_BY_USER, JOBS_BY_FOLDER, and JOBS_BY_ORGANIZATION. Each view has the same shape but a different scope of visibility.

A typical pattern for finding expensive jobs looks like this:

SELECT
  job_id,
  user_email,
  total_slot_ms,
  total_bytes_processed,
  creation_time
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND job_type = 'QUERY'
ORDER BY total_slot_ms DESC
LIMIT 20

The Professional Data Engineer exam likes to test whether you reach for INFORMATION_SCHEMA when the question is about a specific job, and Cloud Monitoring when the question is about a trend over time. Both are valid observability tools. They answer different questions.

The BigQuery admin resource charts in the console also surface slot utilization, capacity utilization, and job concurrency. These are useful for the day-to-day work of tuning reservations, and they show up on the exam as the right answer when a question says something like "the team wants a visual view of slot usage without writing SQL."

Custom query quotas

Slot metrics tell you what is happening. Query quotas let you control what is allowed to happen. These are not slot quotas. They are limits on the number of bytes read or the number of queries run within a specific timeframe.

Two things matter for the exam. First, query quotas can be set at the project level or at the principal level, where the principal is a user or service account. Second, they exist to prevent accidental overspending and to ensure fair resource usage in shared environments. If one analyst writes a query that scans 50 TB by mistake, a bytes-read quota will stop it before it finishes.

When the exam describes a scenario where a single user keeps consuming the project's capacity, the right answer is usually a principal-level query quota. When the scenario describes a whole project consuming too much, it is a project-level quota.

Reservations, autoscaling, and the classic exam question

The capstone scenario for this material on the Professional Data Engineer exam is one I see candidates get wrong all the time. It goes something like this. A company has a critical production application that consistently uses X slots in BigQuery but occasionally spikes to X + Y. How do they guarantee capacity while still optimizing costs?

The wrong answers are "reserve X + Y slots permanently" (over-provisioned) or "run everything on-demand" (no capacity guarantee and unpredictable cost). The right answer is an Enterprise Edition reservation with a baseline of X slots and autoscaling up to Y additional slots. You pay for the baseline you always need, and the autoscaler handles the spikes without you committing to peak capacity around the clock.

Putting it together

The combination strategy that the Professional Data Engineer exam rewards is fairly simple to remember. Use capacity-based pricing with reservations for predictable production workloads. Use on-demand for ad-hoc analytics queries. Layer query quotas on top to cap accidental spend. Then monitor everything continuously with Cloud Monitoring and INFORMATION_SCHEMA so you can adjust as patterns shift.

If a question describes a steady workload and asks how to control cost, think reservations. If it describes one team running expensive ad-hoc queries, think principal-level quotas. If it describes a spike on top of a steady baseline, think baseline plus autoscaling. The exam is consistent about which lever maps to which symptom.

My Professional Data Engineer course covers BigQuery slot monitoring, INFORMATION_SCHEMA queries, reservation strategy, and the exact scenario patterns the exam uses to test this material.