A security engineer is designing a Customer-Managed Encryption Key (CMEK) lifecycle strategy for sensitive enterprise workloads hosted in Google Cloud. Company security compliance mandates that encryption keys must automatically rotate every 90 days. The engineer must configure the CMEK keys and dependent cloud resources so that: Key rotation occurs automatically on schedule without manual operational intervention. New data writes are automatically protected with the newest key version. Existing historical data remains decryptable and accessible without requiring immediate manual re-encryption or updating resource configurations. Which configuration strategy should the engineer implement?

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.: What Automated CMEK Key Rotation Is Customer-Managed Encryption Keys (CMEK) in Google Cloud allow organizations to manage symmetric encryption keys inside Cloud Key Management Service (Cloud KMS) to protect data at rest across managed services. When configuring a CryptoKey, administrators can define an automated rotation period (such as 90 days) alongside a next rotation time. How It Meets the Requirements Automated rotation schedule: Setting a 90-day rotation period on the CryptoKey instructs Cloud KMS to automatically generate a new primary CryptoKeyVersion every 90 days without manual API calls or script triggers. Transparent encryption for new writes: CMEK-integrated resources reference the base CryptoKey resource name (e.g., projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME) rather than a specific version ID. The resource automatically uses the current primary key version for all new write operations. Historic data accessibility: Cloud KMS key rotation does not automatically re-encrypt existing data at rest. By keeping earlier CryptoKeyVersions in an Enabled state, Google Cloud services can continue decrypting existing blocks and records that were encrypted with previous versions without service interruption. Key Advantages and Capabilities Zero configuration updates: Eliminates the operational overhead of updating key version URIs in resource definitions or redeploying workloads upon rotation. Granular lifecycle control: Allows security teams to inspect version history, audit key usage in Cloud Audit Logs, and disable specific compromised versions if necessary. Cryptographic separation: Enforces compliance limits on the amount of plaintext encrypted under a single cryptographic key version. Why This Is Optimal This architecture adheres strictly to Google Cloud security best practices by decoupling the key resource path from individual version numbers while maintaining seamless read access to older ciphertext versions.

Cloud KMS Automatic CMEK Rotation Every 90 Days

Automatic Cloud KMS Rotation for CMEK Data

A security engineer is designing a Customer-Managed Encryption Key (CMEK) lifecycle strategy for sensitive enterprise workloads hosted in Google Cloud. Company security compliance mandates that encryption keys must automatically rotate every 90 days.

The engineer must configure the CMEK keys and dependent cloud resources so that:

Key rotation occurs automatically on schedule without manual operational intervention.
New data writes are automatically protected with the newest key version.
Existing historical data remains decryptable and accessible without requiring immediate manual re-encryption or updating resource configurations.

Which configuration strategy should the engineer implement?

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.

Create a symmetric Cloud KMS key with a 90-day rotation period, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

Explanations

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

What Cloud Function KeyRing Recreation Does

This pattern uses a custom serverless script to create entirely new KeyRings and keys at scheduled intervals, invokes manual batch jobs to re-encrypt stored data, and attempts to delete old key infrastructure.

Why It Doesn't Meet the Requirement

Immutability of KeyRings: In Cloud KMS, KeyRings and CryptoKeys cannot be deleted; their resource names and metadata persist permanently in the project.
Unnecessary operational overhead: Custom Cloud Functions duplicate native Cloud KMS automated rotation capabilities, increasing architecture complexity and failure points.
Potential downtime: Migrating workloads to a new KeyRing requires updating IAM role bindings for service agents and updating CMEK configurations across all dependent cloud services.

Key Characteristics

Cloud KMS natively supports automated key version generation on individual CryptoKeys.
Service agents require permissions at the KeyRing or CryptoKey level, which would need continuous reconfiguration if new KeyRings were continuously created.

This Answer Would Be Correct If

An organization required multi-region key migration or structural reorganization of key management across distinct Google Cloud projects.

View source documentation

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

What Asymmetric Signing Keys and Admin Roles Do

This approach deploys an asymmetric key pair intended for digital signatures, assigns administrative permissions (roles/cloudkms.admin) to Google Cloud service agents, and disables older key versions.

Why It Doesn't Meet the Requirement

Incorrect key purpose: CMEK for Google Cloud services (such as Cloud Storage, BigQuery, Vertex AI, and Cloud SQL) requires Symmetric encrypt/decrypt keys, not asymmetric signing keys.
Violation of least privilege: Service agents require the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role, not administrative roles like roles/cloudkms.admin.
Data accessibility loss: Disabling older key versions prevents the service agent from performing decryption operations on historical data that has not yet been rewritten.

Key Limitations

Asymmetric keys cannot be used for standard native CMEK data-at-rest encryption.
Service agents only need cryptographic data access, not administrative permissions to manage or create keys.

This Answer Would Be Correct If

The workload specifically required digital signature generation and verification for authentication tokens or software artifact signing rather than CMEK data-at-rest encryption.

View source documentation

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.

What Automated CMEK Key Rotation Is

Customer-Managed Encryption Keys (CMEK) in Google Cloud allow organizations to manage symmetric encryption keys inside Cloud Key Management Service (Cloud KMS) to protect data at rest across managed services. When configuring a CryptoKey, administrators can define an automated rotation period (such as 90 days) alongside a next rotation time.

How It Meets the Requirements

Automated rotation schedule: Setting a 90-day rotation period on the CryptoKey instructs Cloud KMS to automatically generate a new primary CryptoKeyVersion every 90 days without manual API calls or script triggers.
Transparent encryption for new writes: CMEK-integrated resources reference the base CryptoKey resource name (e.g., projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME) rather than a specific version ID. The resource automatically uses the current primary key version for all new write operations.
Historic data accessibility: Cloud KMS key rotation does not automatically re-encrypt existing data at rest. By keeping earlier CryptoKeyVersions in an Enabled state, Google Cloud services can continue decrypting existing blocks and records that were encrypted with previous versions without service interruption.

Key Advantages and Capabilities

Zero configuration updates: Eliminates the operational overhead of updating key version URIs in resource definitions or redeploying workloads upon rotation.
Granular lifecycle control: Allows security teams to inspect version history, audit key usage in Cloud Audit Logs, and disable specific compromised versions if necessary.
Cryptographic separation: Enforces compliance limits on the amount of plaintext encrypted under a single cryptographic key version.

Why This Is Optimal

This architecture adheres strictly to Google Cloud security best practices by decoupling the key resource path from individual version numbers while maintaining seamless read access to older ciphertext versions.

View source documentation

Create a symmetric Cloud KMS key with a 90-day rotation period, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

What Explicit Version Referencing and Immediate Destruction Does

This approach specifies the explicit version path (such as /cryptoKeyVersions/1) within the resource encryption specification and schedules immediate destruction of previous CryptoKeyVersion resources as soon as a new version is generated.

Why It Doesn't Meet the Requirement

Breaks historical data access: Destroying or disabling previous key versions renders all existing data encrypted with those versions permanently unreadable and inaccessible, causing severe data loss.
Breaks automatic rotation: Pinning a resource configuration to a specific /cryptoKeyVersions/X path prevents the resource from automatically using the new primary version upon rotation, requiring manual configuration updates across all dependent resources.
Operational disruption: CMEK configurations across Google Cloud require referencing the parent CryptoKey name without the version number so Cloud KMS can automatically manage version transitions.

Key Limitations

Cloud KMS does not automatically rewrite historical ciphertext when a key rotates.
Pinned key version paths negate the benefits of automated rotation schedules.
Key destruction is irreversible after the scheduled destruction period expires.

This Answer Would Be Correct If

An organization intended to execute a complete cryptographic erasure (crypto-shredding) of all historical data associated with prior key versions upon rotation.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Automatic Cloud KMS Rotation for CMEK Data

The engineer must configure the CMEK keys and dependent cloud resources so that:

Key rotation occurs automatically on schedule without manual operational intervention.
New data writes are automatically protected with the newest key version.
Existing historical data remains decryptable and accessible without requiring immediate manual re-encryption or updating resource configurations.

Which configuration strategy should the engineer implement?

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

Explanations

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

What Cloud Function KeyRing Recreation Does

Why It Doesn't Meet the Requirement

Immutability of KeyRings: In Cloud KMS, KeyRings and CryptoKeys cannot be deleted; their resource names and metadata persist permanently in the project.
Unnecessary operational overhead: Custom Cloud Functions duplicate native Cloud KMS automated rotation capabilities, increasing architecture complexity and failure points.
Potential downtime: Migrating workloads to a new KeyRing requires updating IAM role bindings for service agents and updating CMEK configurations across all dependent cloud services.

Key Characteristics

Cloud KMS natively supports automated key version generation on individual CryptoKeys.
Service agents require permissions at the KeyRing or CryptoKey level, which would need continuous reconfiguration if new KeyRings were continuously created.

This Answer Would Be Correct If

An organization required multi-region key migration or structural reorganization of key management across distinct Google Cloud projects.

View source documentation

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

What Asymmetric Signing Keys and Admin Roles Do

Why It Doesn't Meet the Requirement

Incorrect key purpose: CMEK for Google Cloud services (such as Cloud Storage, BigQuery, Vertex AI, and Cloud SQL) requires Symmetric encrypt/decrypt keys, not asymmetric signing keys.
Violation of least privilege: Service agents require the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role, not administrative roles like roles/cloudkms.admin.
Data accessibility loss: Disabling older key versions prevents the service agent from performing decryption operations on historical data that has not yet been rewritten.

Key Limitations

Asymmetric keys cannot be used for standard native CMEK data-at-rest encryption.
Service agents only need cryptographic data access, not administrative permissions to manage or create keys.

This Answer Would Be Correct If

The workload specifically required digital signature generation and verification for authentication tokens or software artifact signing rather than CMEK data-at-rest encryption.

View source documentation

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.

What Automated CMEK Key Rotation Is

How It Meets the Requirements

Automated rotation schedule: Setting a 90-day rotation period on the CryptoKey instructs Cloud KMS to automatically generate a new primary CryptoKeyVersion every 90 days without manual API calls or script triggers.
Transparent encryption for new writes: CMEK-integrated resources reference the base CryptoKey resource name (e.g., projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME) rather than a specific version ID. The resource automatically uses the current primary key version for all new write operations.
Historic data accessibility: Cloud KMS key rotation does not automatically re-encrypt existing data at rest. By keeping earlier CryptoKeyVersions in an Enabled state, Google Cloud services can continue decrypting existing blocks and records that were encrypted with previous versions without service interruption.

Key Advantages and Capabilities

Zero configuration updates: Eliminates the operational overhead of updating key version URIs in resource definitions or redeploying workloads upon rotation.
Granular lifecycle control: Allows security teams to inspect version history, audit key usage in Cloud Audit Logs, and disable specific compromised versions if necessary.
Cryptographic separation: Enforces compliance limits on the amount of plaintext encrypted under a single cryptographic key version.

Why This Is Optimal

View source documentation

Create a symmetric Cloud KMS key with a 90-day rotation period, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

What Explicit Version Referencing and Immediate Destruction Does

Why It Doesn't Meet the Requirement

Breaks historical data access: Destroying or disabling previous key versions renders all existing data encrypted with those versions permanently unreadable and inaccessible, causing severe data loss.
Breaks automatic rotation: Pinning a resource configuration to a specific /cryptoKeyVersions/X path prevents the resource from automatically using the new primary version upon rotation, requiring manual configuration updates across all dependent resources.
Operational disruption: CMEK configurations across Google Cloud require referencing the parent CryptoKey name without the version number so Cloud KMS can automatically manage version transitions.

Key Limitations

Cloud KMS does not automatically rewrite historical ciphertext when a key rotates.
Pinned key version paths negate the benefits of automated rotation schedules.
Key destruction is irreversible after the scheduled destruction period expires.

This Answer Would Be Correct If

An organization intended to execute a complete cryptographic erasure (crypto-shredding) of all historical data associated with prior key versions upon rotation.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Automatic Cloud KMS Rotation for CMEK Data

Explanations

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

What Cloud Function KeyRing Recreation Does

Why It Doesn't Meet the Requirement

Key Characteristics

This Answer Would Be Correct If

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

What Asymmetric Signing Keys and Admin Roles Do

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.

What Automated CMEK Key Rotation Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Create a symmetric Cloud KMS key with a 90-day rotation period, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

What Explicit Version Referencing and Immediate Destruction Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Cloud KMS HSM Key Import (BYOK)

Cloud KMS CryptoKeyVersion Disable and Destroy

Organization Policy Inheritance and Overrides

On-Demand Scanning Pre-Push Gating

Cloud SQL Auth Proxy with Workload Identity

Analytics Hub Authorized Views And Row-Level Security

Automatic Cloud KMS Rotation for CMEK Data

Explanations

Create an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

What Cloud Function KeyRing Recreation Does

Why It Doesn't Meet the Requirement

Key Characteristics

This Answer Would Be Correct If

Create an asymmetric Cloud KMS signing key with an automatic 90-day rotation period, grant the Cloud KMS Admin role to the resource service agent, and disable older versions.

What Asymmetric Signing Keys and Admin Roles Do

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Create a symmetric Cloud KMS key with a 90-day rotation period, reference the fully qualified CryptoKey resource name without a version suffix in the resource encryption specifications, and keep previous key versions enabled.

What Automated CMEK Key Rotation Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Create a symmetric Cloud KMS key with a 90-day rotation period, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

What Explicit Version Referencing and Immediate Destruction Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Cloud KMS HSM Key Import (BYOK)

Cloud KMS CryptoKeyVersion Disable and Destroy

Organization Policy Inheritance and Overrides

On-Demand Scanning Pre-Push Gating

Cloud SQL Auth Proxy with Workload Identity

Analytics Hub Authorized Views And Row-Level Security