Question

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

A company deploying Compute Engine virtual machines requires that persistent disks are encrypted using raw 256-bit AES encryption keys generated in their local data center. Security policy dictates that Google Cloud must never store these key strings at rest on Google infrastructure under any circumstances, and the keys must be supplied during disk creation and attach operations. Which encryption mechanism meets these requirements?

  1. Customer-Supplied Encryption Keys (CSEK)Answer
  2. B
    Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS
  3. C
    Google-default encryption using primitive Owner roles for access control
  4. D
    Google-default encryption protected by VPC Service Controls

Answer

Customer-Supplied Encryption Keys (CSEK) meet the requirement because the customer supplies their own raw 256-bit AES keys with each API call, and Google Cloud never persists these keys to disk.
Customer-Supplied Encryption Keys (CSEK) allow organizations to provide raw AES-256 keys directly to Compute Engine when creating or attaching disks. Google uses the key in memory to perform encryption/decryption operations and discards it immediately without writing the key material to persistent storage.

Step-by-Step Solution

1
Analyze key management requirements
The requirement specifies raw AES-256 keys generated on-premises that Google must never persist at rest.
Identifying key persistence and management boundary rules is critical for selecting the correct GCP encryption implementation.
2
Compare GCP encryption options against requirements
CSEK requires the caller to provide the key string for disk read/write/attach requests, while CMEK stores keys in Cloud KMS.
Only CSEK keeps key persistence completely off Google Cloud storage.

Key Concept

Customer-Supplied Encryption Keys (CSEK) vs Customer-Managed Encryption Keys (CMEK)
Rate this question