Key Encryption Key

Envelope Encryption – KMS Data Key Encryption

~ Last updated on : ~ jayendrapatil

Envelope Encryption

  • AWS KMS and Google Cloud KMS use a method called envelope encryption to protect the data.
  • Envelope encryption is an optimized method for encrypting data that uses two (or more) different keys — a Key Encryption Key (KEK) and a Data Encryption Key (DEK).
  • Master key is also known as Key Encryption Key – KEK and Data key is also known as Data Encryption Key – DEK.
  • Envelope encryption reduces the network load for the application or the cloud service as only the request and fulfillment of the much smaller data key through KMS must go over the network.
  • The data key is used locally by the encrypting service, avoiding the need to send the entire block of data to KMS and suffer network latency.
  • KMS can encrypt at most 4 KB of data directly. Envelope encryption allows encrypting arbitrarily large payloads by using locally generated data keys.
  • Envelope encryption can reduce KMS-related costs by up to 99% by minimizing the number of KMS API calls — only the data key wrapping/unwrapping goes through KMS, while encryption/decryption of actual data happens locally.

Envelope encryption key hierarchy

Root Key

  • A root key is an encryption key that is used to encrypt other encryption keys, such as data keys and key encryption keys. Unlike data keys and key encryption keys, root keys must be kept in plaintext so they can be used to decrypt the keys that they encrypted.
  • Key Management Service (KMS) generates and protects the root keys within FIPS 140-2 (AWS) or FIPS 140-3 (latest) validated Hardware Security Modules (HSMs).
  • In AWS KMS, root keys are referred to as KMS keys (previously called Customer Master Keys or CMKs — the CMK term was deprecated in August 2021).

Key Encryption Key – KEK

  • A key encryption key is an encryption key that is used to encrypt a data key or another key encryption key.
  • Key encryption key is encrypted (wrapped) by using a root key.
  • In Google Cloud KMS, the KEK is the Cloud KMS key used to wrap (encrypt) the DEK. The KEK never leaves Cloud KMS.

Data Encryption Key – DEK

  • A data key or data encryption key is an encryption key that is used to protect data.
  • Data keys differ from root keys and key encryption keys, which are typically used to encrypt other encryption keys.
  • Best practice is to use a strong algorithm such as 256-bit Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) for DEKs.
  • A new DEK should be generated every time data is written — this eliminates the need to rotate DEKs separately.
  • DEKs should always be stored encrypted (wrapped by a KEK) and near the data they encrypt for easy access.

Envelope Encryption Process

  • Encryption
    • Create a KMS key (root/master key) in your KMS service.
    • Generate a data key using the KMS API (e.g., AWS KMS GenerateDataKey API).
    • KMS returns both the plaintext data key and the encrypted (ciphertext) data key.
    • Use the plaintext data key locally to encrypt the data.
    • Store the encrypted data key alongside the encrypted data.
    • Immediately discard the plaintext data key from memory.
  • Decryption
    • Retrieve the ciphertext data key and encrypted data from storage.
    • Call KMS Decrypt API to decrypt the ciphertext data key using the KMS key. The plaintext data key is returned.
    • Use the plaintext data key to decrypt the data locally.
    • Discard the plaintext data key from memory after use.
  • Encrypting the data key is more efficient than re-encrypting the data under the new key because it is quicker and produces a much smaller ciphertext.

Envelope Encryption Benefits

  • Protecting data keys
    • When you encrypt a data key, you don’t have to worry about storing the encrypted data key, because the data key is inherently protected by encryption. You can safely store the encrypted data key alongside the encrypted data.
  • Encrypting the same data under multiple keys
    • Encryption operations can be time-consuming, particularly when the data being encrypted are large objects.
    • Instead of re-encrypting raw data multiple times with different keys, you can re-encrypt only the data keys that protect the raw data.
  • Combining the strengths of multiple algorithms
    • In general, symmetric key algorithms are faster and produce smaller ciphertexts than public key algorithms.
    • But public key algorithms provide inherent separation of roles and easier key management.
    • Envelope encryption lets you combine the strengths of each strategy.
  • Performance and scalability
    • Only the small data key (typically 256 bits) needs to transit the network to KMS, not the large data payload.
    • Reduces latency since encryption/decryption of the actual data is performed locally.
    • Helps stay within KMS API request rate quotas for high-throughput workloads.
  • Overcoming the 4 KB KMS size limit
    • KMS keys can only directly encrypt data up to 4 KB. Envelope encryption removes this limitation by using locally generated data keys for the actual encryption.

AWS KMS Envelope Encryption APIs

  • GenerateDataKey — Returns a plaintext data key and a copy encrypted under the specified KMS key. Use this when you need to encrypt data immediately.
  • GenerateDataKeyWithoutPlaintext — Returns only the encrypted data key. Use this when you don’t need to encrypt data immediately but want to store a key for future use.
  • GenerateDataKeyPair — Returns an asymmetric data key pair (public key in plaintext, private key in plaintext and encrypted). Useful for client-side encryption where different parties encrypt/decrypt.
  • GenerateDataKeyPairWithoutPlaintext — Returns only the public key in plaintext and the private key encrypted.
  • Encrypt — Encrypts up to 4 KB of plaintext directly using a KMS key (not envelope encryption).
  • Decrypt — Decrypts a ciphertext that was encrypted by a KMS key, including encrypted data keys.

AWS Encryption SDK

  • The AWS Encryption SDK is a client-side encryption library that implements envelope encryption as a best-practice pattern.
  • It generates a unique symmetric data key for each encryption operation by default.
  • Supports multiple wrapping keys (KMS keys) — allowing the same data to be decryptable by multiple keys.
  • Includes key commitment — ensures the ciphertext can only be decrypted to a single plaintext (prevents ciphertext ambiguity attacks).
  • Data Key Caching — An optional feature that reuses data keys for multiple encryption operations to reduce KMS API calls and cost. Should be used cautiously with appropriate security thresholds (max age, max messages, max bytes).
  • Available for Java, Python, C, JavaScript, and .NET.

Key Rotation and Envelope Encryption

  • When a KMS key is rotated, only new data keys are encrypted with the new key material.
  • Previously encrypted data keys remain decryptable because AWS KMS retains all previous versions of the key material.
  • This means you do not need to re-encrypt all your data when rotating the KMS key — only the key wrapping changes for new operations.
  • AWS KMS Key Rotation Updates (April 2024):
    • Flexible automatic rotation periods — customizable between 90 days and 2,560 days (previously fixed at 365 days).
    • On-demand rotation — rotate key material immediately using RotateKeyOnDemand API, independent of the automatic rotation schedule.
    • Rotation visibility improvements — track rotation history and key material versions.
    • Cost capped at 2 rotations — $1/month is added for the first and second rotation; all subsequent rotations are free.
    • Imported key rotation (June 2025) — On-demand rotation is now supported for symmetric-encryption KMS keys with imported key material (EXTERNAL origin).

Post-Quantum Cryptography and Envelope Encryption

  • As quantum computing advances, organizations must prepare for potential threats to current cryptographic algorithms (store-now-harvest-later attacks).
  • AWS KMS Post-Quantum Support (2025):
    • ML-KEM (Module-Lattice Key Encapsulation Mechanism) — Post-quantum key exchange now supported in TLS connections to AWS KMS, ACM, and Secrets Manager (April 2025). Protects data in transit against future quantum threats.
    • ML-DSA (Module-Lattice Digital Signature Algorithm) — Post-quantum digital signatures supported in AWS KMS (June 2025). Enables quantum-resistant signing operations within FIPS 140-3 Level 3 certified HSMs.
  • Google Cloud KMS Post-Quantum Support (2025):
    • Announced support for quantum-safe Key Encapsulation Mechanisms (KEMs) in preview (June 2025).
    • Quantum-safe digital signatures available in Cloud KMS (February 2025).
  • While envelope encryption itself (symmetric AES-256-GCM for data) remains quantum-resistant, the key exchange and wrapping mechanisms need post-quantum upgrades.

KMS Key Storage Options

  • Standard KMS Key Store — Default option. Keys are stored and protected in multi-tenant FIPS-validated HSMs managed by AWS.
  • Custom Key Store (CloudHSM-backed) — Keys are stored in a dedicated AWS CloudHSM cluster you own and control. Provides single-tenant HSM with direct key control.
  • External Key Store (XKS) — Introduced November 2022. Keys are stored in an external key management system outside of AWS. Designed for regulated workloads requiring keys to remain outside AWS at all times. Key operations may have higher latency due to external dependencies.
  • Google Cloud EKM (External Key Manager) — Similar to AWS XKS, allows using keys managed by a supported external key manager with Google Cloud services.

Envelope Encryption in AWS Services

  • Amazon S3 — Uses envelope encryption for Server-Side Encryption with KMS (SSE-KMS). Each object is encrypted with a unique data key, which is wrapped by the KMS key.
  • Amazon EBS — Encrypts volumes using data keys wrapped by a KMS key. Supports default encryption for all new volumes.
  • Amazon RDS/Aurora — Uses envelope encryption for encryption at rest of databases, automated backups, snapshots, and read replicas.
  • Amazon DynamoDB — Encryption at rest uses envelope encryption with AWS managed or customer managed KMS keys.
  • AWS Secrets Manager — Encrypts secret values using envelope encryption with KMS keys.
  • Amazon EKS — Supports default envelope encryption for all Kubernetes API data (secrets). Uses KMS keys for encrypting data encryption keys at the Kubernetes layer.
  • Amazon MSK (Managed Streaming for Apache Kafka) — Supports envelope encryption with KMS for data at rest.

Google Cloud KMS Envelope Encryption

  • Google Cloud KMS uses a similar key hierarchy with DEKs and KEKs.
  • The Encrypt and Decrypt operations in Cloud KMS are limited to 64 KiB input size (vs 4 KB in AWS KMS).
  • For larger data, use envelope encryption with a local DEK wrapped by a Cloud KMS KEK.
  • Best practices for DEKs in Google Cloud:
    • Generate DEKs locally.
    • Always store DEKs encrypted at rest.
    • Store the DEK near the data it encrypts.
    • Generate a new DEK every time you write data.
    • Use AES-256-GCM cipher for data encryption.
  • Google Cloud offers client-side encryption with Tink library, which implements envelope encryption with Cloud KMS as the KEK provider.
  • Customer-Managed Encryption Keys (CMEK) — Allows control over encryption keys used by Google Cloud services, leveraging Cloud KMS for key management.
  • Customer-Supplied Encryption Keys (CSEK) — Available for Cloud Storage and Compute Engine; you supply your own AES-256 key as the KEK.

AWS Certification Exam Tips

  • Envelope encryption is a key topic for AWS Solutions Architect Associate (SAA-C03), AWS Security Specialty (SCS-C02), and AWS Developer Associate (DVA-C02) exams.
  • Understand the difference between direct KMS encryption (up to 4 KB) and envelope encryption (unlimited data size).
  • Know when to use GenerateDataKey vs Encrypt API — if data exceeds 4 KB, envelope encryption with GenerateDataKey is required.
  • Understand that the plaintext data key should be discarded from memory immediately after use.
  • Key rotation does not require re-encrypting existing data — old key material is retained for decryption.
  • Know the role of Encryption Context as additional authenticated data (AAD) that provides integrity and authenticity.

Practice Questions

  1. A company needs to encrypt files larger than 100 MB using AWS KMS. Which approach should they use?
    1. Use the KMS Encrypt API directly
    2. Split the file into 4 KB chunks and encrypt each with KMS
    3. Use envelope encryption with GenerateDataKey to create a data key, then encrypt the file locally
    4. Use AWS CloudHSM directly without KMS
    Show Answer

    Answer: c – KMS Encrypt can only handle up to 4 KB. Envelope encryption uses a locally generated data key for encrypting large files.

  2. In envelope encryption, what happens when the KMS key is rotated?
    1. All previously encrypted data must be re-encrypted
    2. All previously encrypted data keys must be re-wrapped
    3. Only new data keys are wrapped with the new key material; old data keys remain decryptable
    4. The rotation fails if there are existing encrypted data keys
    Show Answer

    Answer: c – AWS KMS retains all previous key material versions, so old data keys encrypted under older material can still be decrypted.

  3. Which AWS KMS API should be used to obtain a data key for envelope encryption when you need to encrypt data immediately?
    1. Encrypt
    2. GenerateDataKeyWithoutPlaintext
    3. GenerateDataKey
    4. CreateKey
    Show Answer

    Answer: c – GenerateDataKey returns both the plaintext and encrypted data key for immediate use. GenerateDataKeyWithoutPlaintext only returns the encrypted copy.

  4. What is the maximum data size that can be encrypted directly using the AWS KMS Encrypt API?
    1. 256 bytes
    2. 4 KB
    3. 64 KB
    4. 1 MB
    Show Answer

    Answer: b – The KMS Encrypt API can encrypt up to 4,096 bytes (4 KB) of plaintext directly.

  5. A developer wants to reduce AWS KMS API costs for an application that performs thousands of encryption operations per second. Which approach is recommended? (Select TWO)
    1. Use the AWS Encryption SDK with data key caching
    2. Call KMS Encrypt for each operation
    3. Implement envelope encryption to minimize KMS API calls
    4. Increase the KMS API request quota
    5. Use SSE-S3 instead of SSE-KMS
    Show Answer

    Answers: a, c – Data key caching reuses data keys to reduce KMS calls, and envelope encryption itself minimizes KMS interactions by using local encryption.

  6. Which statement about AWS KMS key rotation is correct as of 2024? (Select TWO)
    1. Automatic rotation can only occur every 365 days
    2. On-demand rotation is available via the RotateKeyOnDemand API
    3. Rotation periods can be customized between 90 and 2,560 days
    4. Key rotation requires re-encrypting all existing data
    5. Rotation is only supported for AWS managed keys
    Show Answer

    Answers: b, c – Since April 2024, AWS KMS supports flexible rotation periods (90-2,560 days) and on-demand rotation independent of automatic schedules.

References

Google Cloud KMS – Key Management & Encryption

~ Last updated on : ~ jayendrapatil

Google Cloud KMS Key Management Service

  • Google Cloud KMS – Key Management Service provides a centralized, scalable, fast cloud key management service to manage encryption keys
  • KMS helps apply hardware security modules (HSMs) effortlessly to the most sensitive data by just a toggle between software- and hardware-protected encryption keys with the press of a button.
  • KMS provides support for external keys using Cloud External Key Manager to protect the data in Google Cloud and separate the data from the key
  • Cloud KMS supports multiple protection levels:
    • SOFTWARE – keys protected by software
    • HSM – keys protected by Cloud HSM hardware security modules
    • EXTERNAL – keys managed in an external key manager via Cloud EKM over the internet
    • EXTERNAL_VPC – keys managed in an external key manager via Cloud EKM over a VPC network
  • Cloud KMS now supports post-quantum cryptography (PQC) algorithms to help protect against future quantum computing threats (see Post-Quantum Cryptography section below)

Cloud KMS Keys, Keys Versions, and Key Rings

  • A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key.
  • A key exists on exactly one key ring tied to a specific location.
  • After creation, a key cannot be moved to another location or exported.
  • As of March 2026, keys and key versions can now be deleted (previously only key versions could be destroyed, not deleted). Deleted key names cannot be reused.

Google Cloud KMS Keys, Key Rings, and Key VersionsKey

  • A named object representing a cryptographic key that is used for a specific purpose. The key material – the actual bits used for cryptographic operations – can change over time as new key versions are created
  • Key is the most important object for understanding KMS usage.
  • Key purpose and other attributes of the key are connected with and managed using the key.
  • IAM permissions and roles can be used to allow and deny access to keys
  • Cloud KMS supports both asymmetric keys and symmetric keys.
    • Symmetric key
      • is used for symmetric encryption to protect some corpus of data for e.g., using AES-256 to encrypt a block of plaintext.
    • Asymmetric key
      • consists of a public and private key.
      • can be used for asymmetric encryption, or for creating digital signatures.
      • supports ECDSA on Curve25519 in PureEdDSA mode (added April 2024)
  • Cloud KMS also supports:
    • MAC signing keys – for creating and validating MAC digital signatures
    • Key Encapsulation Mechanism (KEM) keys – for post-quantum safe key encapsulation (Preview, Sept 2025)
  • Key’s type (symmetric or asymmetric) can’t be changed after key creation
  • Cloud KMS supports algorithms including AES-256, RSA 2048/3072/4096, EC P256, EC P384, Ed25519, and post-quantum algorithms (ML-DSA-65, SLH-DSA-SHA2-128S, ML-KEM-768, ML-KEM-1024, KEM-XWING)

Key Ring

  • A grouping of keys for organizational purposes.
  • Key ring belongs to Google Cloud project and resides in a specific location
  • Keys inherit IAM policies from the Key Ring that contains them.
  • Grouping keys with related permissions in a key ring allows you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
  • Key rings provide convenience and categorization
  • To prevent resource name collisions, a key ring cannot be deleted.
  • Key rings and keys do not have billable costs or quota limitations, so their continued existence does not affect costs or production limits.

Key Metadata

  • Includes resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any other derived data
  • Key metadata can be managed differently than the key material.

Key Version

  • Represents the key material associated with a key at some point in time.
  • Key version is the resource that contains the actual key material.
  • Granting access to a key also grants access to all of its enabled versions. Access to a key version cannot be managed.
  • A key version can be disabled or destroyed without affecting other versions
  • Disabling or destroying a key also disables or destroys each key version.
  • Versions are numbered sequentially, beginning with version 1.
  • When a key is rotated, a new key version is created with new key material.
  • The same logical key can have multiple versions over time, thus limiting the use of any single version.
  • Symmetric keys will always have a primary version. This version is used for encrypting by default, if no version is specified
  • Asymmetric keys do not have primary versions, and a version must be specified when using the key.
  • When Cloud KMS performs decryption using symmetric keys, it identifies automatically which key version is needed to perform the decryption.
  • Key versions can now be deleted (GA March 2026) in addition to being destroyed. Deleted key versions must meet specific deletion criteria.

Key States

  • A key version’s state is always one of the following:
    • Pending generation (PENDING_GENERATION)
      • Applies to asymmetric keys only
      • is still being generated and can’t be used, enabled, disabled, or destroyed yet.
      • KMS will automatically change the state to enabled as soon as the version is ready.
    • Pending import (PENDING_IMPORT)
      • Applies to imported keys
      • Key material is being imported and can’t be used yet.
      • KMS will automatically change the state to enabled once import completes.
    • Enabled (ENABLED)
      • is ready for use.
    • Disabled (DISABLED)
      • may not be used, but the key material is still available, and the version can be placed back into the enabled state.
    • Scheduled for destruction (DESTROY_SCHEDULED):
      • is scheduled for destruction, and will be destroyed soon.
      • can be placed back into the disabled state.
      • Default scheduled destruction duration is 30 days (changed from 24 hours as of June 2024). Custom durations can be configured between 24 hours and 120 days.
    • Destroyed (DESTROYED)
      • is destroyed, and the key material is no longer stored in Cloud KMS.
      • If the key version was used
        • for asymmetric or symmetric encryption, any ciphertext encrypted with this version is not recoverable.
        • for digital signing, new signatures cannot be created.
      • may not leave the destroyed state once entered, except when re-imported (supported since Sept 2021).
      • It takes 45 days from destruction time for key material to be deleted from all Google active and backup systems.
    • Import failed (IMPORT_FAILED)
      • Key import was attempted but failed.
      • The import can be retried.
  • A key version can only be used when it is enabled.
  • Organization policy constraints can require a key version to be disabled before it can be scheduled for destruction (constraints/cloudkms.disableBeforeDestroy)

Google Cloud KMS Key States

Key Rotation

  • For symmetric encryption, periodically and automatically rotating keys is a recommended security practice
  • Cloud KMS does not support automatic rotation of asymmetric keys and has to be done manually
  • With key rotation, data encrypted with previous key versions is not automatically re-encrypted with the new key version.
  • Rotating keys provides several benefits:
    • Limiting the number of messages encrypted with the same key version helps prevent brute-force attacks enabled by cryptanalysis.
    • In the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to compromise.
    • If you suspect that a key version is compromised, disable it and revoke access to it as soon as possible.
    • Regular key rotation helps validate the key rotation procedures before a real-life security incident occurs.
    • Regular key rotation ensures that the system is resilient to manual rotation, whether due to a security breach or the need to migrate your application to a stronger cryptographic algorithm.

Key Hierarchy

Google Cloud KMS Key Hierarchy

  • Data Encryption Key (DEK)
    • A key used to encrypt data.
  • Key Encryption Key (KEK)
    • A key used to encrypt, or wrap, a DEK.
    • All Cloud KMS platform options (software, hardware, and external backends) allow you to control KEK.
  • KMS Master Key
    • The key used to encrypt the KEK.
    • This key is distributed in memory.
    • KMS Master Key is backed up on hardware devices.
  • Root KMS
    • Google’s internal key management service.

Cloud KMS Autokey

  • Cloud KMS Autokey (GA September 2024) simplifies creating and using customer-managed encryption keys (CMEKs) by automating provisioning and assignment.
  • With Autokey, key rings, keys, and service accounts don’t need to be planned and provisioned before they’re needed. Instead, Autokey generates keys on demand as resources are created.
  • Keys created by Autokey use HSM protection level by default and follow recommended practices for:
    • Separation of duties
    • Key rotation
    • Location matching
    • Key specificity
  • Supported services include Cloud Storage, Compute Engine, BigQuery, Secret Manager, Cloud SQL, and Spanner.
  • Autokey supports two key management models:
    • Centralized key management – keys are created in a dedicated key project for all resources in a folder
    • Delegated key management (Autokey for Projects) – keys are created in the same project as the resources they protect (Public Preview, Feb 2026)
  • Autokey has a free tier (since April 2025):
    • 100 free active key versions monthly
    • 10,000 free cryptographic operations monthly
  • Uses a KeyHandle resource model: creating a KeyHandle triggers Autokey to provision a CryptoKey automatically.

Post-Quantum Cryptography (PQC)

  • Cloud KMS supports post-quantum cryptography algorithms to protect against threats from future quantum computers (“harvest now, decrypt later” attacks).
  • PQC Digital Signatures (Public Preview, February 2025):
    • ML-DSA-65 (FIPS 204) – Module-lattice-based digital signature algorithm
    • SLH-DSA-SHA2-128S (FIPS 205) – Stateless hash-based digital signature algorithm
    • These are NIST-approved post-quantum safe algorithms
  • Key Encapsulation Mechanisms (KEMs) (Preview, September 2025):
    • ML-KEM-768 – NIST-standardized lattice-based KEM
    • ML-KEM-1024 – Higher-security variant of ML-KEM
    • KEM-XWING – Hybrid KEM combining classical and post-quantum algorithms
    • KEMs enable sharing secrets resistant to quantum attacks
    • Uses a new key purpose: KEY_ENCAPSULATION
  • Google Cloud network encryption already uses ML-KEM for cryptographic key exchange by default, protecting all customer workloads.

Single-tenant Cloud HSM

  • Single-tenant Cloud HSM (GA December 2025) provides dedicated single-tenant HSM instances for customers requiring the highest level of isolation.
  • Each instance is a cluster of partitions on HSMs in a single Cloud KMS region.
  • Google manages the physical HSMs, but customers have administrative control over their instance.
  • Available in: us-central1, us-east4, europe-west1, europe-west4
  • Creating and managing an instance requires quorum approval with two-factor authentication using keys created and secured outside of Google Cloud.
  • Single-tenant Cloud HSM incurs additional costs beyond standard Cloud HSM pricing.
  • This differs from standard (multi-tenant) Cloud HSM where Google manages shared HSM infrastructure.

Cloud KMS Locations

  • Within a project, Cloud KMS resources can be created in one of many locations.
  • A key’s location impacts the performance of applications using the key
  • Regional
    • data centers exist in a specific geographical place
  • Dual-regional
    • data centers exist in two specific geographical places.
  • Multi-regional
    • data centers are spread across a general geographical area
  • Global
    • special multi-region with its data centers spread throughout the world
  • Reading and writing resources or associated metadata in dual-regional or multi-regional locations, including the global location may be slower than reading or writing from a single region.
  • Cloud KMS is available in 35+ regions worldwide, including recent additions: asia-southeast3 (Jan 2026), europe-north2 (Mar 2025), northamerica-south1 (Nov 2024), and africa-south1 (Jan 2024)

Cloud External Key Manager (Cloud EKM)

  • Cloud EKM lets you use encryption keys managed within a supported external key management system to protect data within Google Cloud.
  • Supports two connectivity options:
    • Cloud EKM over the internet – communicates with external key manager over the internet
    • Cloud EKM over a VPC – communicates via a Virtual Private Cloud network (private endpoint)
  • Coordinated external keys (since March 2023) – allows creating and managing keys in a compatible external key management system directly from Cloud KMS over a VPC network
  • Partner-managed EKM – arrangement where your EKM is managed by a trusted partner
  • Supported EKM partners include Thales CipherTrust, Fortanix, and others
  • Integrates with Key Access Justifications – provides visibility into reasons for each key access request, enabling fine-grained access control based on justification codes

Encryption Metrics and Key Tracking

  • Encryption Metrics Dashboard (GA May 2026) provides visibility into key usage across CMEK integrations.
  • Shows summaries and details of keys used in CMEK integrations and the resources they protect.
  • Supports both centralized and delegated key management models.
  • Project-level key tracking allows viewing which resources are protected by which keys.
  • Available via Google Cloud Console under Security > Key Management.

Organization Policy Constraints

  • Cloud KMS supports several organization policy constraints for governance:
    • constraints/gcp.restrictNonCmekServices – requires CMEK protection for specified services
    • constraints/gcp.restrictCmekCryptoKeyProjects – limits which KMS keys can be used for CMEK
    • constraints/cloudkms.disableBeforeDestroy – requires key version to be disabled before destruction
    • constraints/cloudkms.allowedProtectionLevels – controls which protection levels can be used (e.g., only EXTERNAL or EXTERNAL_VPC)
  • Custom organization policy constraints (Oct 2024) provide more granular control over specific fields for Cloud KMS resources.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Question 1: Your organization requires that all encryption keys used to protect Cloud Storage data are automatically provisioned with HSM protection and follow best practices for key management. Which Cloud KMS feature should you use?

  1. Cloud EKM with VPC
  2. Cloud KMS Autokey
  3. Manual CMEK creation with HSM protection level
  4. Google-managed encryption keys (GMEK)
Show Answer

Answer: 2 – Cloud KMS Autokey automatically provisions CMEK keys with HSM protection level, following best practices for separation of duties, rotation, and key specificity.

Question 2: Your security team is concerned about “harvest now, decrypt later” attacks where encrypted data is captured today and decrypted by future quantum computers. Which Cloud KMS capability helps mitigate this threat?

  1. Symmetric AES-256 encryption
  2. Cloud HSM with FIPS 140-2 Level 3
  3. Post-quantum cryptography (PQC) digital signatures and KEMs
  4. Key rotation every 90 days
Show Answer

Answer: 3 – Cloud KMS supports post-quantum safe algorithms including ML-DSA-65, SLH-DSA-SHA2-128S for digital signatures, and ML-KEM-768/1024 and KEM-XWING for key encapsulation, designed to resist quantum computer attacks.

Question 3: What is the default scheduled destruction duration for Cloud KMS key versions?

  1. 24 hours
  2. 7 days
  3. 30 days
  4. 90 days
Show Answer

Answer: 3 – As of June 2024, the default scheduled destruction duration is 30 days (changed from the previous 24-hour default). Custom durations between 24 hours and 120 days can be configured.

Question 4: Your company needs dedicated HSM hardware with administrative control, where creating instances requires quorum approval with two-factor authentication. Which Cloud KMS offering meets this requirement?

  1. Multi-tenant Cloud HSM
  2. Single-tenant Cloud HSM
  3. Cloud EKM with VPC
  4. Bare Metal HSM
Show Answer

Answer: 2 – Single-tenant Cloud HSM (GA Dec 2025) provides dedicated single-tenant instances with customer administrative control, requiring quorum approval with 2FA for management operations.

Question 5: Which statements about Cloud KMS key deletion are correct? (Choose 2)

  1. Key rings can be deleted
  2. Keys and key versions can be deleted if they meet deletion criteria
  3. Names of deleted keys can be reused
  4. Keys must meet deletion criteria before they can be deleted
  5. Deleted keys are immediately removed from all systems
Show Answer

Answer: 2, 4 – As of March 2026, keys and key versions can be deleted (GA), but they must meet specific deletion criteria. Key rings cannot be deleted, and names of deleted keys cannot be reused.

See also: Google Cloud Security Services Cheat Sheet

References