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?

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_ID`** distinct 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.cryptoKeyEncrypterDecrypter` directly 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.

Configure Cmek Cloud Hsm Bigquery Storage Separation Of Duties | professional-cloud-data-engineer

Configure Cmek Cloud Hsm Bigquery Storage Separation Of Duties

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.

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?

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.

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.

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.

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.

Professional Cloud Data Engineer

Configure Cmek Cloud Hsm Bigquery Storage Separation Of Duties

Related questions