Unlock the power of your data in the cloud! Get hands-on with Google Cloud's core data services like BigQuery and Looker to validate your practical skills in data ingestion, analysis, and management, and earn your Associate Data Practitioner certification!
Managing an encryption key from birth to destruction is called its lifecycle, and Cloud KMS gives you control over every step. The lifecycle has four main stages: creating, using, rotating, and destroying keys. Each stage has a specific purpose and security impact.
When you create a key in Cloud KMS, you first choose a key ring and a location (a Google Cloud region) so the key lives close to the data it protects. Cloud KMS supports different key types such as Cloud KMS software keys (software-based encryption), Cloud HSM keys (hardware-backed), and Cloud EKM keys (keys you manage outside Google Cloud). Once a key exists, you can use it for cryptographic operations like signing, encryption, and verification. These operations happen entirely inside Cloud KMS – your raw key material never leaves the service, which keeps it secure.
Key rotation is the practice of replacing a key with a new version on a schedule. Cloud KMS lets you configure automatic rotation, so a new key version is created at regular intervals without manual work. Rotating limits the amount of data encrypted with any single key, reducing the damage if a key is ever compromised. You can also adjust or remove rotation schedules, giving you flexibility to match your organization’s security policies.
Destroying a key or a specific key version is a permanent action. After destruction, any data encrypted with that key becomes unreadable – there is no way to recover it. To schedule destruction, you confirm the action in the Google Cloud console or use command-line tools, specifying the key version number and the key ring location. Because this step is irreversible, you must carefully verify which key or version you are destroying.
Keeping track of key operations helps you meet compliance requirements. Cloud Audit Logs record every administrative activity, such as key creation, rotation, and destruction. You can set up alerts to notify your team when a key version is destroyed or when someone uses a sensitive key. This logging gives you a clear chain of custody for your encryption keys and helps you prove to auditors that your data is properly protected.
Cloud KMS is built from three main components: key rings, keys, and key versions. Together they form a hierarchy that organizes and controls your encryption strategy.
A hierarchy diagram showing the Cloud KMS resource structure, where a Google Cloud Location contains a Key Ring, which holds Keys, which in turn contain multiple Key Versions.
A key ring is a logical container – think of it as a folder for your keys. It is the root resource in the Cloud KMS hierarchy, meaning a key ring holds one or more keys and their versions. Each key ring must be created inside a specific Google Cloud location (a region like us-central1). You should choose the location to be near the data the keys protect; this improves performance and helps you meet data residency rules, which require data to stay in a specific geographic area.
Inside a key ring you create keys, the actual cryptographic tools that encrypt and decrypt your data. Cloud KMS offers different key types to match different security needs. Cloud KMS software keys are fully managed by Google. Cloud HSM keys are backed by a hardware security module for stronger physical protection. Cloud EKM keys let you use a key that is stored and managed outside Google Cloud. Each key can be used for encryption, decryption, signing, or verification depending on its purpose.
A single key can have multiple key versions. Each version is a separate instance of the key material. Versioning makes key rotation possible: when you rotate a key, Cloud KMS creates a new version while keeping the old ones available so you can still decrypt data that was encrypted with an earlier version. You can enable or disable any version, which gives you fine-grained control over which keys are active. This layered structure – key ring, key, version – allows you to enforce strong security and meet compliance regulations. For example, Key Access Justifications gives you a reason every time someone requests access to a customer-managed key, so you can audit and approve each use.
Google Cloud encrypts all data at rest by default using Google-managed encryption keys. This automatic encryption works without any setup and gives you a baseline level of security. But some organizations need more control – for example, to satisfy compliance rules or to be able to revoke access to data immediately. For those cases, Google Cloud offers Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS.
With Google-managed keys, Google creates, rotates, and destroys the encryption keys on your behalf. You never see the key material, and you cannot control the key lifecycle. This is simple and works for most applications. With CMEK, you create and own the keys inside Cloud KMS. You decide when to rotate them, who can use them, and when to destroy them. The tradeoff is that you take on more management responsibility, but you gain full authority over the encryption of your data.
When you enable CMEK for a Google Cloud service – such as Google Security Operations, Google Kubernetes Engine (GKE), or a Data Lake – that service uses your key (stored in Cloud KMS) to encrypt and decrypt data at rest. For instance, a persistent disk attached to a VM can be encrypted with a CMEK key. The service always calls Cloud KMS to perform the encryption or decryption; it does not have access to the key material itself. This integration creates a direct dependency: if you disable or destroy the CMEK key in Cloud KMS, the service immediately loses the ability to decrypt the data. That gives you a powerful kill switch – you can revoke access to your data by disabling a single key. You also define access control through Cloud KMS permissions, specifying exactly which users or services can manage the key and which can use it for cryptographic operations. This granular control helps you enforce compliance policies and keep your organization as the ultimate custodian of its information.
Gauge your current knowledge

Gauge your current knowledge
