An organization is designing an encryption management architecture in Google Cloud to protect sensitive analytics datasets in accordance with compliance standards. The security team has defined the following operational requirements: Keys must be logically organized and bound to a specific Google Cloud region. Access permissions must be managed efficiently across a collection of related keys using Identity and Access Management (IAM). Keys must undergo periodic rotation without compromising the ability to decrypt historical records that were encrypted with earlier key material. Which architectural configuration in Cloud Key Management Service (Cloud KMS) correctly fulfills these requirements?

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.: What the Cloud KMS Resource Hierarchy Is Google Cloud Key Management Service (Cloud KMS) organizes cryptographic resources into a structured three-tier hierarchy: Key Rings, Keys (CryptoKeys), and Key Versions (CryptoKeyVersions). Key Ring: An administrative container tied to a specific geographic location (region, dual-region, or multi-region) that groups related keys together and acts as an IAM policy boundary. Key: A named object that defines cryptographic parameters such as the key's type (symmetric or asymmetric), purpose (e.g., Symmetric encrypt/decrypt), and protection level (Software, Cloud HSM, or External). Key Version: The underlying cryptographic object that holds the actual key material used to perform cryptographic operations. How It Meets the Requirements Regional Organization (✓): A key ring is defined in a specific location (such as us-central1). All keys created within that ring automatically reside in that location, satisfying regional data locality policies. Efficient IAM Governance (✓): Cloud KMS allows administrators to assign IAM permissions and roles directly at the key ring level. These permissions automatically inherit downward to all keys within the ring, eliminating the need to manage access policies individually for each key. Rotation with Historical Decryption (✓): When a key is rotated, Cloud KMS generates a new key version (e.g., version 2) and sets it as the primary key version for future encryption operations. Earlier key versions remain in the Enabled state, allowing existing data that was encrypted with older versions to be decrypted seamlessly without requiring full data re-encryption. Key Advantages and Capabilities Seamless Key Rotation: Automatic or manual rotation generates new versions while preserving previous versions for continuous decryption capability. Zero-Cost Containers: Key rings incur no ongoing storage or operational costs; charges apply only to active key versions and cryptographic API requests. Centralized Access Control: Applying IAM roles (such as roles/cloudkms.cryptoKeyEncrypterDecrypter) at the key ring simplifies compliance audits. Probabilistic Encryption: Regardless of the underlying algorithm, Cloud KMS employs probabilistic encryption so identical plaintexts encrypted multiple times yield distinct ciphertexts. Comprehensive Audit Trails: Every administrative change and cryptographic action can be tracked through Cloud Audit Logs. Why This Is Optimal This approach aligns with Google Cloud security best practices by grouping related cryptographic assets under a common regional boundary and leveraging resource inheritance for IAM permissions. It guarantees continuous access to historical analytics data while meeting regulatory rotation schedules.

Cloud KMS Regional Key Rings and Key Rotation

Regional Key Rings and Key Version Rotation

An organization is designing an encryption management architecture in Google Cloud to protect sensitive analytics datasets in accordance with compliance standards. The security team has defined the following operational requirements:

Keys must be logically organized and bound to a specific Google Cloud region.
Access permissions must be managed efficiently across a collection of related keys using Identity and Access Management (IAM).
Keys must undergo periodic rotation without compromising the ability to decrypt historical records that were encrypted with earlier key material.

Which architectural configuration in Cloud Key Management Service (Cloud KMS) correctly fulfills these requirements?

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

Explanations

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

What Key Material Protection and Key Ring Lifecycles Are

Cloud KMS is engineered to secure cryptographic keys at rest and in transit. It manages software-backed keys, hardware-backed keys in FIPS 140-validated Hardware Security Modules (Cloud HSM), and connections to external systems (Cloud EKM).

Why It Doesn't Meet the Requirements

Key material cannot be viewed or exported (✗): For security and compliance integrity, no Google Cloud principal or administrator can view or export raw cryptographic key material from Cloud KMS. Cloud KMS executes all cryptographic operations on the user's behalf within its secure boundary.
Key rings cannot be deleted (✗): In Cloud KMS, key rings are permanent administrative objects. Once created, a key ring cannot be deleted. This immutability prevents accidental or malicious destruction of the resource hierarchy.
Prevents compliance verification: Attempting to extract raw keys contradicts the core security model of cloud-native key management, which relies on hardware-enforced isolation and audit logs rather than manual file backups.

Key Characteristics and Limitations

Non-Exportability: Raw cryptographic material never leaves the Cloud KMS boundary, preventing key compromise through exfiltration or credential leaks.
Resource Permanence: Key rings and keys cannot be deleted; to retire a key ring or key, administrators disable its key versions or revoke IAM permissions.
Cost Freezing: While key rings cannot be deleted, they incur zero ongoing costs. Inactive or destroyed key versions do not incur storage charges once fully purged.

This Answer Would Be Correct If

The organization was implementing Customer-Supplied Encryption Keys (CSEK), where raw key material is generated and held on-premises and provided transiently in memory to Google Cloud during specific API calls, rather than being managed natively by Cloud KMS.

Additional Context

The inability to delete key rings is an intentional design choice by Google Cloud to ensure that resource IDs remain immutable and audit histories remain tamper-resistant across the lifetime of the project.

View source documentation

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

What Key Versions and Their Access Models Are

In Cloud KMS, a key version represents a specific iteration of cryptographic key material containing the actual bytes used for encryption, decryption, or signing. Each version has a version number (starting at 1) and a lifecycle state (Enabled, Disabled, Scheduled for destruction, or Destroyed).

Why It Doesn't Meet the Requirements

Cannot manage IAM at the key version level (✗): Cloud KMS does not support Identity and Access Management (IAM) role bindings at the key version level. Permissions can only be applied at the organization, folder, project, key ring, or key level. Granting access to a key automatically grants access to all enabled versions of that key.
Destroys historical decryption capability (✗): To decrypt data, Cloud KMS must use the exact key version that was originally used to encrypt it. Destroying previous key versions permanently deletes the underlying key material, making all historical data encrypted by those versions irrecoverable.

Key Characteristics and Limitations

Inherited Access: Permissions cannot be filtered or restricted to individual versions; any principal authorized to use the key can use any of its enabled versions.
Key Version States: Versions can be transitioned through states such as Enabled, Disabled, Scheduled for destruction, and Destroyed.
Cryptographic Shredding: Destroying a key version permanently removes the key material after a configurable destruction window (default 24 hours), rendering corresponding ciphertexts permanently unreadable.

This Answer Would Be Correct If

The objective was to perform crypto-shredding (selective data deletion) to meet compliance mandates requiring that retired datasets or offboarded client records be permanently rendered inaccessible by destroying the associated key material.

Additional Context

Attempting to enforce granular access policies by version is a common misconception. In Cloud KMS, separation of duties and least privilege must be architected at the key or key ring tier, while key versions serve strictly as rotational iterations of the key material.

View source documentation

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

What the Cloud KMS Resource Hierarchy Is

Google Cloud Key Management Service (Cloud KMS) organizes cryptographic resources into a structured three-tier hierarchy: Key Rings, Keys (CryptoKeys), and Key Versions (CryptoKeyVersions).

Key Ring: An administrative container tied to a specific geographic location (region, dual-region, or multi-region) that groups related keys together and acts as an IAM policy boundary.
Key: A named object that defines cryptographic parameters such as the key's type (symmetric or asymmetric), purpose (e.g., Symmetric encrypt/decrypt), and protection level (Software, Cloud HSM, or External).
Key Version: The underlying cryptographic object that holds the actual key material used to perform cryptographic operations.

How It Meets the Requirements

Regional Organization (✓): A key ring is defined in a specific location (such as us-central1). All keys created within that ring automatically reside in that location, satisfying regional data locality policies.
Efficient IAM Governance (✓): Cloud KMS allows administrators to assign IAM permissions and roles directly at the key ring level. These permissions automatically inherit downward to all keys within the ring, eliminating the need to manage access policies individually for each key.
Rotation with Historical Decryption (✓): When a key is rotated, Cloud KMS generates a new key version (e.g., version 2) and sets it as the primary key version for future encryption operations. Earlier key versions remain in the Enabled state, allowing existing data that was encrypted with older versions to be decrypted seamlessly without requiring full data re-encryption.

Key Advantages and Capabilities

Seamless Key Rotation: Automatic or manual rotation generates new versions while preserving previous versions for continuous decryption capability.
Zero-Cost Containers: Key rings incur no ongoing storage or operational costs; charges apply only to active key versions and cryptographic API requests.
Centralized Access Control: Applying IAM roles (such as roles/cloudkms.cryptoKeyEncrypterDecrypter) at the key ring simplifies compliance audits.
Probabilistic Encryption: Regardless of the underlying algorithm, Cloud KMS employs probabilistic encryption so identical plaintexts encrypted multiple times yield distinct ciphertexts.
Comprehensive Audit Trails: Every administrative change and cryptographic action can be tracked through Cloud Audit Logs.

Why This Is Optimal

This approach aligns with Google Cloud security best practices by grouping related cryptographic assets under a common regional boundary and leveraging resource inheritance for IAM permissions. It guarantees continuous access to historical analytics data while meeting regulatory rotation schedules.

View source documentation

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

What Key Rings and Key Purposes Are

A key ring is a regional or multi-regional resource container in Cloud KMS that binds all contained keys to a designated Google Cloud location. A key's purpose defines the cryptographic operations the key is capable of performing, such as Symmetric encrypt/decrypt, Asymmetric sign, or Asymmetric decrypt.

Why It Doesn't Meet the Requirements

Key rings cannot span arbitrary regions (✗): A key ring must be created in a specific, predefined Google Cloud location (such as a single region like us-east1, a dual-region, or a predefined multi-region like us). You cannot create custom key rings that dynamically span selected disparate regions, nor can a key ring be relocated after creation.
Key purpose is strictly immutable (✗): When a key is created, its purpose is locked permanently. You cannot change a key's purpose from symmetric encryption to asymmetric signing or modify its cryptographic purpose when generating new versions.
All versions share the same purpose (✗): Every key version generated under a key inherits the identical purpose and algorithm family defined by the parent key.

Key Characteristics and Limitations

Immutable Attributes: A key's purpose, protection level, and geographic location cannot be modified after initial creation.
Location Confinement: Cloud KMS resources are immutably tied to their deployment location, ensuring strict adherence to geographic data sovereignty requirements.
Primary Version Behavior: Symmetric encryption keys designate a single primary version used for new write operations, while asymmetric keys require the caller to reference the explicit version.

This Answer Would Be Correct If

The organization needed to deploy keys across a predefined multi-region (such as europe or us) for high availability across regional failures, and required separate individual keys to be provisioned whenever a different cryptographic purpose was needed.

Additional Context

If a data pipeline requires different cryptographic algorithms (e.g., migrating from AES-GCM to HMAC or asymmetric RSA), engineers must create an entirely new key with the desired purpose rather than updating the existing key.

View source documentation

Last updated October 23, 2026

Regional Key Rings and Key Version Rotation

Keys must be logically organized and bound to a specific Google Cloud region.
Access permissions must be managed efficiently across a collection of related keys using Identity and Access Management (IAM).
Keys must undergo periodic rotation without compromising the ability to decrypt historical records that were encrypted with earlier key material.

Which architectural configuration in Cloud Key Management Service (Cloud KMS) correctly fulfills these requirements?

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

Explanations

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

What Key Material Protection and Key Ring Lifecycles Are

Why It Doesn't Meet the Requirements

Key material cannot be viewed or exported (✗): For security and compliance integrity, no Google Cloud principal or administrator can view or export raw cryptographic key material from Cloud KMS. Cloud KMS executes all cryptographic operations on the user's behalf within its secure boundary.
Key rings cannot be deleted (✗): In Cloud KMS, key rings are permanent administrative objects. Once created, a key ring cannot be deleted. This immutability prevents accidental or malicious destruction of the resource hierarchy.
Prevents compliance verification: Attempting to extract raw keys contradicts the core security model of cloud-native key management, which relies on hardware-enforced isolation and audit logs rather than manual file backups.

Key Characteristics and Limitations

Non-Exportability: Raw cryptographic material never leaves the Cloud KMS boundary, preventing key compromise through exfiltration or credential leaks.
Resource Permanence: Key rings and keys cannot be deleted; to retire a key ring or key, administrators disable its key versions or revoke IAM permissions.
Cost Freezing: While key rings cannot be deleted, they incur zero ongoing costs. Inactive or destroyed key versions do not incur storage charges once fully purged.

This Answer Would Be Correct If

Additional Context

View source documentation

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

What Key Versions and Their Access Models Are

Why It Doesn't Meet the Requirements

Cannot manage IAM at the key version level (✗): Cloud KMS does not support Identity and Access Management (IAM) role bindings at the key version level. Permissions can only be applied at the organization, folder, project, key ring, or key level. Granting access to a key automatically grants access to all enabled versions of that key.
Destroys historical decryption capability (✗): To decrypt data, Cloud KMS must use the exact key version that was originally used to encrypt it. Destroying previous key versions permanently deletes the underlying key material, making all historical data encrypted by those versions irrecoverable.

Key Characteristics and Limitations

Inherited Access: Permissions cannot be filtered or restricted to individual versions; any principal authorized to use the key can use any of its enabled versions.
Key Version States: Versions can be transitioned through states such as Enabled, Disabled, Scheduled for destruction, and Destroyed.
Cryptographic Shredding: Destroying a key version permanently removes the key material after a configurable destruction window (default 24 hours), rendering corresponding ciphertexts permanently unreadable.

This Answer Would Be Correct If

Additional Context

View source documentation

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

What the Cloud KMS Resource Hierarchy Is

Key Ring: An administrative container tied to a specific geographic location (region, dual-region, or multi-region) that groups related keys together and acts as an IAM policy boundary.
Key: A named object that defines cryptographic parameters such as the key's type (symmetric or asymmetric), purpose (e.g., Symmetric encrypt/decrypt), and protection level (Software, Cloud HSM, or External).
Key Version: The underlying cryptographic object that holds the actual key material used to perform cryptographic operations.

How It Meets the Requirements

Regional Organization (✓): A key ring is defined in a specific location (such as us-central1). All keys created within that ring automatically reside in that location, satisfying regional data locality policies.
Efficient IAM Governance (✓): Cloud KMS allows administrators to assign IAM permissions and roles directly at the key ring level. These permissions automatically inherit downward to all keys within the ring, eliminating the need to manage access policies individually for each key.
Rotation with Historical Decryption (✓): When a key is rotated, Cloud KMS generates a new key version (e.g., version 2) and sets it as the primary key version for future encryption operations. Earlier key versions remain in the Enabled state, allowing existing data that was encrypted with older versions to be decrypted seamlessly without requiring full data re-encryption.

Key Advantages and Capabilities

Seamless Key Rotation: Automatic or manual rotation generates new versions while preserving previous versions for continuous decryption capability.
Zero-Cost Containers: Key rings incur no ongoing storage or operational costs; charges apply only to active key versions and cryptographic API requests.
Centralized Access Control: Applying IAM roles (such as roles/cloudkms.cryptoKeyEncrypterDecrypter) at the key ring simplifies compliance audits.
Probabilistic Encryption: Regardless of the underlying algorithm, Cloud KMS employs probabilistic encryption so identical plaintexts encrypted multiple times yield distinct ciphertexts.
Comprehensive Audit Trails: Every administrative change and cryptographic action can be tracked through Cloud Audit Logs.

Why This Is Optimal

View source documentation

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

What Key Rings and Key Purposes Are

Why It Doesn't Meet the Requirements

Key rings cannot span arbitrary regions (✗): A key ring must be created in a specific, predefined Google Cloud location (such as a single region like us-east1, a dual-region, or a predefined multi-region like us). You cannot create custom key rings that dynamically span selected disparate regions, nor can a key ring be relocated after creation.
Key purpose is strictly immutable (✗): When a key is created, its purpose is locked permanently. You cannot change a key's purpose from symmetric encryption to asymmetric signing or modify its cryptographic purpose when generating new versions.
All versions share the same purpose (✗): Every key version generated under a key inherits the identical purpose and algorithm family defined by the parent key.

Key Characteristics and Limitations

Immutable Attributes: A key's purpose, protection level, and geographic location cannot be modified after initial creation.
Location Confinement: Cloud KMS resources are immutably tied to their deployment location, ensuring strict adherence to geographic data sovereignty requirements.
Primary Version Behavior: Symmetric encryption keys designate a single primary version used for new write operations, while asymmetric keys require the caller to reference the explicit version.

This Answer Would Be Correct If

Additional Context

View source documentation

Last updated October 23, 2026

Regional Key Rings and Key Version Rotation

Explanations

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

What Key Material Protection and Key Ring Lifecycles Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

What Key Versions and Their Access Models Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

What the Cloud KMS Resource Hierarchy Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

What Key Rings and Key Purposes Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Customer-Managed Encryption Keys

Cloud KMS Asymmetric Envelope Encryption

Cloud Storage Archive Storage Class

Cloud Storage Firestore BigQuery Data Structure Mapping

Cloud Composer vs Workflows vs Dataproc Workflow Templates

Cloud Service Mesh Telemetry API Root Namespace

Regional Key Rings and Key Version Rotation

Explanations

Deploy keys in a regional key ring, export the underlying key material from the key version for off-site backup, and delete the key ring when older versions expire.

What Key Material Protection and Key Ring Lifecycles Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Apply IAM permissions directly to individual key versions to restrict access, and destroy previous key versions upon generating a new version during rotation.

What Key Versions and Their Access Models Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Deploy keys inside a regional key ring to manage IAM access policies at the group level, and generate new key versions during rotation while keeping earlier versions enabled for decryption.

What the Cloud KMS Resource Hierarchy Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Create a key ring that spans multiple regions, and update the cryptographic purpose of the primary key whenever a new key version is generated.

What Key Rings and Key Purposes Are

Why It Doesn't Meet the Requirements

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Customer-Managed Encryption Keys

Cloud KMS Asymmetric Envelope Encryption

Cloud Storage Archive Storage Class

Cloud Storage Firestore BigQuery Data Structure Mapping

Cloud Composer vs Workflows vs Dataproc Workflow Templates

Cloud Service Mesh Telemetry API Root Namespace