Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Rotating Imported HSM Keys in Cloud KMS
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 enterprise is designing a secure data analytics platform on Google Cloud that processes sensitive data across Cloud Storage and BigQuery. Your compliance and security officers mandate strict cryptographic controls with the following specific requirements:
- Hardware Security: Cryptographic key material must reside and execute within FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs).
- Key Custody (BYOK): The organization must generate and escrow its own 256-bit symmetric encryption keys on-premises before securely introducing them into Google Cloud.
- Separation of Duties: Key administrators (cryptographic officers) must be able to manage key lifecycles and versions, but must not possess permissions to perform direct cryptographic data operations (
encrypt/decrypt). Automated service agents must perform the cryptographic operations. - Lifecycle Maintenance: The key must support scheduled periodic rotation to limit cryptographic exposure over time.
Which strategy should the data engineering team implement to satisfy these architecture and compliance requirements?
Explanations
Create a Cloud KMS key with the protection level set to SOFTWARE, set an automatic rotation period of 90 days, and import the on-premises key material into version 1. Assign roles/cloudkms.admin to cryptographic officers and roles/cloudkms.cryptoKeyEncrypterDecrypter to service agents.
Create a Cloud KMS key with the protection level set to SOFTWARE, set an automatic rotation period of 90 days, and import the on-premises key material into version 1. Assign roles/cloudkms.admin to cryptographic officers and roles/cloudkms.cryptoKeyEncrypterDecrypter to service agents.
What the option does
This configuration creates a software-backed key in Cloud KMS, attempts to apply a native automatic rotation schedule to an imported key, and sets up standard IAM roles.
Why it doesn't meet the requirements
- Fails Hardware Security Requirement: Software-protected keys (
SOFTWAREprotection level) run on BoringCrypto software modules validated only up to FIPS 140-2 Level 1, failing the mandatory FIPS 140-2 Level 3 hardware requirement. - Fails Key Lifecycle Architecture: Cloud KMS cannot automatically generate new key versions on a schedule for imported keys (
ImportOnly). Setting an automatic rotation period (rotationPeriod) requires Cloud KMS to generate the new cryptographic material natively, which directly violates the BYOK on-premises generation mandate.
Key limitations
- Software-backed keys do not provide physical HSM isolation.
- Automatic rotation schedules are strictly unsupported for keys utilizing external/imported key material.
This answer would be correct if
The workload accepted FIPS 140-2 Level 1 compliance, allowed Google Cloud to generate internal key material natively, and required automated scheduled key version generation without an on-premises BYOK workflow.
Create a Cloud KMS key in a dedicated key project with the protection level set to HSM, configured with the ImportOnly flag and skipping initial version generation. Wrap the on-premises key using a Cloud KMS import job and import it as a new version. Grant roles/cloudkms.admin to cryptographic officers and roles/cloudkms.cryptoKeyEncrypterDecrypter to the storage service agents. Implement automated pipeline workflows to generate, wrap, and import new key versions on schedule.
Create a Cloud KMS key in a dedicated key project with the protection level set to HSM, configured with the ImportOnly flag and skipping initial version generation. Wrap the on-premises key using a Cloud KMS import job and import it as a new version. Grant roles/cloudkms.admin to cryptographic officers and roles/cloudkms.cryptoKeyEncrypterDecrypter to the storage service agents. Implement automated pipeline workflows to generate, wrap, and import new key versions on schedule.
What the solution is
This solution implements a robust Customer-Managed Encryption Key (CMEK) architecture utilizing Cloud KMS with Cloud HSM and Key Import (Bring Your Own Key - BYOK). It establishes strict separation of duties and secure key lifecycle management for sensitive analytics workloads.
How it meets all requirements
- Hardware Security: Setting the key's protection level to
HSMensures that all cryptographic operations and key material are hosted inside FIPS 140-2 Level 3 validated hardware security modules. - Key Custody (BYOK): Setting
ImportOnly: trueandSkipInitialVersionCreation: trueensures that Google Cloud does not generate default key material. The on-premises generated symmetric key is securely encrypted (wrapped) with a Cloud KMS public wrapping key in transit and unwrapped directly inside Cloud HSM. - Separation of Duties: Granting
roles/cloudkms.adminto cryptographic officers allows them to manage key rings, metadata, and import jobs without grantingroles/cloudkms.cryptoKeyEncrypterDecrypter(which is reserved for the automated BigQuery and Cloud Storage service agents). - Lifecycle Maintenance: Because Cloud KMS cannot automatically generate rotation material for imported keys, implementing external automation to regularly generate, wrap, and import new key versions satisfies the regular key rotation policy.
Key advantages
- Zero Plaintext Exposure: Key material is wrapped before transit and remains confined within Cloud HSM boundaries.
- Enforced Governance: A dedicated key project with granular Identity and Access Management (IAM) roles prevents unauthorized data access and adheres to NIST SP 800-152 standards.
- Primary Version Promotion: When a new imported key version is uploaded, it becomes the active primary version for subsequent CMEK encryption while older versions remain available for decryption.
Why this is optimal
This approach aligns strictly with enterprise compliance standards by maintaining on-premises key generation and escrow while leveraging Google Cloud's managed HSM infrastructure and automated service agent encryption.
Use Customer-Supplied Encryption Keys (CSEK) by transmitting the raw AES-256 key directly inside API request headers for Cloud Storage and BigQuery operations. Grant roles/cloudkms.admin and roles/cloudkms.cryptoKeyEncrypterDecrypter to the cryptographic officers to manage the lifecycle.
Use Customer-Supplied Encryption Keys (CSEK) by transmitting the raw AES-256 key directly inside API request headers for Cloud Storage and BigQuery operations. Grant roles/cloudkms.admin and roles/cloudkms.cryptoKeyEncrypterDecrypter to the cryptographic officers to manage the lifecycle.
What the option does
This approach utilizes Customer-Supplied Encryption Keys (CSEK), where client applications supply raw cryptographic keys with every individual API call, holding the key material only in transient memory during request processing.
Why it doesn't meet the requirements
- Fails Service Compatibility: While Cloud Storage supports CSEK, BigQuery does not natively support CSEK; BigQuery requires Google-managed encryption or Cloud KMS CMEK.
- Fails Hardware Security & HSM Requirement: CSEK keys are not stored or operated within FIPS 140-2 Level 3 Cloud HSM modules.
- Fails Separation of Duties: Granting
roles/cloudkms.cryptoKeyEncrypterDecrypterto cryptographic officers violates the principle of least privilege and separation of duties under NIST SP 800-152 guidelines.
Key limitations
- Requires client applications to manage, store, and transmit raw key material across the network on every transaction.
- Key material is not managed through Cloud KMS resource hierarchies or audited through KMS data access logs.
This answer would be correct if
The workload only involved Cloud Storage or Compute Engine persistent disks, required no server-side key retention in Google Cloud whatsoever, and did not require integration with BigQuery or Cloud HSM.
Deploy Cloud KMS Autokey in the data project folder to automatically create and provision HSM keys for BigQuery and Cloud Storage. Grant roles/owner on the project to cryptographic officers to oversee key and data lifecycles.
Deploy Cloud KMS Autokey in the data project folder to automatically create and provision HSM keys for BigQuery and Cloud Storage. Grant roles/owner on the project to cryptographic officers to oversee key and data lifecycles.
What the option does
This option uses Cloud KMS Autokey to automatically provision hardware-backed keys on demand as resources are created in the project, while assigning broad project ownership permissions.
Why it doesn't meet the requirements
- Fails BYOK Key Custody Requirement: Cloud KMS Autokey automatically generates brand new key material internally within Google Cloud's HSM clusters. It does not support importing externally generated and escrowed on-premises key material.
- Fails Separation of Duties: Assigning the primitive
roles/ownerrole gives cryptographic officers broad administrative and operational access across all project resources, violating the strict separation between key administrators and data consumers. - Violates Architecture Best Practices: Keys should reside in a centralized, dedicated KMS key project rather than inside the application data project.
Key limitations
- Autokey generates managed keys dynamically and cannot be used for custom Bring-Your-Own-Key import workflows.
- Primitive IAM roles (
Owner,Editor) bypass least privilege safeguards.
This answer would be correct if
The organization wanted fully automated, Google-managed key generation within Cloud HSM without requiring BYOK key import, custom escrow, or manual key lifecycle management.
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
BigQuery Cloud Storage Default CMEK Encryption
Data security (encryption and key management)
AdvancedProfessional Data Engineer
BigQuery Reservations Idle Slot Sharing
Capacity management (e.g., BigQuery Editions and reservations)
AdvancedProfessional Data Engineer
AlloyDB HTAP PostgreSQL Compatibility
Analyzing data access patterns
AdvancedProfessional Data Engineer
Apache Beam Runner Portability
Designing for data and application portability (e.g., multi-cloud and data residency requirements)
AdvancedProfessional Cloud DevOps Engineer
Kubernetes Ephemeral Debug Containers
Collecting metrics (e.g., from applications, platforms, networking, Cloud Service Mesh, Google Cloud Managed Service for Prometheus, hybrid/multi-cloud environments)
Last updated Validated