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.

Must-know

• Cloud 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.
• Lifecycle 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.
• Lifecycle rule evaluation in Cloud Storage runs asynchronously (checked roughly once per day), so actions are not instantaneous when an object first meets a condition.
• BigQuery 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.
• Bigtable 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.
• For 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.

Coverage checked against the published exam guide on Aug 11, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.