Task 3.1: Protecting sensitive data and preventing data loss.

• AAn on-demand inspection job for each table, started by a script that lists datasets each week

  Incorrect

  Inspection jobs examine the data you point them at once; a weekly script of jobs across hundreds of projects is costly and misses tables created between runs.

• BSecurity Health Analytics detectors for BigQuery across the organization

  Incorrect

  Security Health Analytics checks resource configuration, such as public datasets, not the contents of the tables.

• CA Sensitive Data Protection discovery scan configuration at the organization level for BigQuery

  Correct

  Discovery profiles tables continuously across the organization or selected folders and projects, records the infoTypes found and can publish the profiles to Security Command Center.

• DColumn-level access control with policy tags on every table that analysts have marked as sensitive

  Incorrect

  Policy tags restrict access to columns someone has already classified; they do not find personal data in tables nobody has reviewed.

Sensitive data discovery in Sensitive Data Protection creates data profiles for BigQuery tables and other supported data, at the organization, folder or project level, and keeps them current as data changes. Profiles show the infoTypes and sensitivity found and can be sent to Security Command Center, while inspection jobs suit one-off, deep scans of specific data.

• ADeterministic encryption with AES-SIV, using one KMS-wrapped key for both datasets

  Correct

  The same input always gives the same token, so joins still work, and the token can be decrypted with the key when the legal team needs the original.

• BCryptographic hashing with HMAC-SHA-256, using one KMS-wrapped key

  Incorrect

  Hashing also keeps joins working, but its output cannot be re-identified, so the legal team could never recover an address.

• CCharacter masking that replaces everything before the @ sign with asterisks

  Incorrect

  Many addresses would mask to the same value at the same domain, which breaks joins, and the masked part cannot be recovered.

• DReplacement with the infoType name, so every address reads EMAIL_ADDRESS

  Incorrect

  Every value becomes the same placeholder, so the column can no longer be joined and nothing can be recovered.

Sensitive Data Protection offers several pseudonymization methods. Deterministic encryption with AES-SIV replaces each value with the same token every time and can be reversed with the key, which suits joins plus controlled re-identification. Cryptographic hashing is consistent but irreversible, and masking or replacement removes the information outright.

• AA global secret with an automatic replication policy and a CMEK key in europe-west3

  Incorrect

  Automatic replication places the payload wherever Google chooses, and a regional key does not change where the secret data is replicated.

• BA global secret with a user-managed replication policy limited to europe-west3

  Incorrect

  User-managed replication controls where a global secret is stored, but Google points strict residency needs to regional secrets, which also cover processing in use and in transit.

• CA global secret in a project whose resource locations policy allows only in:europe-west3-locations

  Incorrect

  The location policy limits where resources are created; it does not give the at-rest, in-use and in-transit guarantees the officer asked for.

• DA regional secret created in europe-west3

  Correct

  Regional secrets keep their data in the chosen location at rest, in use and in transit, are not replicated elsewhere and are reached through that location's endpoint.

Secret Manager has a global service and a regional service. Regional secrets are created in one location and are not replicated, and Google's best practices recommend them for strict data residency and sovereignty requirements because they give at-rest, in-use and in-transit guarantees.

• AMove the startup script from instance metadata to project-wide metadata so that fewer people view it

  Incorrect

  Project-wide metadata is readable by every VM in the project and by anyone who can view the project, so exposure grows.

• BKeep the password in Secret Manager and grant the VM's identity Secret Accessor on it

  Correct

  Granting Secret Manager Secret Accessor on one secret to the VM's service account keeps the value out of metadata, and only that identity can read it.

• CBase64-encode the password inside the startup script and decode it at boot time

  Incorrect

  Encoding is not encryption; anyone who can read the metadata can decode the value.

• DEncrypt the VM's boot disk with a customer-managed key from Cloud KMS

  Incorrect

  Metadata is served by the metadata server, not read from the boot disk, so disk encryption does not protect it.

Metadata values, including startup scripts, can be read by anyone with permission to view the instance and from inside the VM through the metadata server, so Google advises against storing secrets there. Secret Manager keeps the value encrypted with per-secret IAM, and the VM's attached service account can fetch it when the script runs.

• AFormat preserving encryption with FFX, using a KMS-wrapped key

  Correct

  FPE keeps the input's character set and length, so the output is still 16 digits, and it can be reversed with the key.

• BDeterministic encryption with AES-SIV, using a KMS-wrapped key

  Incorrect

  This method does not keep the character set or length of the input, so the legacy job would reject its output.

• CCryptographic hashing with HMAC-SHA-256, truncated to 16 characters

  Incorrect

  Hexadecimal hash output is not a string of 16 digits, so the legacy job would reject it, and truncation throws information away.

• DBucketing of each number into ranges of one million

  Incorrect

  Bucketing generalizes values into ranges; it neither keeps a valid 16-digit value nor allows recovery.

Format preserving encryption (FPE-FFX) replaces a value with a token of the same length and character set and can be reversed with the key. It suits systems that validate format, though Google points out important security considerations for it.

• AA higher likelihood threshold for the built-in PERSON_NAME detector

  Incorrect

  Changing a threshold for names does not teach the inspector a new identifier format.

• BA custom infoType defined by a regular expression for the EMP- pattern

  Correct

  A custom infoType defined by a regular expression finds values that follow a known pattern that no built-in infoType covers.

• CA large stored dictionary built from all employee names in the directory

  Incorrect

  A dictionary of names matches names, which are already handled, not the identifier pattern.

• DThe built-in infoType for US Social Security numbers, which matches digit groups

  Incorrect

  That detector looks for SSN formats; it would not match the company's EMP- identifiers.

Sensitive Data Protection includes many built-in infoType detectors and lets you add custom infoTypes: regular expressions for known patterns, word lists and large stored dictionaries for known values. A regex detector is the fit for a company-specific identifier format.

• AA row access policy that hides rows with card numbers from support agents

  Incorrect

  Row-level security removes whole rows, not part of a column's value.

• BAn authorized view for support agents that returns SUBSTR of the column

  Incorrect

  A view would work, but it is the extra object the company ruled out, and agents would have to query it instead of the table.

• CA Last four characters masking rule on a policy tag, with the matching reader roles

  Correct

  Dynamic data masking returns masked values to Masked Readers and full values to Fine-Grained Readers from the same column.

• DA Sensitive Data Protection de-identification job that rewrites the column in place every night

  Incorrect

  Rewriting the column would hide full numbers from the fraud team as well.

BigQuery dynamic data masking uses data policies. A data policy attaches a masking rule, such as Last four characters, Nullify or SHA-256 hash, to a policy tag (or, as a newer option, directly to a column); users with Masked Reader see the masked value, and users with Fine-Grained Reader on the tag see the real value, all through the same table and query.

• AStronger database passwords stored in Secret Manager and rotated every 30 days

  Incorrect

  Rotation improves the passwords but keeps shared database credentials separate from Google identities.

• BSSL/TLS with client certificates required for every connection to the instance

  Incorrect

  Client certificates protect the connection, but database users and passwords still decide who signs in.

• CAuthorized networks that list only the office and application subnets

  Incorrect

  Authorized networks limit where connections come from, not who the user is.

• DIAM database authentication on the instance, with the users and service accounts added as IAM database users

  Correct

  Cloud SQL can authenticate database users with their IAM identities, so access follows IAM grants and ends when the identity is removed.

Cloud SQL IAM database authentication lets users and service accounts sign in to the database with their Google identities and short-lived tokens, often through the Cloud SQL Auth Proxy or connectors. Access is managed with IAM, so removing the identity or its role removes database access.