How does a BigQuery authorized view give a team query access without access to the source tables?

## The problem it solves BigQuery access control is resource-scoped: you grant roles on a project, a dataset, or an individual table. A plain view stores only a query, so when a user selects from it, BigQuery evaluates that query as *them* — and they need read permission on every table it touches. That makes a plain view useless as a security boundary, because anyone who can query the view could equally query the raw table directly. ## How authorization works An authorized view inverts the check. The view is registered as a trusted principal on the dataset that holds the source data. From then on, the view's own identity carries the read permission, and the caller does not need any grant on the source dataset at all. In classic database terms this is definer's rights rather than invoker's rights: the query runs with the authority of the object, not the person. Two consequences follow directly. First, the view **must live in a different dataset from the data it reads** — if it sat in the same dataset, anyone who could read the view could already read the tables, and nothing would be gained. Second, whoever can *edit* the view can rewrite it to select anything in the source dataset, so edit rights on the view's dataset are as sensitive as read rights on the raw data. ## Setting one up Three moves: 1. Create the view in a serving dataset: `CREATE VIEW reporting.orders_public AS SELECT order_id, region, total FROM raw.orders WHERE deleted_at IS NULL;` 2. Add that view to the `raw` dataset's access list as an authorized view (console, Terraform, or `bq update --source` with the dataset's JSON). 3. Grant your consumers a reader role on `reporting` only, plus the ability to run jobs in whatever project pays for the queries. ## Authorized datasets and routines Managing a per-view entry on the source dataset does not scale past a handful. Authorizing an entire dataset makes every view inside it trusted, so adding a new curated view is a one-step operation. The same mechanism extends to routines — an authorized UDF or stored procedure can read source data that its caller cannot, which is how you expose a computation rather than a result set. ## What it does not solve **Cost.** Query jobs are billed to the project where the job runs — the reader's project — and the bytes billed are the bytes the underlying scan reads. A view is not a cache. Selecting three columns instead of thirty genuinely reduces bytes read because BigQuery is columnar, but the view itself adds no saving and adds no acceleration. **Freshness or performance.** A view is re-executed every time. If the exposed slice is expensive, materialize it — either as a scheduled table or a materialized view — and authorize that instead. **Per-user filtering.** One view exposes one fixed slice. If ten teams each need a different subset of rows, ten views is a maintenance problem; a row access policy on the base table expresses the same thing once. The historical trick is to filter inside the view with `SESSION_USER()` against a mapping table, which still works, but row-level security is the purpose-built answer. **Column-level governance.** Hiding a column by omitting it from the SELECT is only as good as your review process. Tagging the column in a taxonomy and requiring a fine-grained reader role enforces it wherever the column is read, including from tables you forget about. ## Pitfalls worth naming in an interview `SELECT *` in an authorized view is a slow-motion leak: add a sensitive column to the base table and it appears in the view without anyone deciding to publish it. Always enumerate columns. If the view's creator loses access to the source data, the view keeps working — the trust is on the view object, not the human — which is usually what you want but surprises people who expect it to break. Cross-project works fine; the view and the data can be in different projects as long as both are in the same location. Finally, an authorized view is a *read* surface. Users still cannot write, and anything that copies the view's output into a table under a broader identity re-opens whatever the view was hiding.