Encryption questions on the Professional Data Engineer exam almost always come down to one decision: who holds the key. Google Cloud encrypts everything at rest by default, so the interesting question is never whether the data is encrypted. It is who created the key, where it lives, who can rotate it, and who can revoke it. Cloud KMS is the service that answers those questions, and the answer you pick changes both your security posture and your compliance story.
In this article I want to walk through the four key types you should know cold before sitting for the exam: Google-managed keys, customer-managed encryption keys (CMEKs), customer-supplied encryption keys (CSEKs), and External Key Manager (EKM). I will also touch on Cloud HSM and Tink, which are worth recognizing even though they are less likely to be the right answer on a scenario question.
If you do nothing, your data in BigQuery, Cloud Storage, Compute Engine, Pub/Sub, and every other GCP service is encrypted with Google-managed keys, sometimes called GMEKs. Google creates the key, Google rotates the key, Google stores the key, and Google retires the key. You never see it and you never touch it.
This is the right choice when you have no specific compliance requirement that forces you to control the key material. It is the lowest operational overhead option because there is literally nothing to operate. For internal analytics workloads where the data is sensitive but not regulated, this is usually fine. On the exam, if a scenario emphasizes simplicity and no regulatory pressure is mentioned, Google-managed keys are often the intended answer.
CMEKs are the keys you create and manage yourself inside Cloud KMS. Google still operates the key management infrastructure, but you decide when keys are created, rotated, disabled, or destroyed. This is the type the Professional Data Engineer exam leans on most heavily, and for good reason. CMEKs are the standard answer when a scenario says any of the following:
CMEKs cover the full key lifecycle: creation, usage, rotation, and revocation. Rotation is particularly important on the exam. You can configure automatic rotation on a schedule, and old key versions remain available to decrypt data encrypted under them while new data uses the latest version. Revocation matters too. Destroying a CMEK version makes any data encrypted under that version unreadable, which is a powerful tool for compliance scenarios that involve right-to-be-forgotten requirements or wind-downs of sensitive datasets.
Setting up a CMEK in BigQuery looks roughly like this:
gcloud kms keyrings create my-keyring \
--location=us-central1
gcloud kms keys create bq-cmek \
--location=us-central1 \
--keyring=my-keyring \
--purpose=encryption \
--rotation-period=90d \
--next-rotation-time=2026-08-01T00:00:00Z
bq mk --table \
--destination_kms_key=projects/my-project/locations/us-central1/keyRings/my-keyring/cryptoKeys/bq-cmek \
my_dataset.my_tableIf you remember nothing else, remember that CMEK is the default correct answer when the question mentions customer control, key rotation policy, or regulatory key management without any hint that the key must physically live outside Google.
CSEKs go a step further. Instead of creating the key in Cloud KMS, you generate it yourself outside Google Cloud and supply it on every request. Google holds the key only in memory long enough to encrypt or decrypt, then discards it. The catch is that CSEKs are supported only on Cloud Storage and Compute Engine persistent disks. They are not available for BigQuery, Pub/Sub, Dataflow, or most of the analytics stack a Professional Data Engineer works with daily.
This narrow scope is the trap on the exam. If a scenario mentions BigQuery and asks for customer-supplied key material, the answer is almost certainly CMEK rather than CSEK, because CSEK simply does not apply. Reserve CSEK for questions that explicitly involve GCS or Compute Engine and explicitly require that Google never store the key material.
EKM is for the strictest compliance scenarios. The key never enters Google Cloud at all. It lives in an external key management partner such as Thales, Fortanix, or Equinix SmartKey, and Cloud KMS calls out to the partner over a secure connection every time a key operation is needed. You get the strongest possible separation between your data (in Google Cloud) and your keys (outside Google Cloud).
On the exam, EKM is the answer when a scenario says something like "keys must remain in our existing on-premises HSM" or "the regulator requires that Google cannot access the key material under any circumstances." If the question stops short of that language and only asks for customer control, CMEK is still the better fit because EKM adds latency and operational complexity that you only pay for when you actually need it.
Cloud HSM is a flavor of CMEK where the key is generated and stored inside a FIPS 140-2 Level 3 hardware security module that Google operates on your behalf. It is the right answer when a scenario specifically calls out hardware-backed key storage but does not require the key to leave Google Cloud. Tink is an open-source cryptographic library for application-level encryption. It is useful in practice but rarely the focus of a Professional Data Engineer scenario question.
My shortcut for the exam is to read the scenario looking for three signals. If the question emphasizes simplicity and no compliance language appears, pick Google-managed. If the question mentions rotation, revocation, or customer control over keys for BigQuery, GCS, or Compute Engine, pick CMEK. If the question explicitly requires the key to live outside Google Cloud, pick EKM. CSEK only shows up when the scenario is locked to GCS or Compute Engine and demands customer-supplied material.
My Professional Data Engineer course covers Cloud KMS, CMEK configuration on BigQuery and GCS, and the full encryption decision tree alongside every other security and data-protection topic on the exam blueprint.
