A financial enterprise is designing a streaming ingestion pipeline to import sensitive customer transactions from an on-premises datacenter into a BigQuery data warehouse. The architecture must satisfy several strict security, encryption, and auditability requirements: Sensitive fields must be protected before leaving the on-premises network and remain encrypted at the column level within BigQuery, requiring dual-access control where analysts need explicit permissions to both the table and the decryption key to view cleartext. All ingestion components (Pub/Sub topics, Dataflow jobs, and BigQuery datasets) must be encrypted at rest using Customer-Managed Encryption Keys (CMEK) backed by Cloud HSM in the matching geographical region. Automated deployment processes and engineers must interact with cloud resources without downloading or storing long-lived service account JSON keys. Ingestion operations and CI/CD pipeline actions must maintain an auditable trail that can be correlated with Cloud Audit Logs. Which architecture and implementation strategy satisfies these requirements?

Encrypt sensitive fields on-premises using the Tink library with Data Encryption Keys (DEKs) wrapped by a Cloud HSM Key Encryption Key (KEK), store wrapped DEKs and encrypted data in BigQuery for AEAD decryption, enforce regional Cloud HSM CMEK across Pub/Sub, Dataflow, and BigQuery, require service account impersonation using the Service Account Token Creator role, and add the X-Goog-Request-Reason header to deployment API requests.: ### What the Solution Is This architecture establishes an end-to-end secure, auditable, and compliant data ingestion architecture by combining **client-side envelope encryption**, **Customer-Managed Encryption Keys (CMEK)**, **short-lived credential management**, and **audit log enrichment** across Google Cloud services. ### How It Meets the Requirements - **Column-Level Protection and Dual-Access Control**: By using the open-source **Tink** encryption library on-premises, sensitive transaction data is encrypted with local **Data Encryption Keys (DEKs)** before egress. These DEKs are wrapped using a symmetric **Key Encryption Key (KEK)** managed in **Cloud HSM**. In BigQuery, functions using **AEAD encryption** allow authorized users with access to both the dataset and the Cloud KMS crypto key to unwrap the DEK and decrypt specific column data, enforcing dual-access control. - **Regional Cloud HSM CMEK**: Pub/Sub topics, Dataflow pipelines, and BigQuery datasets are configured with **CMEK** hosted in **Cloud HSM** in the same geographical region as the compute and storage resources, ensuring cryptographic protection at rest. - **Eliminating Long-Lived Service Account Keys**: Rather than exporting persistent JSON keys, engineers and automated CI/CD runners use **service account impersonation**. Users granted the **Service Account Token Creator** (`roles/iam.serviceAccountTokenCreator`) role generate short-lived OAuth 2.0 access tokens, mitigating credential leakage risks. - **Auditability and Traceability**: Including the `X-Goog-Request-Reason` HTTP header on API requests embeds the deployment run ID directly into **Cloud Audit Logs**, allowing teams to correlate deployment execution logs with infrastructure modifications. ### Key Advantages and Capabilities - **Defense-in-Depth Cryptography**: Protects data on-premises, in flight, and at rest in BigQuery columns. - **Strict Cryptographic Isolation**: FIPS 140-2 Level 3 validated hardware protection via **Cloud HSM**. - **Credential Hygiene**: Eliminates static service account key distribution across local developer workstations and CI/CD environments. - **Deterministic Log Correlation**: Simplifies security incident investigation by binding build identifiers to Google Cloud API actions. ### Why This Is Optimal This solution fully satisfies all security constraints without architectural compromises. It leverages native Google Cloud services (**Cloud KMS/HSM**, **BigQuery AEAD functions**, **Cloud IAM**, and **Cloud Logging**) to minimize operational complexity while providing maximum security and auditability.

Secure Streaming Ingestion Cmek Auditability | professional-cloud-data-engineer

Secure Streaming Ingestion Cmek Auditability

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial enterprise is designing a streaming ingestion pipeline to import sensitive customer transactions from an on-premises datacenter into a BigQuery data warehouse. The architecture must satisfy several strict security, encryption, and auditability requirements:

Sensitive fields must be protected before leaving the on-premises network and remain encrypted at the column level within BigQuery, requiring dual-access control where analysts need explicit permissions to both the table and the decryption key to view cleartext.
All ingestion components (Pub/Sub topics, Dataflow jobs, and BigQuery datasets) must be encrypted at rest using Customer-Managed Encryption Keys (CMEK) backed by Cloud HSM in the matching geographical region.
Automated deployment processes and engineers must interact with cloud resources without downloading or storing long-lived service account JSON keys.
Ingestion operations and CI/CD pipeline actions must maintain an auditable trail that can be correlated with Cloud Audit Logs.

Which architecture and implementation strategy satisfies these requirements?

Encrypt fields on-premises using standard AES-CBC with static symmetric keys, assign the Service Account User role directly to engineers with downloaded JSON keys, configure default Google-managed encryption on Pub/Sub and BigQuery, and export all Data Access audit logs to Cloud Storage without request headers.

Encrypt sensitive fields on-premises using the Tink library with Data Encryption Keys (DEKs) wrapped by a Cloud HSM Key Encryption Key (KEK), store wrapped DEKs and encrypted data in BigQuery for AEAD decryption, enforce regional Cloud HSM CMEK across Pub/Sub, Dataflow, and BigQuery, require service account impersonation using the Service Account Token Creator role, and add the X-Goog-Request-Reason header to deployment API requests.

Encrypt records using client-side Tink encryption with third-party external HSM keys, grant analysts direct table permissions while disabling BigQuery audit logs to optimize query slot performance, and store static service account keys in Secret Manager for deployment pipelines.

Ingest plaintext data over Cloud Interconnect into Pub/Sub, execute Dataflow to tokenize data using multi-region Cloud KMS software keys located in a different region, grant the BigQuery Admin role to analysts, and rely on standard Cloud Logging retention without custom metadata.

Professional Cloud Data Engineer

Secure Streaming Ingestion Cmek Auditability

Related questions