Laying out projects, datasets, and tables so governance holds up

In BigQuery, governance is enforced through a resource hierarchy, organization, folder, project, dataset, table, where each level can carry IAM bindings, labels, and policies that cascade downward. Good architecture separates workloads (e.g., raw/staging/curated, or prod/dev/sensitive-PII) into distinct projects or datasets so that access control, cost tracking, and compliance boundaries align with business and regulatory requirements.

1 · Learn the must-know

• 1A dataset's location (region or multi-region) is set at creation and cannot be changed afterward, so choosing the wrong location means recreating the dataset and copying data.
• 2IAM roles can be granted at the organization, folder, project, dataset, table, or view level, and BigQuery also supports column-level security via policy tags and row-level security via row access policies for finer-grained governance.
• 3Separating sensitive or regulated data into its own project or dataset (rather than relying only on table-level permissions) simplifies auditing, key management (CMEK), and access reviews.
• 4Authorized views and authorized datasets let you grant query access to derived/aggregated data without granting underlying table access, supporting least-privilege design.
• 5Labels on projects, datasets, and tables (not tags) are the mechanism for cost allocation, data classification, and governance metadata, and they propagate into billing exports for chargeback/showback.
• 6Using separate projects per environment or team (rather than one large shared project) aligns quota, billing, and IAM boundaries with organizational structure and reduces blast radius for misconfigured permissions.

2 · Check your understanding