Task 1.1: Designing for security and compliance.

• AApply policy tags from one taxonomy and grant the fraud team Fine-Grained Reader

  Correct

  Policy tags restrict columns in place: a column tagged with a policy tag is readable only by principals with Fine-Grained Reader on that tag, and one tag can be applied to columns in many tables, so one IAM policy governs all of them.

• BCreate an authorized view of each table without the two columns for analysts

  Incorrect

  Authorized views work, but they add 31 objects that analysts must switch to and that must be kept in step with each table, which the company ruled out; they also leave no single control for the columns.

• CAdd a row access policy to each table that hides rows from users outside fraud

  Incorrect

  Row-level security filters rows, not columns. Analysts outside the fraud team would lose whole customer records instead of just the two columns.

• DMove the two columns to a separate dataset and grant the fraud team access to it

  Incorrect

  Splitting each table changes 31 schemas and every query that joins the columns back, and it is still a per-dataset grant rather than one policy for the columns.

Column-level access control in BigQuery is done with policy tags. A taxonomy holds the tags, each column gets at most one tag, and reading a tagged column needs the Data Catalog Fine-Grained Reader role on that tag. Because the same tag can sit on columns in any number of tables in the same location, one grant controls the sensitive columns everywhere, and users without it can still query the other columns of the table.

• ABigQuery Job User on project data-prj

  Incorrect

  Job User on data-prj lets the analysts create jobs in data-prj, so their queries could be billed there, which the requirement forbids.

• BBigQuery Job User on project analytics-prj

  Correct

  Running a query needs bigquery.jobs.create in the project that runs the job. Job User on analytics-prj grants it there, so the query is billed to analytics-prj.

• CBigQuery Data Editor on the sales dataset

  Incorrect

  Data Editor can read but also create, update and delete tables in the dataset, which is more than read access.

• DBigQuery Data Viewer on the sales dataset

  Correct

  Data Viewer on the dataset gives bigquery.tables.getData and metadata read on its tables, and nothing that changes them.

• EBigQuery Admin on project analytics-prj

  Incorrect

  Admin on analytics-prj grants far more than needed and still gives no read access to tables in data-prj.

A cross-project query needs two separate permissions: the right to create the job in the project that pays for it (Job User, granted at project level) and the right to read table data where the data lives (Data Viewer, granted as narrowly as the dataset). Keeping the two grants in different places is what stops analysts from billing jobs to the data project.

• AAn IAM deny policy on the data projects that blocks table export permissions

  Incorrect

  A deny policy blocks the permission for the principals it names, but a stolen key of an authorized identity can still read rows and write them somewhere else with a query; deny policies do not look at where data is going.

• BCustomer-managed encryption keys on the datasets that hold the claims data

  Incorrect

  CMEK controls the key that protects data at rest. An identity that is allowed to read the table reads decrypted rows and can write them to a table that is not under that key.

• CA VPC Service Controls perimeter around the data projects that restricts BigQuery

  Correct

  A service perimeter blocks copying data to resources outside it, even by callers with valid credentials, and can block access from outside networks, which is the exfiltration case described.

• DData Access audit logs for BigQuery, with an alert on copy and export jobs

  Incorrect

  Audit logs record who read or copied data and can drive an alert, but only after the data has left; they do not block the copy.

IAM decides who may act on a resource; VPC Service Controls decides where data may flow. A perimeter around the projects that hold the data blocks copies and exports to resources outside it and access from unauthorized networks, even when the credentials used are valid, so a stolen key or an insider cannot move the data out. Google recommends using both together.

• APolicy tags on the region column with a Fine-Grained Reader grant per region

  Incorrect

  Policy tags do not filter rows by the value they hold, so they cannot give each manager a different slice of the rows.

• BRow access policies that filter on region and grant each manager group

  Correct

  A row access policy's filter works like a WHERE clause for the principals in its grantee list, so each regional group sees only its rows and finance can be granted a policy with a filter that passes every row.

• CA separate table for each region, each shared with that region's managers

  Incorrect

  Separate tables are secure but are exactly the per-region copies that the company wants to avoid.

• DA dynamic data masking rule on the region column for the regional groups

  Incorrect

  Masking changes how a column's values are shown; the manager would still see every row, with the region masked.

Row-level security in BigQuery attaches row access policies to a table. Each policy has a filter expression and a grantee list; users see the rows that the policies granted to them allow, and users in no policy see no rows. It keeps one table for everyone, which Google positions between authorized views and separate tables for balancing flexibility and security.

• AGoogle's default encryption at rest, which already rotates keys

  Incorrect

  Default encryption uses Google-owned keys that the customer cannot view, rotate on its own schedule or disable.

• BCustomer-supplied encryption keys sent with each load and query job

  Incorrect

  BigQuery does not support customer-supplied encryption keys for its tables.

• CCloud External Key Manager keys held in a partner key manager

  Incorrect

  Cloud EKM keeps the key material in an external key manager, which is the outside system the lender does not want to run.

• DCustomer-managed Cloud KMS keys set as the datasets' default key

  Correct

  CMEK lets the customer set the rotation period, trigger rotations and disable or destroy key versions, after which the protected data cannot be accessed.

Customer-managed encryption keys give the customer the key lifecycle: rotation schedule, key state and destruction, with usage visible in logs. The key ring must be in a location that matches the dataset, and the BigQuery service account needs the Cloud KMS CryptoKey Encrypter/Decrypter role on the key.

• ACryptographic hashing with a key, which produces consistent tokens

  Correct

  Keyed hashing keeps referential integrity, so the same identifier always gives the same token for joins, and its output cannot be re-identified.

• BDeterministic encryption with AES-SIV and a wrapped key in Cloud KMS

  Incorrect

  AES-SIV tokens are joinable, but anyone with the key can re-identify them, which the policy forbids.

• CFormat-preserving encryption that keeps the identifier's length

  Incorrect

  Format-preserving encryption is reversible with its key and gives weaker guarantees than AES-SIV.

• DCharacter masking that hides the identifier except its last four characters

  Incorrect

  Masked values collide, since many identifiers share the last four characters, so tables can no longer be joined reliably on them.

Sensitive Data Protection's cryptographic pseudonymization methods all keep referential integrity, but they differ in reversibility: deterministic encryption and format-preserving encryption can be re-identified with the key, while cryptographic hashing (HMAC-SHA-256) cannot. When joins are needed and re-identification must be impossible, hashing is the fit.

• ATurn on Object Versioning so that each read creates a new generation

  Incorrect

  Object Versioning keeps noncurrent versions when objects are overwritten or deleted; reads create nothing.

• BAdd a retention policy and lock it so that object access is preserved

  Incorrect

  A locked retention policy stops objects from being deleted or replaced; it does not record who read them.

• CEnable Data Access audit logs with DATA_READ for Cloud Storage

  Correct

  Data Access audit logs are disabled by default for most services, including Cloud Storage; enabling DATA_READ records object reads with the caller's identity.

• DCreate a Pub/Sub notification on the bucket for each object event

  Incorrect

  Pub/Sub notifications report object changes such as finalize, delete and metadata updates; reads do not trigger them.

Data Access audit logs, which record reads and writes of user data, are off by default for every service except some of BigQuery, and must be enabled per service at the project, folder or organization level. Their volume can be large, which adds logging cost.