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.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Import External Keys Cloud Kms Hsm Cmek

Section: Creating and managing encryption keys for CMEK and EKM (e.g., key rotation and revocation, key import).

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 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.

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.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Import External Keys Cloud Kms Hsm Cmek

Section: Creating and managing encryption keys for CMEK and EKM (e.g., key rotation and revocation, key import).

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?

Explanations

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.

View source documentation

Professional Cloud Security Engineer

Import External Keys Cloud Kms Hsm Cmek

Professional Cloud Security Engineer

Import External Keys Cloud Kms Hsm Cmek

What the Solution Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Related questions

BigQuery Generative AI Functions