Aging, tiering, and expiring data over its lifecycle

Lifecycle management automates moving or deleting data as it ages, reducing storage costs while meeting retention and compliance needs. On Google Cloud, this is primarily implemented via Cloud Storage Object Lifecycle Management rules, BigQuery table/partition expiration, and Bigtable garbage collection policies. Choosing the right mechanism per service is a common exam focus.

1 · Learn the must-know

• 1Cloud Storage Object Lifecycle Management uses conditions (age, createdBefore, matchesStorageClass, numNewerVersions, isLive, daysSinceCustomTime, daysSinceNoncurrentTime) combined with actions (SetStorageClass, Delete) defined in a JSON lifecycle configuration applied to a bucket.
• 2Lifecycle transitions in Cloud Storage only move data to a 'colder' (cheaper) storage class or delete it, you cannot use lifecycle rules to transition to a warmer/more expensive class.
• 3Lifecycle rule evaluation in Cloud Storage runs asynchronously (checked roughly once per day), so actions are not instantaneous when an object first meets a condition.
• 4BigQuery supports dataset-level default table expiration and per-table expiration (expirationTime), plus partition expiration on partitioned tables, so BigQuery handles its own lifecycle rather than relying on Cloud Storage rules.
• 5Bigtable lifecycle is managed through garbage collection (GC) policies per column family, based on age (MaxAge) or version count (MaxVersions), not through Cloud Storage-style lifecycle rules.
• 6For compliance/legal holds, Cloud Storage offers Bucket Lock (retention policies) and Object Hold, which can override or block lifecycle deletion until the hold/retention period expires.

2 · Check your understanding