Secure BigQuery Data Sharing with Authorized Views

PDE By islever Editorial Last updated

Maintaining awareness of failures and mitigating impact. Designing for a data platform.

Short answer

D Create authorized views for each team in separate datasets and assign data viewer access to those datasets, following the Hub-and-Spoke pattern for secure BigQuery data sharing.

Question

You are migrating your data warehouse to BigQuery. You have migrated all of your data into tables in a dataset. Multiple users from your organization will be using
the data. They should only see certain tables based on their team membership. How should you set user permissions?
  1. Assign the users/groups data viewer access at the table level for each table
  2. Create SQL views for each team in the same dataset in which the data resides, and assign the users/groups data viewer access to the SQL views
  3. Create authorized views for each team in the same dataset in which the data resides, and assign the users/groups data viewer access to the authorized views
  4. Create authorized views for each team in datasets created for each team. Assign the authorized views data viewer access to the dataset in which the data resides. Assign the users/groups data viewer access to the datasets in which the authorized views reside Correct Answer

Key Takeaways

The main trap is placing views in the same dataset as the source data; the correct pattern uses separate 'spoke' datasets for views to ensure strict isolation and simplified permissions.

Learn how to securely share BigQuery data with specific teams using authorized views and separate datasets, implementing the Hub-and-Spoke pattern for optimal access control.

Common mistake: Choosing Option B or C because they seem simpler. However, placing views in the same dataset as source data risks accidental exposure of underlying tables and violates the recommended separation of concerns for multi-tenant access.

Expert Analysis

The correct approach is Option D. The core constraint in this scenario is that users must only see certain tables based on team membership, implying a need for strict data isolation and secure access control without granting direct table permissions.

Why Option D is Correct: Google’s recommended architecture for sharing BigQuery data securely is the Hub-and-Spoke pattern. This involves:

  1. Source Dataset (Hub): Contains the raw data tables. Access is restricted to specific roles (e.g., Data Engineers).
  2. Reporting Datasets (Spokes): Separate datasets created for each team or consumer group.
  3. Authorized Views: Views are created within the Reporting Datasets but are authorized to query the Source Dataset.
  4. Access Control: Users are granted BigQuery Data Viewer access to the Reporting Dataset (which contains the view), but not to the Source Dataset. Because the view is authorized, it can query the source data transparently. This ensures users only see what the view exposes.

Why Other Options Fail:

  • Option A: Assigning table-level permissions directly violates the principle of least privilege if multiple users need access to different subsets of the same dataset. It also becomes unmanageable at scale and doesn't provide row/column level security easily. More importantly, the question implies a structured governance model.
  • Option B: Creating views in the same dataset as the source data is problematic. If users have viewer access to the dataset containing the views, they might potentially access other tables in that same dataset unless granular object-level ACLs are perfectly configured, which is complex and error-prone. The official best practice strongly recommends separating views into distinct datasets.
  • Option C: Similar to B, keeping authorized views in the same dataset as the source data mixes operational and reporting concerns. While technically possible with strict IAM, it is not the recommended scalable pattern for multi-tenant access control as described in Google Cloud documentation.

Key Insight: The phrase "authorized views" combined with "datasets created for each team" points directly to the Hub-and-Spoke model. The key is that the view resides in the user's dataset, not the source dataset. This isolates the consumer from the source infrastructure.

Official Reference

https://cloud.google.com/bigquery/docs/share-access-views

This link opens the official vendor documentation in a new tab.

Exam Strategy

When asked about sharing data securely in BigQuery, always look for solutions that involve 'authorized views' and 'separate datasets'. Avoid options that place views in the same dataset as the source data unless explicitly stated otherwise. Remember the Hub-and-Spoke pattern: Source Data in one dataset, Views in separate datasets per consumer group.

Frequently Asked Questions

What is the Hub-and-Spoke pattern in BigQuery?

It is an architectural pattern where source data resides in a central 'hub' dataset, and consumer-specific views are created in separate 'spoke' datasets. This allows controlled access to data without granting direct table permissions.

Why can't I just use table-level permissions (Option A)?

While table-level permissions are possible, they become difficult to manage at scale and don't provide the same level of abstraction and security isolation as authorized views in separate datasets. They also don't support row/column filtering natively.

Do users need access to the source dataset?

No. Users should only have access to the dataset containing the authorized views. The view itself is authorized to query the source dataset, allowing users to see the results without knowing the underlying table structure or having direct access.

More PDE FAQ →

Community Votes

D
47%
A
41%
C
12%

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

Discussion 62 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 62

  1. someshsehgal 👍 41
    Correct A: A . Now it is feasible to provide table level access to user by allowing user to query single table and no other table will be visible to user in same dataset.
  2. madhu1171 👍 27
    D should be the answer
  3. hdmi_switch 👍 14
    Back then D, now A. Question is, if the exam is already up to date.
  4. jits1984 👍 12
    Should still be D. Question states - "They should only see certain tables based on their team membership" Option A states - Assign the users/groups data viewer access at the table level for each table With A, everyone will see every table. Hence D.
  5. rickywck 👍 9
    Yes, should be D: https://cloud.google.com/bigquery/docs/share-access-views
Show 25 more comments
  1. squishy_fishy 👍 8
    It is possible for about a year now. https://cloud.google.com/bigquery/docs/table-access-controls-intro#example_use_case
  2. dambilwa 👍 6
    Option [D] - has to be the Answer
  3. norwayping 👍 6
    Sorry, it should be D
  4. Rajokkiyam 👍 6
    Answer D
  5. MaxNRG 👍 5 Answered D
    https://cloud.google.com/solutions/migration/dw2bq/dw-bq-data-governance When you create the view, it must be created in a dataset separate from the source data queried by the view. Because you can assign access controls only at the dataset level, if the view is created in the same dataset as the source data, your users would have access to both the view and the data. https://cloud.google.com/bigquery/docs/authorized-views This approach aligns with the Google Cloud best practices for data governance, ensuring that users can only access the data intended for them without having direct access to the source tables. Authorized views serve as a secure interface to the underlying data, and by placing these views in separate datasets per team, you can manage permissions effectively at the dataset level.
  6. apnu 👍 5
    both A and D are correct , now we have option to share the table with user and group. in this case as billiability is not a concern so I would go with A.
  7. John_Pongthorn 👍 4 Answered A
    It has nothing to do with authorize view because of the following Authorized views make use of query results but this question emphasise on Table level https://cloud.google.com/bigquery/docs/authorized-views An authorized view lets you share query results with particular users and groups without giving them access to the underlying source data.
  8. Unmesh93 👍 4
    A Description Big query now supports access st Table level. https://cloud.google.com/bigquery/docs/table-access-controls-intro
  9. clouditis 👍 4
    D looks correct
  10. cetanx 👍 3
    According to Chat GPT, it is also D. And it explains why it shouldn't be "A" as; Granularity: While you can assign access permissions at the table level, it doesn't allow for fine-grained access control. For example, if you want to restrict access to certain columns or rows within a table based on user or group, table-level permissions would not be sufficient. Scalability: In organizations with many tables and users, managing permissions at the table level can quickly become unwieldy. You would need to individually set permissions for each user for each table, which can be time-consuming and error-prone. Security: Table-level permissions expose the entire table to a user or a group. If the data in the table changes over time, users might get access to data they shouldn't see. With authorized views, you have more control over what data is exposed. Maintenance: If the structure of your data changes (for instance, if tables are added or removed, or if the schema of a table changes), you would need to manually update the permissions for each affected table.
  11. kped21 👍 3
    A - as per latest BigQuery table ACL lets you set table-level permissions on resources like tables and views. Table-level permissions determine the users, groups, and service accounts that can access a table or view. You can give a user access to specific tables or views without giving the user access to the complete dataset. For example, grant the role BigQuery Data Viewer (roles/bigquery.dataViewer) to a user to let that user query just the table or view without full dataset access.
  12. Pupina 👍 3
    Tables are in one dataset but the autorized view can be in a different new dataset. One for each user simplifying the number of binding policies used or all the views in one dataset. Both eschemas has pros and cons. Need to understand whtat this question is wanting us to answer. Cannot be A because it is not a best practice. I prefer D over than C because reduce administration but the on the other hand the views cannot be re-used.
  13. federicohi 👍 3
    THe tables were saved in only 1 dATASET so the answer is C not D because D is for many datasets " You have migrated all of your data into tables in a dataset. " This mains clear that is only one. Answer D but now may be A its possible too because i are able to gice access at table level.
  14. kishanu 👍 3
    I would go with D. Though A seems to be feasible, there could be numerous tables under a dataset, and to provide access to the users could be a cumbersome process. Instead, create datasets for multiple groups(so-called teams), and assign access policies to them.
  15. daghayeghi 👍 3
    D: main point is that you can't give table level access for users and when you give access to a Dataset, user have access to all of data in it. then you should create new Datasets and view for each group and give view access for each of groups.
  16. ashuchip 👍 3
    A . we have now the feasibility to provide table level access to user with acl permission bigquery.dataviewer. it will allow user to query single table and no other table willl be visible to user in same dataset.
  17. plum21 👍 3 Answered D
    The question was created at the time when it was not possible to share data on table level (dataset was the only option). At that time D was possible only. Right now A is feasible as well.
  18. squishy_fishy 👍 3
    There is only one dataset mentioned in the question here. "You have migrated all of your data into tables in a dataset"
  19. medeis_jar 👍 3 Answered A
    A, since we just deal with permission to data and not give access to a subset of data.
  20. vakati 👍 3
    A. seems relevant now
  21. dsyouness 👍 3 Answered D
    Should be D.
  22. mAbreu 👍 2
    yes, should be D: https://cloud.google.com/bigquery/docs/share-access-views Create a separate dataset to store your view After creating your source dataset you create a new dataset to store the view you will share with your data analysts. This view will have access to the data in the source dataset. Your data analysts will have access to the view, not the source data.
  23. postbox4643 👍 2 Answered D
    Why Option D is the Best Fit In BigQuery, simply creating a view isn't enough to grant access to the underlying data. If a user has access to a view but not the source table, the query will fail. An Authorized View solves this by allowing the view itself to "authorize" access to the source data, even if the user doesn't have direct access to those tables.
  24. John_Pongthorn 👍 2 Answered A
    https://cloud.google.com/bigquery/docs/table-access-controls-intro Don't think too much ,there is nothing to do with view, the question refer to table obviousely. Assume that User see certain table so he can see everything in such a table
  25. spicebits 👍 2
    A is the best answer for security as stated in the documentation - https://cloud.google.com/bigquery/docs/row-level-security-intro#comparison_of_authorized_views_row-level_security_and_separate_tables

Reader comments & corrections

No reader corrections 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.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

Bigtable Row Key Design for Time-Series Data

S-grade

Monitoring Cloud Bigtable for Cluster Scaling Decisions

S-grade

← Back to PDE Study Guide