Domain 1 of 5 · Chapter 1 of 4

Security & Compliance

The four data-security concerns, one model

Picture a BigQuery dataset that holds customer orders with email addresses and card numbers, feeding a pipeline whose service account writes nightly. Securing it on Google Cloud always comes down to the same four questions, and the rest of this page is one question per section: who can act on the data (access), who holds the key that encrypts it (encryption), how the sensitive values themselves are protected when data leaves the table (privacy), and where the data may live and what can cross its boundary (residency and isolation). Underneath all four sits the project, dataset, and table layout that decides where every control attaches.

Keep these four as distinct concerns rather than blurring them, because the exam loves to offer a control from the wrong concern. Access (Cloud IAM) decides who, but it does nothing once data is in a query result. Encryption is always on, so its only design choice is key ownership, not whether to turn it on. Privacy controls (Sensitive Data Protection, column-level security) act on the values themselves and survive an export. Residency and isolation (dataset location, Organization Policy, VPC Service Controls) constrain place and movement, independent of who holds a valid credential.

Concern Question it answers Primary controls
Access Who can act on this resource? Cloud IAM[1] roles, hierarchy inheritance, deny policies
Encryption Who owns the key? Google-managed keys, CMEK in Cloud KMS[2], CSEK, Cloud HSM/EKM
Privacy How are the values themselves protected? Sensitive Data Protection[3], BigQuery column-level security, dynamic masking
Residency & isolation Where can data live, what crosses the boundary? Dataset location, Organization Policy[4], VPC Service Controls[5]

A question that says "a user with valid permissions can still not query the table from outside the network" is pointing at the residency-and-isolation concern (VPC Service Controls), not at IAM, because IAM already said yes.

Accesswho can actCloud IAMEncryptionwho owns the keyCMEK / Cloud KMSPrivacyprotect the valuesSensitive Data ProtectionResidency &isolationwhere data livesOrg Policy, VPC-SCProject / dataset / table architecturewhere every control attaches; dev and prod in separate projects
The four data-security concerns sit on top of the project/dataset/table architecture that hosts every control.

Access: IAM on datasets, buckets, and the hierarchy

Cloud IAM grants a role (a bundle of permissions) to a principal (a user, group, or service account) on a resource; you never grant a bare permission. The reusable rule for least privilege is to bind the narrowest role at the lowest resource that satisfies the need: roles/bigquery.dataViewer on one dataset, not roles/editor on the project.

Inheritance sets the blast radius

The Google Cloud resource hierarchy runs organization > folders > projects > resources, and an IAM allow policy set on a node is inherited by everything beneath it. A role granted at the folder applies to every project under that folder, so the level you bind at, not just the role you pick, decides the blast radius. This is why dev/prod separation is a security control and not just tidiness: a role scoped to the production folder cannot touch development resources.

Both BigQuery and Cloud Storage expose resource-level IAM below the project. A BigQuery dataset (and, finer still, a table or view) takes its own IAM grants, and a Cloud Storage bucket takes bucket-level IAM, so a pipeline's service account can be scoped to exactly the dataset it reads and the bucket it writes. Prefer bucket-level uniform IAM[6] over legacy per-object ACLs for buckets that back a data lake.

Allow is additive; deny wins

Allow policies only ever add permissions; they cannot subtract one. To guarantee a permission is blocked, attach an IAM deny policy[7] at the organization, folder, or project. IAM evaluates deny rules before allow rules, so a matching deny blocks the permission no matter what role was granted, including an inherited Owner. A deny rule applies when its condition is true or cannot be evaluated, and exceptionPrincipals carves out break-glass identities. Do not try to undo an over-broad grant by layering more allow grants; that never removes the original.

OrganizationFolder (prod)ProjectDataset / bucketresource-level IAMallow rolesinherit downwardDeny policyevaluated before allowoverrides
IAM allow roles inherit down organization to folder to project to resource; a deny policy is checked first and overrides any allow.

Encryption: default at rest, then key ownership

Encryption is never the decision; key ownership is. Google Cloud encrypts all customer data at rest by default[8] with AES-256 and no action from you, using envelope encryption: a data encryption key (DEK) encrypts the data, and a key encryption key (KEK) wraps the DEK. The only design choice is who controls the KEK.

The three key-ownership tiers

With Google-managed keys, Google holds and rotates the KEK; there is nothing to set up and no key for you to lose. With customer-managed encryption keys (CMEK) in Cloud KMS, you own the KEK: you can rotate it on a schedule, disable it, and destroy it, and destroying or disabling it makes the protected data permanently unreadable, which is crypto-shredding. With customer-supplied encryption keys (CSEK), you pass a raw key with each request and Google never stores it, so losing it loses the data. Reach for CMEK when a regulator demands auditable key control or rotation; stay on Google-managed keys otherwise, because CMEK adds key IAM, a rotation schedule, and an availability dependency on Cloud KMS.

When a stronger key boundary is mandated

If a control mandates a hardware-backed key, Cloud HSM[9] stores the CMEK in a cluster of FIPS 140-2 Level 3 certified hardware security modules. If the key must live outside Google Cloud entirely, Cloud EKM (External Key Manager) keeps it in a third-party key manager and Cloud KMS calls out to it. Plain CMEK is a software-protected key inside Cloud KMS. The common confusion is CMEK versus CSEK: CMEK keys are stored and managed in Cloud KMS, while CSEK keys are supplied per request and never stored by Google.

In BigQuery you set CMEK at the dataset level so new tables inherit it; in Cloud Storage you set a default CMEK on the bucket.

Must you controlthe key?NoGoogle-managed keysdefault, no setupYesWhere mustthe key live?in Cloud KMSCMEKsoftware; or Cloud HSMfor FIPS 140-2 L3outside GoogleCloud EKMexternal key manager;CSEK if supplied per request
Key-ownership ladder: Google-managed by default, CMEK in Cloud KMS when you must control the key, Cloud HSM for FIPS hardware, Cloud EKM for an external key.

Privacy: de-identify PII and mask columns

IAM decides who opens a table, but once a value is in a query result, an export, or a downstream dataset, IAM no longer protects it. Privacy controls act on the sensitive values themselves, so the protection travels with the data.

Sensitive Data Protection finds and de-identifies

Sensitive Data Protection[3] (formerly Cloud DLP) discovers and classifies sensitive data across BigQuery, Cloud Storage, and Datastore, and can inspect streaming content inline. It matches built-in infoTypes such as credit-card number or national ID, then de-identifies what it finds. The de-identification techniques are masking (replace characters), redaction (remove the value), bucketing (generalize, for example an exact age to an age range), date shifting (move dates by a consistent random offset), and tokenization. Tokenization (also called pseudonymization) swaps a value for a token while keeping a consistent mapping, so the same input always yields the same token and the original can be recovered if the format-preserving or cryptographic method permits, all without exposing the raw value. Use this when you must analyze data that contains PII but the analysts should never see the raw identifiers.

Column-level control inside BigQuery

For per-column governance without copying data, BigQuery column-level security[10] tags sensitive columns with policy tags from Data Catalog and grants the Fine-Grained Reader role only to principals allowed to read them; everyone else cannot select the column. Dynamic data masking[11] goes further by returning an obfuscated value (nulled, hashed, or default) at query time based on the caller's role, so the same query shows real data to one role and masked data to another, with no second copy of the table. Reach for these inside the warehouse; reach for Sensitive Data Protection when the data lives in Cloud Storage, spans services, or needs a one-time bulk de-identification job.

Source dataBigQuery, GCSMatch infoTypescard, national IDDe-identifyprotection travelsmask / redact / bucket /date-shift / tokenize
Sensitive Data Protection inspects source data, matches infoTypes, then de-identifies so the protection travels with the values.

Residency, isolation, and the project architecture

Two scenarios on this exam look like access control but are not: "data must stay in the EU" and "a user with valid permissions still cannot reach the data from outside the perimeter." The first is residency, the second is isolation, and both are governed independent of IAM.

Pin residency at creation and enforce it from above

A BigQuery dataset's location is fixed when the dataset is created and cannot be changed afterward; moving data to another region means creating a new dataset there and copying. Choosing the location per dataset is necessary but not enough at scale, because nothing stops a team from creating one in the wrong region. The Organization Policy[4] resource-location constraint set at the organization or folder forces every project below to provision resources only in allowed regions, which is how residency becomes enforced rather than advisory. Organization Policy governs what configuration is allowed (the what), while IAM governs who can act (the who); they are complementary, and a list/boolean constraint inherits to all descendants of the node it is set on.

When a requirement is residency only, the location constraint is the answer. Only when a scenario needs location AND access AND personnel guarantees together (for example an EU Data Boundary that also restricts which Google staff can act) do you reach for Assured Workloads[12], which is heavier and tied to specific compliance regimes.

Isolate the boundary with VPC Service Controls

VPC Service Controls[5] draws a service perimeter around projects and their Google-managed services. Communication inside the perimeter is free; communication across it is blocked by default. The key property is that it is context-based and independent of IAM: a caller with valid IAM permissions is still blocked across the perimeter, which makes it the data-exfiltration control. Controlled exceptions are ingress and egress rules, and dry-run mode logs would-be blocks before you enforce. Note what it does not do: it governs Google API access (for example a bigquery.googleapis.com request), not packet-level traffic between VMs, which remains the job of VPC firewall rules.

Architect projects for governance

Keep development and production in separate projects so a test job can never read or corrupt production data, and so IAM, quotas, billing, and audit logs are scoped cleanly per environment. A folder per environment lets one inherited IAM and Organization Policy set govern every project beneath it. Within an environment, model datasets and tables so the natural IAM boundary, a dataset-level grant, matches how teams actually share data, rather than dumping everything into one dataset and trying to claw back access table by table.

Service perimeterProd projectBigQuery, GCSDev projectseparate envinside: allowedOutside callervalid IAMblockedacross boundary
A VPC Service Controls perimeter allows access inside but blocks cross-boundary API calls even from a caller holding valid IAM.

Four governance concerns for data security on Google Cloud

ConcernPrimary controlWhat it decidesKey trap
Access (who)Cloud IAM roles on the resource + hierarchy inheritanceWhich principals can act on a dataset, table, or bucketBinding a broad role high in the hierarchy widens the blast radius
Encryption (key ownership)Google-managed keys / CMEK in Cloud KMS / CSEKWho holds and can destroy the key (data is always encrypted)Assuming you must enable encryption; it is already on by default
Privacy (the data itself)Sensitive Data Protection; BigQuery column-level security + maskingHow PII is found and de-identified before sharing/analysisRelying on IAM alone once data leaves the table in a result
Residency & isolation (where)Dataset location + Organization Policy location constraint; VPC Service ControlsWhich regions hold data and what crosses the perimeterTrying to move a dataset's location after creation
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Grant the narrowest IAM role at the lowest resource that meets the need

Cloud IAM grants a role (a bundle of permissions) to a principal on a resource; you never grant a bare permission. For least privilege, bind the narrowest role at the lowest level: an analyst who needs to read one BigQuery dataset gets roles/bigquery.dataViewer on that dataset, not roles/editor on the project. Both BigQuery datasets and tables and Cloud Storage buckets expose their own resource-level IAM, so a pipeline's service account can be scoped to exactly the data it touches.

Trap Granting a broad project-level role like Editor to satisfy a request that only needs read access on a single dataset, which silently exposes every other resource in the project.

2 questions test this
IAM roles inherit downward, so the binding level is the blast radius

An IAM allow policy set on an organization, folder, or project is inherited by every resource beneath it, so the level you bind a role at, not just the role you pick, decides how far it reaches. A role on the production folder applies to every project under it. This is why putting development and production in separate folders/projects is a real security control: a grant scoped to one environment cannot touch the other.

Trap Granting a role at the organization or folder to fix one project's access, which silently propagates the permission to every project below that node.

2 questions test this
An IAM deny policy is evaluated before allow and overrides any grant

Allow policies are additive only and can never subtract a permission, so the way to guarantee a block is an IAM deny policy attached at organization, folder, or project. IAM evaluates deny rules before allow rules, so a matching deny blocks the permission regardless of any role granted, including an inherited Owner. A deny applies when its condition is true or cannot be evaluated, and exceptionPrincipals carves out break-glass identities.

Trap Trying to revoke an over-broad permission by adding more allow grants; allow is additive and never removes the original, so only a deny policy actually blocks it.

1 question tests this
Prefer uniform bucket-level IAM over per-object ACLs for data-lake buckets

Cloud Storage can control access either with bucket-level uniform IAM or with legacy per-object ACLs, but mixing them makes access unauditable. For a bucket backing a data lake, enable uniform bucket-level access so all access is governed by IAM at the bucket, which is consistent with how datasets are governed and far easier to reason about than thousands of per-object ACLs.

Trap Leaving per-object ACLs enabled on a data-lake bucket, which scatters access decisions across objects and defeats a single auditable IAM policy.

All data is encrypted at rest by default; the choice is who owns the key

Google Cloud encrypts all customer data at rest automatically with AES-256 using envelope encryption (a data encryption key wrapped by a key encryption key), with no action required. Encryption is therefore never the design decision; key ownership is. The question on the exam is whether Google-managed keys suffice or a regulator requires customer-controlled keys.

Use CMEK in Cloud KMS when you must rotate, disable, or destroy the key

Customer-managed encryption keys (CMEK) put the key encryption key under your control in Cloud KMS, so you can rotate it on a schedule, disable it, and destroy it. Destroying or disabling the CMEK makes the protected data permanently unreadable, which is crypto-shredding. Choose CMEK when a regulator demands auditable key control or rotation; default Google-managed keys are simpler and add no Cloud KMS availability dependency when no such requirement exists.

Trap Adopting CMEK purely to be more secure when no requirement exists; data is already AES-256 encrypted, and CMEK only adds key lifecycle work and a dependency on Cloud KMS availability.

6 questions test this
CMEK keys live in Cloud KMS; CSEK keys are supplied per request and never stored

Both let the customer control the key, but they differ in storage. CMEK keys are created and managed inside Cloud KMS (Google stores the wrapped key). Customer-supplied encryption keys (CSEK) are raw keys passed with each request that Google uses then discards and never stores, so losing a CSEK loses the data with no recovery. CSEK shifts all key custody to you; CMEK keeps Cloud KMS lifecycle features.

Trap Assuming Google can recover data protected with CSEK; the key is never stored, so a lost CSEK is unrecoverable, unlike a CMEK held in Cloud KMS.

Cloud HSM gives a FIPS 140-2 Level 3 key; Cloud EKM keeps the key off Google Cloud

When a control mandates a hardware-backed key, Cloud HSM stores the CMEK in a cluster of FIPS 140-2 Level 3 certified hardware security modules. When the key must live entirely outside Google Cloud, Cloud EKM (External Key Manager) keeps it in a third-party key manager that Cloud KMS calls out to. Plain CMEK is a software-protected key in Cloud KMS, the default tier when neither hardware certification nor external custody is required.

Trap Reaching for Cloud EKM when the requirement is only a hardware-backed key; FIPS 140-2 Level 3 is satisfied by Cloud HSM inside Google Cloud, and EKM is for keeping the key outside Google entirely.

Set CMEK at the BigQuery dataset level so new tables inherit it

Rather than configuring a key per table, set a default CMEK on the BigQuery dataset and new tables created in it inherit that key. In Cloud Storage the equivalent is a default CMEK on the bucket. This makes key control a one-time dataset/bucket configuration instead of a per-object task that someone will forget.

Use Sensitive Data Protection to discover and de-identify PII across services

Sensitive Data Protection (formerly Cloud DLP) scans BigQuery, Cloud Storage, and Datastore, and can inspect streaming content, matching built-in infoTypes such as credit-card number or national ID. It then de-identifies findings by masking, redaction, bucketing (generalizing a value, for example an exact age to a range), date shifting, or tokenization. Reach for it when sensitive data spans services or needs a bulk de-identification job, because the protection acts on the values themselves and survives an export.

Trap Relying on IAM alone to protect PII; IAM only controls who opens the table, but the raw values remain exposed once they appear in a query result or export.

5 questions test this
Tokenization swaps a value for a consistent token without exposing the raw data

Tokenization (pseudonymization) in Sensitive Data Protection replaces a sensitive value with a token while preserving a consistent mapping, so the same input always produces the same token and records can still be joined or grouped by it. Unlike redaction or masking, the original can be recovered when the cryptographic or format-preserving method allows re-identification by an authorized party. Use it when analysts must work with the data but never see the real identifiers.

Trap Treating tokenization as the same as masking or redaction; those destroy the value, while tokenization keeps a reversible, consistent mapping for re-identification.

3 questions test this
BigQuery column-level security gates sensitive columns with policy tags

BigQuery column-level security tags sensitive columns with policy tags from Data Catalog and grants the Fine-Grained Reader role only to principals allowed to read them; everyone else simply cannot select the tagged column. This restricts access per column without copying the table or building separate views, keeping one governed source of truth in the warehouse.

1 question tests this
BigQuery dynamic data masking returns obscured values by role at query time

Dynamic data masking builds on policy tags to return an obfuscated value at query time based on the caller role, so the same query shows real data to a privileged role and masked data to others, with no second copy of the table. A caller with the BigQuery Masked Reader role sees the masked value while a Fine-Grained Reader sees the real one, and the masking rule can nullify the column, return a default for its type, or hash it (SHA-256). Choose masking over plain column-level security when lower-privileged users still need to run the query but must not see the real values.

Trap Creating duplicate masked copies or separate views per audience to hide columns, when dynamic data masking returns role-appropriate values from the single table at query time.

A BigQuery dataset's location is fixed at creation and cannot be changed

You choose a dataset's location (a region or multi-region) when you create it, and it cannot be changed afterward; relocating data means creating a new dataset in the target location and copying. Because all tables in a dataset inherit its location, dataset location is the lever for data residency, and queries cannot join tables across locations.

Trap Assuming a dataset can be moved to another region after creation; the location is immutable, so residency must be decided up front or the dataset recreated and copied.

1 question tests this
Enforce residency with an Organization Policy resource-location constraint

Setting locations per dataset is not enough at scale because a team can still create resources in the wrong region. The Organization Policy resource-location constraint, set at the organization or folder, forces every project below to provision resources only in allowed regions, turning residency from advisory into enforced. Organization Policy governs what configuration is allowed (the what) while IAM governs who can act (the who); a constraint inherits to all descendants of the node it is set on.

Trap Trusting each team to pick the right region instead of setting a resource-location org policy; without the constraint nothing prevents provisioning outside the required jurisdiction.

Use Assured Workloads only when location, access, and personnel controls are all required

When a requirement is residency alone, a resource-location Organization Policy is sufficient and far lighter. Assured Workloads is for scenarios that need location AND access AND personnel guarantees together, such as an EU Data Boundary that also restricts which Google support staff may act, enforced through control packages tied to specific compliance regimes. Reach for it only when those combined guarantees are stated, not for plain residency.

Trap Reaching for Assured Workloads when only data residency is needed; a resource-location org policy already pins the region, and Assured Workloads adds heavier access and personnel controls you were not asked for.

VPC Service Controls blocks cross-perimeter API access even with valid IAM

A VPC Service Controls service perimeter surrounds projects and their Google-managed services: communication inside is free and communication across the boundary is blocked by default. It is context-based and independent of IAM, so a caller holding valid IAM permissions is still denied across the perimeter, which makes it the data-exfiltration control. Controlled exceptions are ingress and egress rules, and dry-run mode logs would-be blocks before enforcing.

Trap Expecting VPC Service Controls to filter packet-level VM traffic; it governs Google API access such as a BigQuery API call, while VPC firewall rules handle network packets between VMs.

8 questions test this
Separate development and production into different projects

Putting development and production in separate Google Cloud projects ensures a test job can never read or corrupt production data and that IAM, quotas, billing, and audit logs are scoped cleanly per environment. A folder per environment lets one inherited IAM and Organization Policy set govern every project beneath it, so controls and isolation are applied once at the folder rather than reconfigured per project.

Trap Sharing one project across dev and prod to save setup, which lets test workloads reach production data and entangles billing, quotas, and audit logs across environments.

Model datasets and tables so the IAM boundary matches how teams share data

Because dataset-level grants are the natural BigQuery IAM boundary, group tables into datasets along the lines teams actually share data, so access is granted by dataset rather than clawed back table by table. A dataset per team or per sensitivity tier keeps the grant simple and auditable, whereas one giant dataset forces fine-grained exceptions that drift over time.

Block service-account keys org-wide with iam.disableServiceAccountKeyCreation and override per project

Enforce constraints/iam.disableServiceAccountKeyCreation at the organization level to stop anyone from creating long-lived service-account keys, regardless of their IAM permissions; pair it with iam.automaticIamGrantsForDefaultServiceAccounts to stop default service accounts getting Editor automatically. Both are enforced by default for organizations created after May 3, 2024. Grant emergency exceptions by overriding the constraint with enforcement disabled on a specific project, not by loosening IAM.

Trap Reaching for IAM role tweaks or written policy to stop key creation when only an organization policy constraint can block it across all current and future projects.

4 questions test this
Grant the service agent CryptoKey Encrypter/Decrypter on the key, and keep KMS in its own project

To protect BigQuery (or Cloud Storage) with a CMEK key, grant that product's service account roles/cloudkms.cryptoKeyEncrypterDecrypter on the Cloud KMS key before creating the resource. Hosting the key in a separate, dedicated KMS project gives separation of duties so key administrators are not the same principals that use the key in workloads.

Trap Granting the human user or workload identity the encrypt/decrypt role instead of the product's own service agent, which is the principal BigQuery actually uses to call KMS.

3 questions test this
A CMEK key ring must sit in the exact same location as the resource it protects

Cloud KMS requires the key ring's location to match the data's location: a US multi-region BigQuery dataset or bucket needs a key ring in the US multi-region, and a us-east1 bucket needs a key ring in us-east1. A multi-region resource cannot use a regional key, and a regional resource cannot borrow a key from another region.

Trap Creating one regional key ring (e.g. us-central1) and trying to reuse it for buckets or datasets in other regions or multi-regions.

3 questions test this
Rotating a CMEK key does not re-encrypt existing data

Key rotation only creates a new primary version for future writes. Existing BigQuery tables keep the key version they were created with, and existing Cloud Storage objects keep their original version; only newly created tables/objects use the new version. To move existing data onto the latest version you must explicitly re-encrypt it (e.g. bq update with --destination_kms_key, or copying the data with the new key specified).

Trap Assuming automatic rotation re-encrypts old tables and satisfies a compliance requirement for current-version encryption without any further action.

4 questions test this
Mandate CMEK for a service with restrictNonCmekServices, and pin the key project with restrictCmekCryptoKeyProjects

Add a service such as bigquery.googleapis.com to the Deny list of constraints/gcp.restrictNonCmekServices and any resource created in that service without a CMEK key is rejected, while existing resources stay accessible. Combine it with constraints/gcp.restrictCmekCryptoKeyProjects to require that the keys come only from an approved KMS project.

Trap Trying to force CMEK with IAM permissions or per-table settings instead of the organization policy constraint that fails non-CMEK resource creation.

3 questions test this
BigQuery Data Access audit logs are on by default and cannot be disabled

Unlike most services where Data Access audit logs are off until you enable them, BigQuery's Data Access logs are always on and immutable, giving immediate who-accessed-what-and-when visibility. For org-wide compliance, route them with an organization-level aggregated sink using --include-children so current and future projects are covered, and remember Admin Activity and System Event logs live in the _Required bucket with a fixed 400-day retention.

Trap Enabling Data Access logs for BigQuery from scratch (or assuming they are off) when they are already capturing access by default.

3 questions test this
Use ingress rules for inbound partner access and a single common perimeter for the strongest exfiltration defense

VPC Service Controls ingress rules let outside principals (e.g. a partner project/service account) reach protected resources, scoped down to specific identities and read-only methods; access levels in Access Context Manager add IP-range and device-trust conditions. For maximum exfiltration protection with least overhead, prefer one common unified perimeter over many small perimeters, and diagnose blocks with the VPC-SC troubleshooter using the unique ID in the denial.

Trap Using an egress rule (outbound) when the requirement is to let an external partner read in, which is what an ingress rule controls.

6 questions test this
Service Account User attaches a SA to a resource; Token Creator mints short-lived credentials to impersonate it

Grant roles/iam.serviceAccountUser on a service account so a developer can attach it to a job (like Dataflow) without being able to create, delete, or modify the account. Grant roles/iam.serviceAccountTokenCreator when someone must impersonate the account to generate short-lived credentials, for example to test locally as a production pipeline's identity without holding standing access to production data.

Trap Granting Token Creator when the user only needs to run a job under a service account, or handing out a downloaded service-account key instead of impersonation.

2 questions test this

Also tested in

References

  1. IAM overview
  2. Customer-managed encryption keys (CMEK)
  3. Sensitive Data Protection overview
  4. Organization Policy Service overview
  5. VPC Service Controls overview
  6. Cloud Storage access control
  7. IAM deny policies overview
  8. Default encryption at rest
  9. Cloud HSM
  10. BigQuery column-level security
  11. BigQuery dynamic data masking
  12. Assured Workloads overview