Question

Difficulty: Very hardData Encryption at Rest, in Transit, and Key Management (KMS/CMEK/CSEK)

Match each enterprise security and compliance requirement on the left with the corresponding Google Cloud key management implementation on the right.

  • The enterprise mandates strict key sovereignty where master encryption key material must permanently reside within an on-premises FIPS 140-2 Level 3 Hardware Security Module (HSM) outside Google Cloud, while permitting Cloud Storage and BigQuery to perform cryptographic operations via API calls.Cloud External Key Manager (Cloud EKM)
  • A regulatory compliance framework requires passing a raw, customer-generated 256-bit AES encryption key in the header of each individual API call for Cloud Storage object operations, ensuring no key material or key metadata is persisted in Google Cloud after the request completes.Customer-Supplied Encryption Keys (CSEK)
  • Internal security policies mandate customer control over key rotation schedules, destruction lifecycle, and IAM permission grants, while performing all cryptographic operations inside cloud-hosted, FIPS 140-2 Level 3 validated hardware security modules managed via Google Cloud APIs.Customer-Managed Encryption Keys (CMEK) using Cloud HSM
  • Standard baseline security policies require transparent data-at-rest encryption across all created storage resources with zero operational management overhead, requiring no custom IAM service account configuration or external cryptographic infrastructure.Google-default Encryption

Answer

1. External key sovereignty with on-premises key residence maps to Cloud External Key Manager (Cloud EKM).
2. Raw key supplied per API request without persistence maps to Customer-Supplied Encryption Keys (CSEK).
3. Customer key lifecycle control using cloud-hosted FIPS 140-2 Level 3 hardware maps to Customer-Managed Encryption Keys (CMEK) using Cloud HSM.
4. Transparent zero-overhead automatic protection maps to Google-default Encryption.
Each requirement maps to its exact cryptographic boundary: Cloud EKM keeps keys in external on-premises HSMs; CSEK requires raw key material passed per API call without persistence; CMEK with Cloud HSM provides customer control over keys residing in Google Cloud FIPS 140-2 Level 3 HSMs; Google-default provides automated, zero-overhead encryption.

Step-by-Step Solution

1
Analyze key residency and external control requirements.
Matched key sovereignty requiring keys to remain outside Google Cloud infrastructure to Cloud External Key Manager (Cloud EKM).
Cloud EKM connects Cloud KMS with external partner HSMs or on-premises key managers so key material never enters Google Cloud.
2
Evaluate key delivery mechanisms per API request.
Matched raw key supply per request header to Customer-Supplied Encryption Keys (CSEK).
CSEK requires raw key material in each API call and bypasses Cloud KMS storage completely.
3
Identify cloud-native HSM key management requirements.
Matched customer key management with FIPS 140-2 Level 3 cloud compliance to CMEK using Cloud HSM.
Cloud HSM hosts customer keys in managed FIPS 140-2 Level 3 hardware modules integrated with Cloud KMS.
4
Determine default platform encryption capability.
Matched zero-overhead automatic encryption to Google-default Encryption.
All GCP data at rest is encrypted by default using Google-managed keys without user configuration.

Key Concept

Architectural selection between Google-default Encryption, Customer-Managed Encryption Keys (CMEK/Cloud HSM), Customer-Supplied Encryption Keys (CSEK), and Cloud External Key Manager (Cloud EKM) based on compliance and custody requirements.
Rate this question