Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Client Side Column Encryption With Tink and HSM
Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
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?
Explanations
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 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.
What the Option Is
This approach relies on traditional static AES-CBC encryption managed completely outside Cloud KMS, issues static JSON service account keys to administrators, and accepts default Google-managed encryption at rest while exporting raw audit logs.
Why It Doesn't Meet the Requirements
- Lack of CMEK and Cloud HSM: Relying on default Google-managed keys directly violates the requirement to use regional Cloud HSM CMEK across Pub/Sub, Dataflow, and BigQuery.
- No Native Dual-Access Column Decryption: Static AES-CBC keys cannot be natively unwrapped or evaluated inside BigQuery queries via BigQuery AEAD functions, preventing granular in-database column-level access controls.
- Credential Leakage Risk: Downloading static service account JSON keys creates significant long-term credential exposure risks and violates the requirement to eliminate long-lived keys.
- Missing Audit Correlation: Exporting logs to Cloud Storage without populating request reason headers or custom request metadata fails to link external CI/CD runs to specific Cloud Audit Logs.
Key Limitations
- Static Key Management: Does not support envelope encryption or centralized Cloud KMS key access policies.
- Poor Governance: Downloading keys makes tracking access and enforcing rotation complex and error-prone.
- No Native In-Database Decryption: Queries cannot decrypt columns dynamically based on user IAM permissions.
This Answer Would Be Correct If
The organization did not require CMEK, had no need for BigQuery AEAD column-level decryption functions, and permitted local key management and exported service account JSON keys.
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 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-ReasonHTTP 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.
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.
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.
What the Option Is
This configuration uses third-party external hardware security modules without Cloud EKM/KMS integration, stores static JSON service account keys in Secret Manager, and disables BigQuery audit logging to conserve compute slots.
Why It Doesn't Meet the Requirements
- Improper Key Management Architecture: Managing external HSM keys without integrating them into Google Cloud KMS/EKM makes native BigQuery AEAD functions unable to reference key URIs for decryption at query runtime.
- Persistent Key Material in Secret Manager: While Secret Manager protects credentials, storing long-lived service account keys still exposes static credentials to pipeline runners instead of enforcing keyless service account impersonation.
- Disabled Auditability: Turning off or failing to configure audit logs completely destroys traceability, preventing security teams from correlating pipeline actions or monitoring table access.
- Misconception About Audit Performance: Disabling audit logging does not impact BigQuery query slot performance, as audit log emission is managed independently by Google Cloud control plane infrastructure.
Key Limitations
- Incompatible In-Database Decryption: BigQuery standard SQL AEAD functions require keysets managed through compatible formats or wrapped via Cloud KMS.
- Static Key Proliferation: Secret Manager stores static secrets, but does not eliminate the presence of long-lived service account keys.
- Compliance Non-Conformance: Removing audit logs prevents adherence to enterprise governance standards.
This Answer Would Be Correct If
External keys were strictly maintained off-cloud without BigQuery SQL decryption needs, and the deployment architecture relied on static secret retrieval rather than IAM impersonation.
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.
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.
What the Option Is
This option sends unencrypted plaintext across the network boundary, relies on post-ingestion tokenization via Dataflow using multi-region software-backed KMS keys, and grants broad dataset-level administrative IAM roles to data consumers.
Why It Doesn't Meet the Requirements
- No Client-Side Column Encryption: Transmitting plaintext data across the network boundary fails to secure sensitive columns prior to leaving the on-premises perimeter.
- Mismatched CMEK Location: Using a multi-region KMS key residing outside the local resource region violates the requirement that CMEK must reside in the exact same geographical location as the Pub/Sub, Dataflow, and BigQuery resources.
- Hardware Security Failure: Software-backed KMS keys do not fulfill the requirement for Cloud HSM hardware-backed key protection.
- Excessive Privileges: Granting
roles/bigquery.adminviolates least privilege and completely bypasses granular column-level dual-access control.
Key Limitations
- Exposed In-Flight Data: Plaintext data remains vulnerable if network interception occurs prior to Dataflow tokenization.
- Regional Key Restrictions: Cloud KMS keys configured across differing regions can cause compliance violations and performance latency.
- Overprivileged Users: Full administrative access removes fine-grained data segregation.
This Answer Would Be Correct If
The data did not contain confidential PII requiring client-side encryption, the pipeline allowed software-backed multi-region keys, and analysts required unrestricted schema and administrative controls over the warehouse.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 1,353 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
AdvancedProfessional Data Engineer
Pub/Sub Avro Schema Revision Deserialization
Data acquisition and import
AdvancedProfessional Data Engineer
Storage Transfer Service On-Premises Agents
Data acquisition and import
AdvancedProfessional Data Engineer
Apache Beam Runner Portability
Designing for data and application portability (e.g., multi-cloud and data residency requirements)
AdvancedProfessional Data Engineer
VPC Service Controls Analytics Hub Ingress Egress
Publishing datasets
AdvancedProfessional Data Engineer
Cloud Storage Object Lifecycle Management
Planning for storage costs and performance
IntermediateProfessional Cloud Architect
VPC Peering Non-Transitive Routing
Cloud-native networking (e.g., virtual private cloud [VPC], peering, firewalls, load balancers, routing, container networking, shared VPC, and Private Service Connect)
Last updated Validated