An enterprise security architect must establish a secure key lifecycle process to import on-premises generated 256-bit AES symmetric keys into Google Cloud KMS for use with Customer-Managed Encryption Keys (CMEK) across Cloud Storage and BigQuery. The solution must satisfy the following requirements: The imported cryptographic key material must be protected inside FIPS 140-2 Level 3 Hardware Security Modules. Key material must be cryptographically wrapped on-premises prior to transit, ensuring Google cannot unwrap the key outside the hardware security boundary. The imported symmetric key must be actively utilized for subsequent CMEK encryption operations. Workload access must enforce separation of duties between key administrators and storage/database services. Which end-to-end workflow and authorization strategy should the architect implement?

Create a target CryptoKey with protection level HSM and skip initial version creation; create an Import Job with HSM protection level and download its public wrapping key; wrap the raw 32-byte binary key locally using the public key, submit the import request, and manually set the imported version as primary; grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service agents.: ### What the Solution Is This workflow establishes a secure **Bring Your Own Key (BYOK)** lifecycle within Google Cloud KMS by manually preparing an empty target key, generating an ephemeral **Import Job** protected by Cloud HSM, cryptographically wrapping the key material on-premises, importing it, activating it as the primary version, and delegating cryptographic usage permissions to Google Cloud **service agents**. ### How It Meets the Requirements - **HSM Protection & FIPS 140-2 Level 3**: By configuring the target key and the Import Job with the `HSM` protection level, the private unwrapping key portion resides strictly within Google Cloud HSMs and cannot be accessed outside the hardware boundary. - **Cryptographic Wrapping in Transit**: The on-premises system retrieves the public wrapping key associated with the Import Job (using RSA-OAEP or RSA-AES-KWP) to encrypt the raw 32-byte AES key. Google unwraps the key payload exclusively inside the Cloud HSM boundary during the atomic import request. - **Primary Version Activation**: When importing symmetric keys into Cloud KMS, newly imported versions are not automatically designated as primary. Manually promoting the imported version to primary ensures all new CMEK encryption requests utilize this imported key material. - **Separation of Duties & Authorization**: Cloud Storage and BigQuery access CMEK resources via their respective managed service agents (e.g., `service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com`). Granting `roles/cloudkms.cryptoKeyEncrypterDecrypter` directly to these service agents—rather than human administrators or end users—enforces least privilege and strict role separation. ### Key Advantages - **Cryptographic Isolation**: The wrapping private key never leaves the Cloud HSM boundary. - **Integrity and Standard Compliance**: Accepts raw 32-byte unencoded binary keys compliant with AES-256 GCM requirements. - **Granular IAM Boundary**: Distinguishes administrative operations (`roles/cloudkms.admin`) from encryption/decryption execution. ### Why This Is Optimal This procedure fully aligns with Google Cloud key import specifications, guarantees end-to-end envelope protection during transit, ensures active CMEK utilization, and satisfies strict regulatory separation-of-duties standards.

Import External Keys Cloud Kms Hsm Cmek | Professional Cloud Security Engineer

Import External Keys Cloud Kms Hsm Cmek

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.

An enterprise security architect must establish a secure key lifecycle process to import on-premises generated 256-bit AES symmetric keys into Google Cloud KMS for use with Customer-Managed Encryption Keys (CMEK) across Cloud Storage and BigQuery.

The solution must satisfy the following requirements:

The imported cryptographic key material must be protected inside FIPS 140-2 Level 3 Hardware Security Modules.
Key material must be cryptographically wrapped on-premises prior to transit, ensuring Google cannot unwrap the key outside the hardware security boundary.
The imported symmetric key must be actively utilized for subsequent CMEK encryption operations.
Workload access must enforce separation of duties between key administrators and storage/database services.

Which end-to-end workflow and authorization strategy should the architect implement?

Create a target CryptoKey with protection level EXTERNAL; create an Import Job targeting the external key manager endpoint; wrap the key locally using the Cloud KMS master key, import the key version, and assign the Cloud KMS Admin role to the resource service agents.

Create a target CryptoKey with protection level HSM and skip initial version creation; create an Import Job with HSM protection level and download its public wrapping key; wrap the raw 32-byte binary key locally using the public key, submit the import request, and manually set the imported version as primary; grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service agents.

Format the symmetric key as a Base64-encoded string; create an Import Job with SOFTWARE protection level; submit the import request using standard TLS without wrapping; configure the key to automatically rotate, and grant the Cloud KMS CryptoKey Decrypter role to service agents.

Create a CryptoKey with default settings without skipping initial version creation; wrap the key using the Google Cloud project default public key; import the key payload into version 1, and grant the Cloud KMS CryptoKey Encrypter/Decrypter role directly to individual end-user identities.

Professional Cloud Security Engineer

Import External Keys Cloud Kms Hsm Cmek

Related questions