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.

Must-know

• A 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.
• IAM 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.
• Separating 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.
• Authorized views and authorized datasets let you grant query access to derived/aggregated data without granting underlying table access, supporting least-privilege design.
• Labels 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.
• Using 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.

Coverage checked against the published exam guide on Aug 11, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.