How to Encrypt Existing BigQuery Data at Rest with CMEK?
You have a BigQuery table that ingests data directly from a Pub/Sub subscription. The ingested data is encrypted with a Google-managed encryption key. You need to meet a new organization policy that requires you to use keys from a centralized Cloud Key Management Service (Cloud KMS) project to encrypt data at rest. What should you do?
Community Votes
58% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This question tests the precise scope of data at rest encryption policies versus streaming data pipelines, with the common trap being the assumption that all components in the ingestion chain must be reconfigured.
Migrating BigQuery tables to Customer-Managed Encryption Keys (CMEK) requires provisioning a new table with CMEK and copying historical data. Community consensus emphasizes that since the organization policy explicitly targets data at rest, only the BigQuery storage component needs re-encryption, while the Pub/Sub ingestion pipeline remains unchanged.
Option D is the most frequent incorrect choice, as candidates incorrectly apply CMEK to the Pub/Sub topic, misunderstanding that Pub/Sub functions primarily as a streaming ingestion mechanism rather than a long-term data-at-rest store.
Community Discussion (21 comments)
raaad
👍 11
Selected: B
- New BigQuery Table with CMEK: This option involves creating a new BigQuery table configured to use a CMEK from Cloud KMS. It directly addresses the need to use a CMEK for data at rest in BigQuery. - Migrate Data: Migrating data from the old table (encrypted with a Google-managed key) to the new table (encrypted with CMEK) ensures that all existing data complies with the new policy.
Blackstile
👍 1
The question did not say anything about the retention policy. Therefore, the correct answer is B. A tip for the exam: never answer what was not asked.
plum21
👍 1
Selected: D
There is data at rest in Pub/Sub, which is stated here in the docs: https://cloud.google.com/pubsub/docs/encryption At rest data -> Application layer -> CMEK encryption
Pime13
👍 1
Selected: B
B. There is no need to create a new pubsub topic since it can be updated with the note that change is not retroactive. https://cloud.google.com/pubsub/docs/encryption#update_cmek_for_a_topic
m_a_p_s
👍 1
Selected: B
B. You don't need to create a new topic in order to use the new CMEK. Existing topic can be updated to use the new key: https://cloud.google.com/pubsub/docs/encryption#update_cmek_for_a_topic
SamuelTsch
👍 2
Selected: B
should be B. Pub/Sub is not designed for storing data at rest.
gr3yWind
👍 1
Selected: B
Agree with raaad
shanks_t
👍 1
Selected: D
Requirement for Cloud KMS keys: The new organization policy requires using keys from a centralized Cloud KMS project for encrypting data at rest. This necessitates the use of customer-managed encryption keys (CMEK). BigQuery table encryption: The existing BigQuery table is encrypted with a Google-managed key. To meet the new policy, a new table needs to be created with CMEK. Pub/Sub topic encryption: Since the data is ingested directly from a Pub/Sub subscription, the Pub/Sub topic also needs to use CMEK to ensure end-to-end encryption with customer-managed keys. Data migration: The existing data in the old BigQuery table needs to be migrated to the new CMEK-encrypted table to ensure all data complies with the new policy
carmltekai
👍 2
Selected: B
"The best solution here is B. Create a new BigQuery table by using customer-managed encryption keys (CMEK), and migrate the data from the old BigQuery table. Here's why: Customer-Managed Encryption Keys (CMEK): CMEKs allow you to have granular control over your encryption keys, complying with the organization's policy to use keys from a centralized Cloud KMS project. Data Migration: Since the data in the existing table is already encrypted with a Google-managed key, you cannot retroactively change the encryption key for that table. Migrating the data to a new table with the correct encryption is the most efficient way to meet compliance.
Anudeep58
👍 2
Selected: D
D. Create a new BigQuery table and Pub/Sub topic by using customer-managed encryption keys (CMEK), and migrate the data from the old BigQuery table. This approach comprehensively addresses the requirement to use CMEK from a centralized Cloud KMS project for encrypting data at rest: Create a new Pub/Sub topic configured to use CMEK from the centralized Cloud KMS project. Create a new BigQuery table with CMEK enabled, using the same centralized Cloud KMS project. Update the ingestion process to use the new Pub/Sub topic to feed data into the new BigQuery table. Migrate existing data from the old BigQuery table to the new BigQuery table to ensure all data complies with the new encryption policy.
AlizCert
👍 2
Selected: B
B, been there, done that...
josech
👍 2
Selected: D
BigQuery and Pub/Sub shall be encrypted using CMEK using new versions of each one. https://cloud.google.com/pubsub/docs/encryption#using-cmek
chrissamharris
👍 2
Selected: B
Data at rest in requirement = Big Query ONLY. Pub/Sub is data in movement - overkill for the solution
f74ca0c
👍 1
Selected: D
D- BigQuery and Pub/sub are automatically encrypted but here we need to apply a more secured policy by using CMEK so we need to use it for bigquery and pub/sub to meet this policy
LaxmanTiwari
👍 2
Selected: B
B. Create a new BigQuery table by using customer-managed encryption keys (CMEK), and migrate the data from the old BigQuery table. Most Voted
amanbawa96
👍 1
Selected: B
BigQuery allows you to encrypt data at rest using either Google-managed encryption keys or customer-managed encryption keys (CMEK) from Cloud KMS. Since the new policy requires using keys from a centralized Cloud KMS project, you need to create a new BigQuery table that is configured to use CMEK for encryption. After creating the new table with CMEK, you can migrate the data from the old table (encrypted with Google-managed keys) to the new table (encrypted with CMEK). This approach ensures that the data in the BigQuery table is encrypted using the required CMEK while preserving the existing data. Creating a new BigQuery table and Pub/Sub topic with CMEK is not necessary because the focus is on encrypting the data at rest in BigQuery. The existing Pub/Sub subscription can still be used to ingest data into the new BigQuery table.
Izzyt99
👍 3
D - 'as new organization policy that requires you to use keys from a centralized Cloud Key Management Service (Cloud KMS) project to encrypt data at rest.' Therefore, the Pub/Sub default Google-managed encryption key is not sufficient as the organization requires it's own CMEK that is to be generated from a centralized Cloud KMS project.
cuadradobertolinisebastiancami
👍 1
Selected: D
Agree with ML6 and Smakyel. To encrypt data at rest we should encrypt the data in PubSub and BigQuery
ML6
👍 3
Only option D complies with the organisation policy: - By creating a new Pub/Sub topic with customer-managed encryption keys (CMEK), any new data ingested into Pub/Sub will be encrypted with the (!) organization's desired encryption keys (!). - Creating a new BigQuery table with CMEK ensures that all data stored in BigQuery, both newly ingested and migrated historical data, is encrypted according to organizational policies. - Migrating the data from the old BigQuery table to the new one ensures that historical data is also encrypted with the new keys, thus meeting the organization's requirements for encryption at rest for both Pub/Sub and BigQuery.
GCP001
👍 3
D. We should use new CMSK for both pubsub topic and BQ tables along with migrating old data.
Smakyel79
👍 3
Selected: D
This option ensures that both the ingestion mechanism (Pub/Sub) and the storage component (BigQuery) are aligned with the organization's policy of using CMEK, providing end-to-end encryption control.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Creating a new BigQuery table with CMEK and migrating existing data directly satisfies the organization requirement to encrypt data at rest using a centralized Cloud KMS key. BigQuery natively supports CMEK, and once the new table is configured, any future data ingested via the existing Pub/Sub subscription will automatically be stored with the new encryption key. Migration ensures compliance for historical records without disrupting the live ingestion pipeline.Why the Other Options Are Wrong
Option A unnecessarily introduces Dataflow, adding complexity when native BigQuery COPY or standard SQL migration tools suffice. Option C attempts to encrypt the Pub/Sub topic but leaves BigQuery unencrypted, failing the core requirement. Option D over-engineers the solution by applying CMEK to Pub/Sub, which is designed for real-time message streaming rather than persistent storage, making it redundant for this specific compliance mandate.Community Comment Notes
Several users correctly highlighted that Pub/Sub handles data in motion, not data at rest, making option B the most efficient path (Comments 6, 10). Others noted that while Pub/Sub does support CMEK, the prompt explicit focus on storage encryption points directly to BigQuery (Comment 7). The discussion reinforces that exam questions often test whether you can identify the exact resource bound by a compliance constraint.Official Reference
Exam Strategy
Always align your solution strictly with the compliance keywords in the prompt; data at rest targets persistent storage, while in transit or streaming would point to network or messaging layers. Resist the urge to over-engineer by modifying upstream services unless explicitly required by the scenario.