Select appropriate storage systems by analysing data access patterns and choosing among BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore, and Memorystore.

An analytics platform team needs BigQuery to query Parquet files that already live in Cloud Storage, while keeping a single set of fine-grained access controls including row-level filters and column-level masking that match the controls used on native BigQuery tables. The Cloud Storage data must remain the system of record for an external Spark pipeline, and the BigQuery interface must enforce the same policies regardless of whether the query runs from BigQuery or from a connected Dataproc Spark job. Which approach best meets these requirements?

• ACreate BigQuery external tables over the Parquet files and configure row access policies and column policy tags on those external tables, accepting that connected engines bypass the policies.
• BCreate BigLake tables over the Parquet files in Cloud Storage and apply row-level access policies and column policy tags so that BigQuery and connected engines such as Spark enforce the same controls.check_circle Correct
• CLoad the Parquet files into a native BigQuery table on a schedule, apply row access policies and column policy tags there, and keep the Cloud Storage copies only as a cold archive for the Spark pipeline.
• DUse object access controls on the Cloud Storage bucket combined with signed URLs for the Spark job, and rely on BigQuery dataset-level IAM for analyst access to the Parquet files.

Why A is wrong: Tempting because external tables do allow querying Parquet from BigQuery, but standard external tables do not support the same fine-grained policy surface and do not extend enforcement to engines like Spark in the way that BigLake does.

Why B is correct: Correct because BigLake tables over Cloud Storage support the same BigQuery fine-grained access controls and extend that enforcement to connected open-source engines through the BigLake connector, which is the only option that meets both requirements.

Why C is wrong: Tempting because native tables clearly support fine-grained controls, but loading duplicates storage and breaks the requirement that Cloud Storage remains the system of record for the external Spark pipeline.

Why D is wrong: Tempting because Cloud Storage IAM is familiar, but bucket-level controls are coarse, cannot express row or column policies, and force two divergent access models for BigQuery and Spark instead of one.