A financial services organization is designing a data storage architecture on Google Cloud to store sensitive transaction records. The organization's security policy defines the following compliance and operational requirements: The organization must retain administrative control over encryption key lifecycle actions, including setting automatic rotation schedules and immediately disabling access to keys when necessary. Security administrators must be able to enforce key usage and restrict key locations centrally using Google Cloud organization policies. Native Google Cloud services must seamlessly integrate with the key management solution without requiring the organization to store or transmit raw cryptographic keys in individual API requests. Which encryption key management approach should the organization implement?

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS): What Customer-Managed Encryption Keys (CMEK) are Customer-managed encryption keys (CMEK) allow organizations to use Cloud Key Management Service (Cloud KMS) to create, manage, rotate, and control the cryptographic keys used to protect data at rest across Google Cloud services. While Google Cloud encrypts all customer content at rest by default, CMEK gives customers direct administrative control over the root keys that protect the data encryption keys. How it meets the requirements: Key lifecycle and access control (✓): With CMEK in Cloud KMS, administrators can define automated key rotation schedules, view detailed audit logs in Cloud Audit Logs, and instantly revoke access to encrypted data by disabling or destroying specific key versions. Organization policy enforcement (✓): CMEK integrates directly with Google Cloud Organization Policy Service, allowing administrators to enforce constraints such as constraints/gcp.restrictNonCmekServices (blocking creation of resources without CMEK) and constraints/gcp.restrictCmekCryptoKeyProjects (limiting authorized KMS key projects). Seamless service integration (✓): Native services (such as AlloyDB, Cloud Storage, and BigQuery) integrate directly with Cloud KMS using service account permissions. Users do not need to transmit raw cryptographic keys over the network with each API call. Key advantages and capabilities: Granular IAM permissions: Manage who can encrypt, decrypt, or administrate keys using standard Google Cloud IAM roles like roles/cloudkms.cryptoKeyEncrypterDecrypter and roles/cloudkms.admin. Centralized auditing: All cryptographic operations performed by Google Cloud services generate Cloud Audit Logs, providing a verifiable record for regulatory compliance. Automated key management: Cloud KMS handles automated rotation, cryptographic versioning, and secure key storage within FIPS 140-2 validated infrastructure (or Hardware Security Modules via Cloud HSM). Broad GCP ecosystem support: Supported natively across almost all Google Cloud data services, including AlloyDB, BigQuery, Compute Engine, Cloud Storage, and NetApp Volumes. Why this is optimal: CMEK strikes the ideal balance between regulatory compliance, centralized control, and operational simplicity. It fulfills strict audit and key governance requirements while retaining seamless cloud automation.

CMEK Rotation Without Handling Raw Keys

Using CMEK for Rotation and Policy Control

A financial services organization is designing a data storage architecture on Google Cloud to store sensitive transaction records. The organization's security policy defines the following compliance and operational requirements:

The organization must retain administrative control over encryption key lifecycle actions, including setting automatic rotation schedules and immediately disabling access to keys when necessary.
Security administrators must be able to enforce key usage and restrict key locations centrally using Google Cloud organization policies.
Native Google Cloud services must seamlessly integrate with the key management solution without requiring the organization to store or transmit raw cryptographic keys in individual API requests.

Which encryption key management approach should the organization implement?

Google-managed encryption keys (GMEK)

Client-side encryption using custom local software before data upload

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

Customer-supplied encryption keys (CSEK)

Explanations

Google-managed encryption keys (GMEK)

What Google-Managed Encryption Keys (GMEK) are:

Google-managed encryption keys (GMEK) represent the default encryption mechanism in Google Cloud. Under GMEK, Google automatically encrypts all customer data at rest using AES-256 without requiring any user configuration, setup steps, or extra fees. Google wholly manages key generation, rotation, storage, and access.

Why it doesn't meet the requirement:

No customer key lifecycle control (✗): Customers have no ability to define rotation intervals, disable keys, or destroy keys to revoke data access on demand.
No organization policy enforcement for custom keys (✗): GMEK cannot satisfy organization policies that explicitly enforce CMEK compliance (such as constraints/gcp.restrictNonCmekServices), which intentionally deny resources protected only by default GMEK.
Lacks compliance auditability: Because Google manages the keys internally, individual key usage events do not generate customer-visible Cloud Audit Logs.

Key characteristics and limitations:

Zero configuration: Applied automatically to all stored data across all Google Cloud services.
No administrative overhead: Handled entirely by Google's internal Key Management Service.
No granular access revocation: You cannot revoke access to a specific dataset by disabling a cryptographic key.

This answer would be correct if:

The scenario stated that the organization wanted standard, baseline encryption at rest with zero operational overhead, no requirement for custom key rotation policies, and no regulatory need to manage cryptographic keys.

View source documentation

Client-side encryption using custom local software before data upload

What Client-Side Encryption is:

Client-side encryption involves encrypting data on the local client machine or application tier using local encryption tools or libraries before transmitting the payload to Google Cloud storage or database endpoints.

Why it doesn't meet the requirement:

No native service integration (✗): Because data is ingested in ciphertext format, native cloud services (such as managed databases and analytics platforms) cannot index, query, or process the underlying fields natively without client-side decryption.
Lacks central organization policy governance in GCP (✗): Google Cloud organization policy constraints cannot verify, manage, or enforce client-side encryption algorithms or key projects.
High implementation complexity: Requires custom development within every client application to handle cryptographic primitives, initialization vectors, and key distribution.

Key characteristics and limitations:

Zero-knowledge cloud storage: The cloud provider only sees encrypted binary blobs.
Loss of native database capabilities: Features like database sorting, querying, filtering, and indexing become unusable in cloud services.
Client development overhead: Application developers must write and maintain the cryptographic code and key retrieval mechanisms.

This answer would be correct if:

The organization required an end-to-end zero-knowledge architecture where cloud infrastructure should never possess unencrypted data or have the capability to decrypt payloads under any circumstance.

View source documentation

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

What Customer-Managed Encryption Keys (CMEK) are

Customer-managed encryption keys (CMEK) allow organizations to use Cloud Key Management Service (Cloud KMS) to create, manage, rotate, and control the cryptographic keys used to protect data at rest across Google Cloud services. While Google Cloud encrypts all customer content at rest by default, CMEK gives customers direct administrative control over the root keys that protect the data encryption keys.

How it meets the requirements:

Key lifecycle and access control (✓): With CMEK in Cloud KMS, administrators can define automated key rotation schedules, view detailed audit logs in Cloud Audit Logs, and instantly revoke access to encrypted data by disabling or destroying specific key versions.
Organization policy enforcement (✓): CMEK integrates directly with Google Cloud Organization Policy Service, allowing administrators to enforce constraints such as constraints/gcp.restrictNonCmekServices (blocking creation of resources without CMEK) and constraints/gcp.restrictCmekCryptoKeyProjects (limiting authorized KMS key projects).
Seamless service integration (✓): Native services (such as AlloyDB, Cloud Storage, and BigQuery) integrate directly with Cloud KMS using service account permissions. Users do not need to transmit raw cryptographic keys over the network with each API call.

Key advantages and capabilities:

Granular IAM permissions: Manage who can encrypt, decrypt, or administrate keys using standard Google Cloud IAM roles like roles/cloudkms.cryptoKeyEncrypterDecrypter and roles/cloudkms.admin.
Centralized auditing: All cryptographic operations performed by Google Cloud services generate Cloud Audit Logs, providing a verifiable record for regulatory compliance.
Automated key management: Cloud KMS handles automated rotation, cryptographic versioning, and secure key storage within FIPS 140-2 validated infrastructure (or Hardware Security Modules via Cloud HSM).
Broad GCP ecosystem support: Supported natively across almost all Google Cloud data services, including AlloyDB, BigQuery, Compute Engine, Cloud Storage, and NetApp Volumes.

Why this is optimal:

CMEK strikes the ideal balance between regulatory compliance, centralized control, and operational simplicity. It fulfills strict audit and key governance requirements while retaining seamless cloud automation.

View source documentation

Customer-supplied encryption keys (CSEK)

What Customer-Supplied Encryption Keys (CSEK) are:

Customer-supplied encryption keys (CSEK) allow an organization to generate and maintain raw cryptographic keys outside of Google Cloud (such as on an on-premises Key Management System). With CSEK, the raw 256-bit AES key must be provided in the headers of every individual API call to encrypt or decrypt data.

Why it doesn't meet the requirement:

Requires transmitting raw keys per API request (✗): CSEK requires client applications to supply the raw AES key with every read and write operation, failing the requirement for seamless integration without passing raw keys.
Limited service integration (✗): CSEK is only supported on a very limited subset of Google Cloud services (primarily Cloud Storage and Compute Engine persistent disks) and cannot be used across managed database services like AlloyDB.
Cannot use CMEK organization policies (✗): Organization policies designed for Cloud KMS (such as constraints/gcp.restrictCmekCryptoKeyProjects) do not manage or enforce CSEK keys.

Key characteristics and limitations:

Strict key ownership: Google never stores the raw key on disk; the key is held strictly in memory during the operation and discarded immediately afterward.
Catastrophic data loss risk: If the customer loses their raw encryption key, Google cannot recover the data under any circumstances.
Heavy operational burden: Applications must securely store, inject, and transmit raw keys for all interactions.

This answer would be correct if:

The organization had an absolute regulatory mandate that raw root cryptographic keys must never reside within cloud infrastructure under any circumstances, and the workload was strictly limited to Cloud Storage or Compute Engine disks.

View source documentation

Last updated October 23, 2026

Using CMEK for Rotation and Policy Control

The organization must retain administrative control over encryption key lifecycle actions, including setting automatic rotation schedules and immediately disabling access to keys when necessary.
Security administrators must be able to enforce key usage and restrict key locations centrally using Google Cloud organization policies.
Native Google Cloud services must seamlessly integrate with the key management solution without requiring the organization to store or transmit raw cryptographic keys in individual API requests.

Which encryption key management approach should the organization implement?

Google-managed encryption keys (GMEK)

Client-side encryption using custom local software before data upload

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

Customer-supplied encryption keys (CSEK)

Explanations

Google-managed encryption keys (GMEK)

What Google-Managed Encryption Keys (GMEK) are:

Why it doesn't meet the requirement:

No customer key lifecycle control (✗): Customers have no ability to define rotation intervals, disable keys, or destroy keys to revoke data access on demand.
No organization policy enforcement for custom keys (✗): GMEK cannot satisfy organization policies that explicitly enforce CMEK compliance (such as constraints/gcp.restrictNonCmekServices), which intentionally deny resources protected only by default GMEK.
Lacks compliance auditability: Because Google manages the keys internally, individual key usage events do not generate customer-visible Cloud Audit Logs.

Key characteristics and limitations:

Zero configuration: Applied automatically to all stored data across all Google Cloud services.
No administrative overhead: Handled entirely by Google's internal Key Management Service.
No granular access revocation: You cannot revoke access to a specific dataset by disabling a cryptographic key.

This answer would be correct if:

View source documentation

Client-side encryption using custom local software before data upload

What Client-Side Encryption is:

Why it doesn't meet the requirement:

No native service integration (✗): Because data is ingested in ciphertext format, native cloud services (such as managed databases and analytics platforms) cannot index, query, or process the underlying fields natively without client-side decryption.
Lacks central organization policy governance in GCP (✗): Google Cloud organization policy constraints cannot verify, manage, or enforce client-side encryption algorithms or key projects.
High implementation complexity: Requires custom development within every client application to handle cryptographic primitives, initialization vectors, and key distribution.

Key characteristics and limitations:

Zero-knowledge cloud storage: The cloud provider only sees encrypted binary blobs.
Loss of native database capabilities: Features like database sorting, querying, filtering, and indexing become unusable in cloud services.
Client development overhead: Application developers must write and maintain the cryptographic code and key retrieval mechanisms.

This answer would be correct if:

The organization required an end-to-end zero-knowledge architecture where cloud infrastructure should never possess unencrypted data or have the capability to decrypt payloads under any circumstance.

View source documentation

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

What Customer-Managed Encryption Keys (CMEK) are

How it meets the requirements:

Key lifecycle and access control (✓): With CMEK in Cloud KMS, administrators can define automated key rotation schedules, view detailed audit logs in Cloud Audit Logs, and instantly revoke access to encrypted data by disabling or destroying specific key versions.
Organization policy enforcement (✓): CMEK integrates directly with Google Cloud Organization Policy Service, allowing administrators to enforce constraints such as constraints/gcp.restrictNonCmekServices (blocking creation of resources without CMEK) and constraints/gcp.restrictCmekCryptoKeyProjects (limiting authorized KMS key projects).
Seamless service integration (✓): Native services (such as AlloyDB, Cloud Storage, and BigQuery) integrate directly with Cloud KMS using service account permissions. Users do not need to transmit raw cryptographic keys over the network with each API call.

Key advantages and capabilities:

Granular IAM permissions: Manage who can encrypt, decrypt, or administrate keys using standard Google Cloud IAM roles like roles/cloudkms.cryptoKeyEncrypterDecrypter and roles/cloudkms.admin.
Centralized auditing: All cryptographic operations performed by Google Cloud services generate Cloud Audit Logs, providing a verifiable record for regulatory compliance.
Automated key management: Cloud KMS handles automated rotation, cryptographic versioning, and secure key storage within FIPS 140-2 validated infrastructure (or Hardware Security Modules via Cloud HSM).
Broad GCP ecosystem support: Supported natively across almost all Google Cloud data services, including AlloyDB, BigQuery, Compute Engine, Cloud Storage, and NetApp Volumes.

Why this is optimal:

View source documentation

Customer-supplied encryption keys (CSEK)

What Customer-Supplied Encryption Keys (CSEK) are:

Why it doesn't meet the requirement:

Requires transmitting raw keys per API request (✗): CSEK requires client applications to supply the raw AES key with every read and write operation, failing the requirement for seamless integration without passing raw keys.
Limited service integration (✗): CSEK is only supported on a very limited subset of Google Cloud services (primarily Cloud Storage and Compute Engine persistent disks) and cannot be used across managed database services like AlloyDB.
Cannot use CMEK organization policies (✗): Organization policies designed for Cloud KMS (such as constraints/gcp.restrictCmekCryptoKeyProjects) do not manage or enforce CSEK keys.

Key characteristics and limitations:

Strict key ownership: Google never stores the raw key on disk; the key is held strictly in memory during the operation and discarded immediately afterward.
Catastrophic data loss risk: If the customer loses their raw encryption key, Google cannot recover the data under any circumstances.
Heavy operational burden: Applications must securely store, inject, and transmit raw keys for all interactions.

This answer would be correct if:

View source documentation

Last updated October 23, 2026

Using CMEK for Rotation and Policy Control

Explanations

Google-managed encryption keys (GMEK)

What Google-Managed Encryption Keys (GMEK) are:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Client-side encryption using custom local software before data upload

What Client-Side Encryption is:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

What Customer-Managed Encryption Keys (CMEK) are

How it meets the requirements:

Key advantages and capabilities:

Why this is optimal:

Customer-supplied encryption keys (CSEK)

What Customer-Supplied Encryption Keys (CSEK) are:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Try 10 interactive questions like this one, free

Related questions

CMEK vs CSEK vs GMEK

CMEK vs CSEK vs GMEK

BigQuery Remote Model Vertex AI

Cloud SQL Enhanced Backups

Cloud Composer DAG Task Dependencies

Transit VPC NVA with Internal Passthrough Load Balancer

Using CMEK for Rotation and Policy Control

Explanations

Google-managed encryption keys (GMEK)

What Google-Managed Encryption Keys (GMEK) are:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Client-side encryption using custom local software before data upload

What Client-Side Encryption is:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Customer-managed encryption keys (CMEK) using Cloud Key Management Service (Cloud KMS)

What Customer-Managed Encryption Keys (CMEK) are

How it meets the requirements:

Key advantages and capabilities:

Why this is optimal:

Customer-supplied encryption keys (CSEK)

What Customer-Supplied Encryption Keys (CSEK) are:

Why it doesn't meet the requirement:

Key characteristics and limitations:

This answer would be correct if:

Try 10 interactive questions like this one, free

Related questions

CMEK vs CSEK vs GMEK

CMEK vs CSEK vs GMEK

BigQuery Remote Model Vertex AI

Cloud SQL Enhanced Backups

Cloud Composer DAG Task Dependencies

Transit VPC NVA with Internal Passthrough Load Balancer