An enterprise is designing a secure data ingestion and processing architecture to import sensitive financial records from an on-premises data center into Google Cloud. The design must fulfill the following security and cryptographic requirements: Sensitive fields must undergo client-side field-level encryption on-premises before being transmitted across a Dedicated Interconnect connection. The Data Encryption Keys (DEKs) used for field-level encryption must never be stored in plaintext and must be protected using envelope encryption with Key Encryption Keys (KEKs) hosted in Cloud KMS/Cloud HSM. A streaming Dataflow pipeline must ingest the encrypted records and store both the encrypted payload and the wrapped DEK into BigQuery. Authorized data analysts must be able to decrypt the granular fields on-demand directly in SQL queries, enforced by IAM permissions on the KEK. Which cryptographic design and implementation meets these requirements?

Encrypt sensitive fields on-premises using the Tink encryption library with local DEKs, wrap the DEKs using a Cloud KMS/Cloud HSM symmetric KEK, ingest the ciphertext and wrapped DEK via Dataflow into BigQuery, and use BigQuery AEAD functions for query-time column decryption.: ### What the Tink and BigQuery AEAD Envelope Encryption Architecture Is This architecture leverages the **Tink cryptographic library** on-premises alongside **Cloud Key Management Service (Cloud KMS)** or **Cloud HSM** to implement client-side **envelope encryption** and column-level access controls. Tink generates localized **Data Encryption Keys (DEKs)** to encrypt specific sensitive fields (such as credit card numbers or account identifiers) before data leaves the corporate perimeter, while the DEKs themselves are securely wrapped (encrypted) by a centralized **Key Encryption Key (KEK)** managed in Cloud KMS/Cloud HSM. ### How it Meets the Stated Requirements - **Client-Side Field-Level Encryption**: By applying Tink locally on-premises, sensitive data attributes are converted into ciphertext prior to transit over Dedicated Interconnect, providing end-to-end payload security. - **Envelope Encryption for DEKs**: DEKs are generated per dataset/session and immediately wrapped by the Cloud KMS/Cloud HSM symmetric KEK. Plaintext DEKs are never written to disk or sent across the network. - **Ingestion via Dataflow to BigQuery**: Dataflow processes the streaming records containing the ciphertext and wrapped DEKs, loading both into BigQuery storage tables. - **On-Demand SQL Decryption with IAM**: BigQuery natively supports **AEAD (Authenticated Encryption with Associated Data)** decryption functions (such as `AEAD.DECRYPT_STRING` or keyset functions). Analysts running queries unwrap the DEK and decrypt values dynamically at runtime only if their identity has IAM `roles/cloudkms.cryptoKeyDecrypter` permissions on the wrapping KEK. ### Key Advantages - **Dual-Access Control**: Decryption requires access permissions on both the BigQuery table and the Cloud KMS cryptographic key. - **Cryptographic Independence**: Google Cloud infrastructure never sees plaintext data in transit or in the ingestion buffer unless authorized by IAM during query execution. - **Standardized Cryptography**: Tink provides cross-platform, deterministic, and non-deterministic AEAD primitives that integrate directly with BigQuery standard SQL functions. - **Granular Key Rotation**: KEKs can be rotated automatically in Cloud KMS every 30 days without needing to re-encrypt all historical stored data chunks. ### Why This Is Optimal This pattern provides defense-in-depth by combining transport encryption, customer-managed envelope encryption, and granular column-level access control without requiring custom decryption microservices in front of BigQuery.

Client Side Aead Envelope Encryption Dataflow | professional-cloud-data-engineer

Client Side Aead Envelope Encryption Dataflow

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.

An enterprise is designing a secure data ingestion and processing architecture to import sensitive financial records from an on-premises data center into Google Cloud. The design must fulfill the following security and cryptographic requirements:

Sensitive fields must undergo client-side field-level encryption on-premises before being transmitted across a Dedicated Interconnect connection.
The Data Encryption Keys (DEKs) used for field-level encryption must never be stored in plaintext and must be protected using envelope encryption with Key Encryption Keys (KEKs) hosted in Cloud KMS/Cloud HSM.
A streaming Dataflow pipeline must ingest the encrypted records and store both the encrypted payload and the wrapped DEK into BigQuery.
Authorized data analysts must be able to decrypt the granular fields on-demand directly in SQL queries, enforced by IAM permissions on the KEK.

Which cryptographic design and implementation meets these requirements?

Generate an asymmetric RSA key pair in Secret Manager, encrypt sensitive columns using the public key on-premises, load the data via Dataflow into BigQuery, and decrypt values during queries using a BigQuery remote User-Defined Function (UDF) that calls Secret Manager.

Encrypt sensitive fields on-premises using the Tink encryption library with local DEKs, wrap the DEKs using a Cloud KMS/Cloud HSM symmetric KEK, ingest the ciphertext and wrapped DEK via Dataflow into BigQuery, and use BigQuery AEAD functions for query-time column decryption.

De-identify data on-premises using the Sensitive Data Protection API via public REST endpoints, write the pseudonymized records to Cloud Storage, and use Cloud Dataproc with Apache Spark to re-identify the data in memory before saving to BigQuery.

Encrypt full files on-premises using Customer-Supplied Encryption Keys (CSEK), store the plaintext DEKs inside Pub/Sub message attributes, decrypt the files inside Dataflow workers using custom transforms, and write the raw plaintext data into BigQuery tables protected with CMEK default dataset keys.

Professional Cloud Data Engineer

Client Side Aead Envelope Encryption Dataflow

Related questions