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.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Configure Cmek Automated Key Rotation Schedule

Section: Creating and managing encryption keys for CMEK and EKM (e.g., key rotation and revocation, key import).

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, specify the exact CryptoKeyVersion resource name in each resource encryption configuration, and destroy previous key versions immediately upon rotation.

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 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 an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Configure Cmek Automated Key Rotation Schedule

Section: Creating and managing encryption keys for CMEK and EKM (e.g., key rotation and revocation, key import).

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 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 an automated Cloud Function that provisions a new Cloud KMS KeyRing every 90 days, re-encrypts all workloads, and deletes the prior KeyRing.

Explanations

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

Professional Cloud Security Engineer

Configure Cmek Automated Key Rotation Schedule

Professional Cloud Security Engineer

Configure Cmek Automated Key Rotation Schedule

What Automated CMEK Key Rotation Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions

Looker vs Looker Studio Semantic Layer