Task 3.3: Using a data lake.

• AGrant the analysts Storage Object Viewer on the bucket

  Incorrect

  Direct bucket access would let analysts read the files and bypass the table-level controls.

• BCreate BigLake tables over the files with a Cloud resource connection

  Correct

  BigLake tables read the data through a connection's service account and enforce row-level and column-level security at the table level.

• CCreate external tables that read with the analysts' own credentials

  Incorrect

  Standard external tables read the files with the querying user's credentials, so analysts would need bucket access.

• DCopy the files into native tables with a nightly load job

  Incorrect

  Loading copies the data, which the requirement rules out, and it is a day behind the files.

• EGive the connection's service account read access to the bucket

  Correct

  The connection's service account, not the analysts, needs Storage Object Viewer on the bucket; users need permissions only on the table.

BigLake tables use access delegation: a Cloud resource connection's service account reads Cloud Storage, and users are granted access only to the table. That is what makes row-level and column-level security on lake data meaningful, because nobody needs to touch the objects directly.

• ASigned URLs for each partner, with a seven-day expiration

  Incorrect

  Signed URLs grant time-limited access to objects, but the bucket's project still pays for the reads and egress.

• BRequester Pays on the bucket, with partners naming a billing project

  Correct

  With Requester Pays, the requester's billing project pays for operations, retrieval and network usage, while storage stays with the bucket owner.

• CA BigQuery sharing listing that exposes the bucket to partner projects

  Incorrect

  BigQuery sharing lists BigQuery datasets and Pub/Sub topics; it does not change who pays for reading objects in a bucket.

• DAutoclass on the bucket, so that rarely read objects move to colder classes

  Incorrect

  Autoclass lowers storage cost for rarely accessed objects; the institute would still pay for the partners' reads.

Requester Pays moves access charges (operations, retrieval and network usage) to the project that makes the request, which must be named on each request; storage charges stay with the bucket's project. It is the standard way to publish large datasets without paying for every consumer's reads.

• ALoad the files into a native BigQuery table each hour

  Incorrect

  Loading creates a second copy outside the lake and adds a pipeline, while the files have to stay the source.

• BEnable metadata caching with a one-hour staleness and automatic refresh

  Correct

  Metadata caching lets queries skip listing files and prune faster, and an automatic refresh suits files that arrive at random times.

• CAssign the query project to a reservation with more slots

  Incorrect

  More slots speed up processing, but the time goes to listing files, which slots do not shorten.

• DRecreate it as a standard external table without a connection

  Incorrect

  Standard external tables do not support metadata caching and would also lose the BigLake access model.

For BigLake tables over many files, metadata caching stores file and partition metadata so that queries avoid listing the store. Staleness can be set from 30 minutes to 7 days, and the cache can refresh automatically, about every 30 to 60 minutes, or manually on a schedule.

• AWith a wildcard URI over gs://lake/sales/* and no partitioning options

  Incorrect

  Without Hive partitioning, dt is not a column BigQuery can prune on, so every query reads every file.

• BAs a native table loaded once a month from the lake's files

  Incorrect

  Loading copies the data and leaves it up to a month behind the lake.

• CWith Hive partitioning on the sales prefix and a required partition filter

  Correct

  Hive partitioning reads dt from the key=value folders as a column and prunes on it, and requirePartitionFilter rejects queries without it.

• DWith the table clustered on dt so that blocks are pruned

  Incorrect

  Clustering is a feature of BigQuery-managed storage; the files' layout in Cloud Storage is what decides what can be skipped.

BigQuery understands the Hive layout of key=value directories: with the common source URI prefix, partition keys become columns that predicates can prune on, and the requirePartitionFilter option makes a partition filter mandatory.

• AObject Versioning, keeping each noncurrent version for seven years

  Incorrect

  Versioning keeps old versions after overwrites, but administrators can still delete versions or turn versioning off.

• BSoft delete with the longest retention period it allows

  Incorrect

  Soft delete keeps deleted objects for at most 90 days, far short of seven years.

• CAn IAM deny policy on storage.objects.delete for the bucket

  Incorrect

  Administrators who manage IAM can remove the deny policy, so it does not meet the requirement.

• DA seven-year retention policy on the bucket, then locked

  Correct

  A retention policy blocks deletion and replacement until objects reach the period, and locking it makes it permanent, so nobody can remove or shorten it.

Bucket Lock gives write-once-read-many storage: the bucket's retention policy prevents objects from being deleted or replaced before they reach the retention period, and once the policy is locked it can no longer be removed or reduced.

• ABuckets with hierarchical namespace enabled at creation

  Correct

  Hierarchical namespace buckets have real folders that can be renamed atomically, which Google recommends for Hadoop and Spark workloads.

• BBuckets with Rapid Cache in the zone where the jobs run

  Incorrect

  Rapid Cache does not change how folders are renamed; a rename on a flat bucket is still a copy and delete of every object.

• CDual-region buckets with turbo replication turned on

  Incorrect

  Turbo replication shortens the replication time between regions; renames are still object by object.

• DBuckets with Autoclass so that temporary files cost less

  Incorrect

  Autoclass changes storage classes over time; it does nothing for rename behaviour.

On a flat namespace, a folder is just a name prefix, so a rename copies and deletes every object. Hierarchical namespace buckets have real folders with atomic rename and higher initial request rates, which suits file-oriented analytics. The setting must be chosen when the bucket is created and needs uniform bucket-level access.