A financial enterprise uses Google Cloud Storage to store sensitive audit logs and transaction records. The bucket is configured with Customer-Managed Encryption Keys (CMEK) managed in Cloud Key Management Service (Cloud KMS). To align with internal data governance and cost optimization frameworks, the security team implements the following configurations: An Object Lifecycle Management policy with a SetStorageClass action to transition objects from Standard to Archive storage after 90 days. An Object Lifecycle Management policy with a Delete action for objects older than 7 years. An active Legal Hold applied to specific objects involved in ongoing regulatory inquiries. An automated annual key rotation schedule configured in Cloud KMS for the CMEK CryptoKey. How do these lifecycle actions and security controls affect object availability, legal holds, and encryption states?

Objects with an active legal hold still transition to Archive storage but cannot be deleted by lifecycle rules, and existing objects continue to be encrypted with their original CMEK key version rather than automatically re-encrypting when keys rotate.: ### What Cloud Storage Lifecycle and CMEK Governance Enforce In Google Cloud Storage, **Object Lifecycle Management** allows organizations to automate data tiering and deletion. However, governance controls like **Legal Holds** and cryptographic policies governing **Customer-Managed Encryption Keys (CMEK)** dictate exact availability and protection states during these automated operations. ### How It Meets Security and Compliance Requirements - **Legal Hold Enforcement**: A legal hold prevents an object from being deleted or overwritten by any identity or automated process, including lifecycle `Delete` actions. However, non-destructive lifecycle actions—specifically `SetStorageClass` transitions (such as moving from Standard to Nearline, Coldline, or Archive)—are permitted and execute as scheduled. This ensures cost optimization without compromising data preservation. - **CMEK Encryption State During Transitions**: Storage class transitions change the metadata and underlying physical tiering of the object but do not perform a cryptographic rewrite of the data payload. The object remains encrypted at rest using the exact **Cloud KMS key version** with which it was initially encrypted. - **CMEK Key Rotation Behavior**: When a Cloud KMS CMEK key undergoes automatic or manual rotation, Cloud KMS creates a new primary key version for future write operations. Existing objects encrypted with previous key versions are **not automatically re-encrypted**. To preserve data availability, older key versions must remain enabled in Cloud KMS so Cloud Storage can decrypt and serve the data when requested. ### Key Advantages and Governance Capabilities - **Immutable Retention**: Legal holds guarantee compliance with legal discovery and regulatory mandates without freezing cost-optimization tiering. - **Cryptographic Boundary Control**: Retaining historical key versions ensures continuous access to archived objects without incurring compute overhead from massive bucket rewrites. - **Separation of Duties**: Security administrators maintain key lifecycles independently of storage lifecycle policies. ### Why This Is Optimal This architecture balances compliance mandates (preserving evidentiary records via legal holds), financial governance (downward storage class tiering to Archive), and cryptographic integrity (maintaining established envelope encryption keys).

Gcs Lifecycle Encryption Legal Holds Governance | Professional Cloud Security Engineer

Gcs Lifecycle Encryption Legal Holds Governance

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial enterprise uses Google Cloud Storage to store sensitive audit logs and transaction records. The bucket is configured with Customer-Managed Encryption Keys (CMEK) managed in Cloud Key Management Service (Cloud KMS).

To align with internal data governance and cost optimization frameworks, the security team implements the following configurations:

An Object Lifecycle Management policy with a SetStorageClass action to transition objects from Standard to Archive storage after 90 days.
An Object Lifecycle Management policy with a Delete action for objects older than 7 years.
An active Legal Hold applied to specific objects involved in ongoing regulatory inquiries.
An automated annual key rotation schedule configured in Cloud KMS for the CMEK CryptoKey.

How do these lifecycle actions and security controls affect object availability, legal holds, and encryption states?

Objects under an active legal hold are completely excluded from all lifecycle actions including storage class transitions, and rotating the Cloud KMS key triggers an automatic rewrite that re-encrypts all objects with the new primary key version.

Lifecycle deletion actions permanently delete objects older than 7 years regardless of legal holds, and transitioning objects to Archive storage automatically falls back to Google default encryption.

Transitioning objects to Archive storage decrypts and re-encrypts the payload with the latest primary CMEK version, and disabling older key versions in Cloud KMS has no impact on existing archived data availability.

Objects with an active legal hold still transition to Archive storage but cannot be deleted by lifecycle rules, and existing objects continue to be encrypted with their original CMEK key version rather than automatically re-encrypting when keys rotate.

Professional Cloud Security Engineer

Gcs Lifecycle Encryption Legal Holds Governance

Related questions