Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Choosing CSEK, CMEK, and Cloud EKM
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.
An enterprise is designing a secure data ingestion and analytics pipeline on Google Cloud that must adhere to strict regulatory compliance and data sovereignty constraints:
- Ingestion Staging (Cloud Storage): Compliance mandates that raw file uploads use encryption where cryptographic key material is held exclusively by the customer, supplied in-memory on each API request, and never stored persistently anywhere on Google Cloud servers.
- Analytics Warehouse (BigQuery): The data warehouse must use dedicated symmetric keys managed within Google Cloud with customer control over rotation schedules, audit logging of key access, and the capability to perform crypto-shredding on demand.
- Data Sovereignty Constraint (Regulatory HYOK): Master key material for specific regulatory analytics tables must physically reside within an external on-premises key manager outside of Google Cloud, while still integrating with Google Cloud services for server-side decryption.
Which combination of encryption mechanisms should the enterprise implement?
Explanations
Use Google-owned and Google-managed default encryption for Cloud Storage, Customer-Supplied Encryption Keys (CSEK) for BigQuery, and Cloud KMS with imported software keys for the regulatory datasets.
Use Google-owned and Google-managed default encryption for Cloud Storage, Customer-Supplied Encryption Keys (CSEK) for BigQuery, and Cloud KMS with imported software keys for the regulatory datasets.
What This Option Proposes
This option suggests using Google default encryption for Cloud Storage file ingestion, CSEK for BigQuery analytics tables, and Cloud KMS key import (Bring Your Own Key - BYOK) for regulatory data assets.
Why It Doesn't Meet the Requirement
- Cloud Storage Compliance Failure: Google default encryption manages symmetric keys inside internal Keystore instances where Google owns and controls the keys. It does not satisfy the requirement for the customer to supply raw keys per API call without persistent storage on Google Cloud servers.
- Unsupported Service Operation: BigQuery does not support Customer-Supplied Encryption Keys (CSEK).
- Data Sovereignty Failure (HYOK vs BYOK): While imported software keys allow bringing existing key material into Cloud KMS (BYOK), once imported, the cryptographic material resides inside the Cloud KMS boundary on Google infrastructure. This fails the requirement for master keys to physically remain hosted on-premises in an external key manager (HYOK).
Key Limitations
- Default Encryption Lack of Control: Customers cannot manage rotation, view metadata, or inspect audit logs with default Google-managed keys.
- Imported Keys Reside in Cloud KMS: Key import does not fulfill external key residency requirements.
This Answer Would Be Correct If
The organization accepted Google-managed keys for staging files, BigQuery supported CSEK, and regulatory compliance permitted storing imported key copies directly inside Cloud KMS.
Use Customer-Supplied Encryption Keys (CSEK) for Cloud Storage, Customer-Managed Encryption Keys (CMEK) via Cloud KMS for BigQuery, and CMEK with Cloud External Key Manager (Cloud EKM) for the regulatory BigQuery datasets.
Use Customer-Supplied Encryption Keys (CSEK) for Cloud Storage, Customer-Managed Encryption Keys (CMEK) via Cloud KMS for BigQuery, and CMEK with Cloud External Key Manager (Cloud EKM) for the regulatory BigQuery datasets.
What This Architecture Is
This architecture combines Customer-Supplied Encryption Keys (CSEK), Customer-Managed Encryption Keys (CMEK) via Cloud KMS, and Cloud External Key Manager (Cloud EKM) to satisfy multi-tiered security, control, and data sovereignty requirements across distinct pipeline stages.
How It Meets Every Requirement
- Cloud Storage Staging (CSEK): CSEK allows clients to supply their own 256-bit AES cryptographic keys in the headers of individual API requests. Google uses the key transiently in-memory to encrypt or decrypt data and never persistently stores the key material on disk or within Cloud KMS.
- BigQuery Analytics Warehouse (CMEK with Cloud KMS): CMEK leverages Cloud KMS (software or Cloud HSM) where the customer controls the Key Encryption Key (KEK) lifecycle, configures automated rotation periods, audits access using Cloud Audit Logs, and can instantly revoke or destroy key versions to achieve cryptographic erasure (crypto-shredding).
- Regulatory HYOK Requirement (Cloud EKM): CMEK with Cloud EKM satisfies "Hold Your Own Key" (HYOK) requirements by maintaining master key material inside a third-party, on-premises external key management system while allowing integrated Google Cloud services to wrap and unwrap data encryption keys over a secure connection.
Key Advantages and Capabilities
- Strict Data Sovereignty: Maintains root keys outside Google Cloud infrastructure via Cloud EKM without losing integration with native managed data services.
- Ephemeral Key Handling: Guarantees through CSEK that Cloud Storage never retains customer key material at rest.
- Granular Lifecycle Control: Enables centralized key management, key rotation tracking, and instant crypto-shredding across BigQuery datasets.
- Separation of Duties: Keeps cryptographic management isolated from data access personas.
Why This Is Optimal
This configuration aligns precisely with the native capabilities and constraints of each Google Cloud service, correctly applying CSEK where supported and required (Cloud Storage) while using CMEK and Cloud EKM to govern BigQuery analytics workloads.
Use Cloud KMS customer-managed keys (CMEK) with software protection for Cloud Storage, CMEK with Cloud EKM for both Cloud Storage and BigQuery, and CSEK for the regulatory BigQuery datasets.
Use Cloud KMS customer-managed keys (CMEK) with software protection for Cloud Storage, CMEK with Cloud EKM for both Cloud Storage and BigQuery, and CSEK for the regulatory BigQuery datasets.
What This Option Proposes
This option suggests configuring Cloud KMS software-backed CMEK for Cloud Storage ingestion and using CSEK for regulatory BigQuery datasets.
Why It Doesn't Meet the Requirement
- Cloud Storage Key Storage: Cloud KMS software-backed CMEK stores the customer's Key Encryption Key (KEK) inside Google Cloud's KMS infrastructure. This violates the ingestion mandate stating that Google must never persistently store the key material.
- Unsupported BigQuery Encryption Mode: BigQuery does not support Customer-Supplied Encryption Keys (CSEK). Applying CSEK to BigQuery tables is impossible.
- Unnecessary EKM Overhead: Using Cloud EKM for staging when CSEK was specifically requested for raw file ingestion adds unnecessary operational dependencies.
Key Limitations
- CMEK Persists KEKs: All standard CMEK implementations persist key metadata and key material (or wrapping keys) inside Google Cloud KMS.
- CSEK Exclusivity: CSEK is restricted to Compute Engine and Cloud Storage only.
This Answer Would Be Correct If
The Cloud Storage ingestion layer required Cloud KMS-governed software keys and BigQuery supported CSEK for regulatory tables.
Use Customer-Supplied Encryption Keys (CSEK) for both Cloud Storage and BigQuery, and use Cloud KMS Autokey for the regulatory datasets requiring external key storage.
Use Customer-Supplied Encryption Keys (CSEK) for both Cloud Storage and BigQuery, and use Cloud KMS Autokey for the regulatory datasets requiring external key storage.
What This Option Proposes
This option proposes applying Customer-Supplied Encryption Keys (CSEK) across both Cloud Storage and BigQuery, while leveraging Cloud KMS Autokey for datasets governed by external on-premises key storage rules.
Why It Doesn't Meet the Requirement
- CSEK Service Limitations: CSEK is only supported by Cloud Storage and Compute Engine persistent disks. BigQuery does not support CSEK; attempting to supply raw key headers to BigQuery API calls will fail.
- Autokey Key Protection Level: Cloud KMS Autokey automatically provisions keys exclusively at the Cloud HSM (Hardware Security Module) protection level within Google Cloud infrastructure. It cannot create or route keys to an on-premises external key management provider (Cloud EKM), failing the regulatory HYOK requirement.
Key Limitations
- No BigQuery CSEK Integration: BigQuery requires server-side envelope encryption managed either via Google default keys or Cloud KMS CMEK.
- Autokey Scope: Autokey simplifies internal Cloud KMS provisioning for supported services but does not integrate with external key management systems.
This Answer Would Be Correct If
BigQuery natively supported client-supplied raw encryption keys on query execution, and the regulatory mandate allowed Google-hosted Cloud HSM keys generated automatically via Autokey instead of external key hardware.
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
Cloud SQL ENCRYPTED_ONLY Private Services Access VPC-SC
Data encryption
AdvancedProfessional Data Engineer
Cloud KMS Envelope Encryption
Data encryption
AdvancedProfessional Data Engineer
Spanner Normalization vs BigQuery Denormalization
Deciding the degree of data normalization
AdvancedProfessional Data Engineer
BigQuery Shuffle Quota Exceeded
Manage workloads, such as jobs, queries, and compute capacity (reservations)
AdvancedProfessional Data Engineer
Bigtable Row Key vs BigQuery Partitioning Clustering
Analyzing data access patterns
AdvancedProfessional Cloud Security Engineer
Workload Identity Federation Attribute Mapping and Conditions
Configuring Workload Identity Federation.
Last updated Validated