Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Default CMEK Encryption for BigQuery and Cloud Storage
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.
Your organization is designing an enterprise data analytics platform in Google Cloud that processes highly regulated healthcare data across Cloud Storage and BigQuery.
Your security and compliance policies dictate the following requirements:
- All data at rest in Cloud Storage buckets and BigQuery datasets must achieve logical data separation and cryptographic isolation using keys owned and controlled by your organization.
- Cryptographic keys must be stored in FIPS 140-2 Level 3 Hardware Security Modules (Cloud HSM).
- A strict separation of duties must be enforced so that data engineers managing storage and analytics resources cannot administer or alter key management configurations.
- All tables created inside analytics datasets and objects written to ingestion buckets must automatically be encrypted without requiring engineers to explicitly supply key identifiers during write operations.
Which architecture and configuration strategy should you implement?
Explanations
Deploy Cloud KMS software-backed keys within the same project as the BigQuery datasets and Cloud Storage buckets, and grant data engineers the Cloud KMS Admin role so they can create and rotate keys on demand.
Deploy Cloud KMS software-backed keys within the same project as the BigQuery datasets and Cloud Storage buckets, and grant data engineers the Cloud KMS Admin role so they can create and rotate keys on demand.
What this option is
This strategy provisions standard software-protected Cloud KMS keys within the existing data workload project and gives data engineers administrative authority over the cryptographic keys.
Why it doesn't meet the requirement
- Fails Hardware Security Module (HSM) requirement: Provisioning software-backed keys (
protectionLevel: SOFTWARE) fails the compliance requirement to store keys in FIPS 140-2 Level 3 validated Cloud HSM hardware. - Violates separation of duties: Co-locating keys in the workload project and assigning data engineers the
roles/cloudkms.adminrole enables the same individuals who manage data to alter key lifecycles, disable keys, or modify access permissions, creating a significant security vulnerability. - Poor multi-tenant isolation: Managing keys in application projects increases the attack surface compared to isolating key governance in a central security project.
Key characteristics and limitations
- Software keys run inside Google's hardened key management infrastructure but lack dedicated hardware security boundary isolation.
- Placing both data assets and cryptographic keys in a single IAM security domain prevents independent auditing and strict least-privilege enforcement.
This answer would be correct if
The organization had no requirement for Cloud HSM or strict separation of duties, and sought a simplified single-project setup where developers have autonomous control over key lifecycles for development or non-regulated testing environments.
Create a dedicated key project for Cloud KMS and provision Cloud HSM-backed CMEK keys with appropriate IAM role separation. Set default CMEK encryption keys on the target BigQuery datasets and Cloud Storage buckets, and grant the respective service agents the Cloud KMS CryptoKey Encrypter/Decrypter role.
Create a dedicated key project for Cloud KMS and provision Cloud HSM-backed CMEK keys with appropriate IAM role separation. Set default CMEK encryption keys on the target BigQuery datasets and Cloud Storage buckets, and grant the respective service agents the Cloud KMS CryptoKey Encrypter/Decrypter role.
What this solution is
This architecture establishes a secure, centrally governed Customer-Managed Encryption Key (CMEK) deployment using Cloud KMS with Cloud HSM across dedicated Google Cloud projects to enforce cryptographic isolation and administrative separation of duties.
How it meets the requirements
- Cryptographic isolation and customer ownership: By utilizing Customer-Managed Encryption Keys (CMEK) stored within Cloud HSM, the organization satisfies FIPS 140-2 Level 3 compliance while maintaining complete ownership and lifecycle control over cryptographic materials.
- Separation of duties: Housing Cloud KMS keys in a dedicated
KEY_PROJECT_IDdistinct from the data analytics and storage projects ensures that data engineers who manage datasets and buckets do not hold administrative IAM permissions (roles/cloudkms.admin) over the keys. - Automatic encryption inheritance: Assigning a default KMS key at the BigQuery dataset and Cloud Storage bucket levels ensures that all newly created tables, query temporary results, and uploaded storage objects automatically inherit the default CMEK key without requiring manual flags or client-side key parameterization during daily data operations.
- Service agent enablement: Granting
roles/cloudkms.cryptoKeyEncrypterDecrypterdirectly to the BigQuery and Cloud Storage service accounts enables transparent server-side envelope encryption and decryption.
Key advantages and capabilities
- Envelope encryption: Leverages local Data Encryption Keys (DEKs) wrapped by Cloud HSM-backed Key Encryption Keys (KEKs).
- Centralized auditing: Allows centralized tracking and logging of all key use and cryptographic operations across services via Cloud Logging and Cloud Audit Logs.
- Reduced human error: Default resource-level configurations prevent accidental storage of plaintext or default-encrypted objects when developers create tables or upload files.
- FIPS compliance: Satisfies high-assurance regulatory requirements by utilizing hardware-backed protection levels.
Why this is optimal
This approach aligns with Google Cloud security best practices by combining isolated project boundaries for key management, hardware-backed keys, and automatic default key inheritance at the dataset and bucket scope, ensuring consistent protection without operational overhead.
Generate and manage customer-supplied encryption keys (CSEK) locally, pass the raw key strings via API headers during every Cloud Storage upload, and use federated queries in BigQuery to access the data directly.
Generate and manage customer-supplied encryption keys (CSEK) locally, pass the raw key strings via API headers during every Cloud Storage upload, and use federated queries in BigQuery to access the data directly.
What this option is
This configuration utilizes Customer-Supplied Encryption Keys (CSEK), where raw 256-bit encryption key strings are maintained on-premises and supplied in request headers for every individual API call to Cloud Storage.
Why it doesn't meet the requirement
- Incompatible with automated default inheritance: CSEK requires that client applications supply the raw cryptographic key on every single read and write request. It cannot be configured as a persistent default encryption key on BigQuery datasets or Cloud Storage buckets.
- Lack of broad BigQuery native table support: BigQuery native storage does not support CSEK for table storage or dataset-level default management; it natively integrates with Cloud KMS CMEK.
- Violates operational simplicity and security: Distributing raw cryptographic keys to every data ingestion job and data engineer creates substantial risk of key exposure and violates the principle of automated platform-managed encryption.
Key characteristics and limitations
- Google does not store CSEK keys on disk or in Cloud KMS; they reside only transiently in memory for the duration of the request.
- If a CSEK key is lost, all data encrypted with that key is permanently unrecoverable.
- CSEK is supported only for select services like Compute Engine disks and Cloud Storage objects, not for managing BigQuery datasets or Cloud SQL instances.
This answer would be correct if
The organization had a strict regulatory requirement that raw cryptographic key material must never be uploaded or stored in any cloud service, including Cloud KMS or Cloud HSM.
Rely on Google default encryption at rest for BigQuery datasets and Cloud Storage buckets, and implement BigQuery AEAD encryption functions at query runtime to manage logical data separation.
Rely on Google default encryption at rest for BigQuery datasets and Cloud Storage buckets, and implement BigQuery AEAD encryption functions at query runtime to manage logical data separation.
What this option is
This option relies entirely on Google default encryption at rest for storage infrastructure, paired with application-level SQL AEAD encryption functions for encrypting specific columns during query execution.
Why it doesn't meet the requirement
- Fails cryptographic isolation and key control: Google default encryption uses Google-managed keys rather than customer-owned keys. It does not provide tenant-level logical data separation through customer-controlled keys, nor does it allow the customer to dictate Cloud HSM backing.
- Does not enforce separation of duties: Applying query-level AEAD functions places the encryption burden on data analysts and query writers rather than enforcing an infrastructure-level separation of duties between key admins and storage operators.
- Lacks default automation across services: Default Google encryption does not allow assigning custom HSM CMEK policies at the dataset or bucket level, and AEAD functions do not protect Cloud Storage raw files automatically upon upload.
Key characteristics and limitations
- Default encryption is enabled automatically across Google Cloud using Google-owned KEKs in Keystore.
- DEKs are rotated and managed by Google without customer-managed rotation schedules or FIPS 140-2 Level 3 HSM guarantees.
- AEAD column-level encryption functions require explicit keyset management in standard SQL queries.
This answer would be correct if
The scenario required ad-hoc, fine-grained, column-level field obfuscation within BigQuery where individual column values must remain encrypted in memory and across distinct application tiers without managing bucket-level or dataset-level KMS keys.
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
Tink Envelope Encryption with BigQuery AEAD
Data security (encryption and key management)
AdvancedProfessional Data Engineer
Cloud KMS Imported Key Rotation
Data security (encryption and key management)
AdvancedProfessional Data Engineer
BigQuery Row Access Policy Grantee Scope
Managing the lake (configuring data discovery, access, and cost controls)
AdvancedProfessional Data Engineer
Cloud Monitoring BigQuery Query Execution Alerts
Monitoring the data lake
AdvancedProfessional Data Engineer
BigQuery Materialized View Partition Expiration Alignment
Designing the project, dataset, and table architecture to ensure proper data governance
FundamentalAssociate Data Practitioner
Uniform Bucket-Level Access
Compare methods of access control for Cloud Storage (e.g., public or private access, uniform access)
Last updated Validated