Encryption and Key Management (CMEK and CSEK)

Encryption is the process of scrambling data so that only someone with the correct key can read it. Think of it as a digital padlock. When you encrypt a file, it becomes unreadable gibberish to anyone except the person who has the key to unlock it. Google Cloud encrypts all customer data at rest (data stored on disk) and in transit (data moving across networks) by default, using keys that Google manages for you. These are called Google-managed encryption keys, and they are always active. You do not need to do anything — it is automatic.

But the PCSE exam focuses on the two situations where you, the customer, want more control over those keys. Those are Customer-Managed Encryption Keys (CMEK) and Customer-Supplied Encryption Keys (CSEK). Both live inside a Google Cloud service called Cloud Key Management Service (Cloud KMS). Cloud KMS is a centralised service to create, rotate, destroy, and audit cryptographic keys.

With CMEK, you create and manage the key material inside Cloud KMS, but the key is still stored in Google's infrastructure. You control when the key is enabled, disabled, or destroyed. You can also set permissions on who can use the key using Identity and Access Management (IAM) roles. The key never leaves Google Cloud. This is the most common choice for enterprises that need to meet compliance requirements such as showing auditors that they control the key lifecycle.

With CSEK, you supply the key yourself. You generate and manage the key outside of Google Cloud — for example, on your own hardware or on-premises key management system. You pass the key to Google Cloud at the time of data operation (like creating an encrypted disk or uploading an object to Cloud Storage). Google uses your key to encrypt or decrypt your data, but it does not store the key. After the operation, Google discards the key from memory. The risk is that if you lose your key, your data is permanently unrecoverable. The benefit is maximum control: Google never has persistent access to your key.

There is also a third option called Cloud External Key Manager (Cloud EKM), where you manage keys in an external key management partner that you control, and Google accesses them on the fly through a secure connection. Cloud EKM is important for the exam because it is sometimes tested as a hybrid between CMEK and CSEK.

Here is the key distinction tested on the exam:

Each of these options changes who is responsible for protecting the key. That responsibility is called the 'key management burden'. With Google-managed keys, the burden is entirely on Google. With CMEK, you share the burden because you manage the key's lifecycle but Google stores it. With CSEK, the full burden is on you — Google holds no copy.

When should you choose each? The PCSE exam tests this exact decision tree. If you need to meet a compliance standard like SOC 2 or PCI DSS that requires customer control over key material, choose CMEK. If you have a strict regulatory requirement that keys must never be stored by the cloud provider (for example, certain government or financial regulations), choose CSEK or Cloud EKM. If you have no special compliance need, Google-managed keys are fine and require no effort.

A common misunderstanding is that CSEK is always more secure. It is not necessarily more secure overall — it simply shifts the security risk from the provider to you. If your key management practices are weak, CSEK can be less secure than CMEK because you might store the key insecurely or lose it. Google's infrastructure for storing keys (CMEK) is already hardened and audited. The trade-off is control versus operational risk.

Another important concept is key rotation. Rotating a key means creating a new version of the key and retiring the old one, so that if an old key is compromised, new data is encrypted with a fresh key. CMEK supports automatic and manual rotation. You set a rotation period (e.g., every 90 days) and Cloud KMS automatically generates a new key version. Old versions are retained so you can still decrypt old data. CSEK does not support rotation in the same way because Google never stores the key — you must rotate the key yourself by supplying a new key next time.

Key destruction is equally important. With CMEK, you can schedule destruction of a key version with a 24-hour waiting period, during which you can cancel the destruction. After destruction, any data encrypted with that key version becomes permanently inaccessible. With CSEK, there is no key to destroy at Google's side; you manage destruction yourself.

Finally, Cloud KMS integrates with many Google Cloud services: Compute Engine (for persistent disk encryption), Cloud Storage (for object-level encryption), BigQuery, Cloud SQL, and more. When you use CMEK or CSEK with these services, the service contacts Cloud KMS to perform the encryption or decryption using your key. The service never receives the plaintext key — only the encrypted operation result.

Consider a healthcare technology startup that processes patient medical records in the United States. They are subject to HIPAA regulations, which require that they control who has access to the encryption keys that protect patient data. They have chosen Google Cloud to store their data. The IT security lead, Maria, must decide how to set up encryption.

Maria starts by mapping the data. Patient records will be stored in Cloud Storage buckets as encrypted objects. They will also use Compute Engine instances with encrypted persistent disks for processing. Each type of data must be protected by keys that the company controls. Maria chooses CMEK because it gives her the necessary compliance control without requiring her team to manage keys outside of Google Cloud.

Here is the step-by-step process Maria follows:

Maria never chose CSEK because the operational risk of losing the key was too high for patient data. If she lost the key, patients' medical records would be permanently inaccessible, which would be a regulatory disaster. CMEK gave her the control she needed with the safety net of Google's managed storage.

If the healthcare startup had a stricter regulation requiring that keys not be stored by the cloud provider at all — for instance, certain government contracts — Maria would have used Cloud EKM with a partner like Thales or Fortanix, where keys reside in an external system but are accessible on-demand.