Lifecycle rules are the answer to a specific kind of Associate Cloud Engineer exam question, and recognizing the question pattern is more important than memorizing every condition the rules support. This article covers what lifecycle rules do, the structure they follow, the common patterns, and the exam scenarios where they are the right answer.
It does not cover every supported condition or action. The Google docs are the right place for that. The exam tests the basic mechanic and the common patterns.
A lifecycle rule is a rule attached to a Cloud Storage bucket that automatically transitions objects to a different storage class, or deletes them, based on conditions you define. The most common condition is age. The most common actions are SetStorageClass and Delete.
The Associate Cloud Engineer exam describes it directly. Lifecycle rules manage the transition of objects to different storage classes, or their deletion, based on conditions such as their age. That is the whole concept in one sentence.
A lifecycle rule has two parts. A condition that says when the rule applies, and an action that says what happens. Here is a JSON config for a bucket that moves objects to Nearline after 30 days and deletes them after 365:
{
"lifecycle": {
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
},
{
"action": {"type": "Delete"},
"condition": {"age": 365}
}
]
}
}You apply this with gsutil:
gsutil lifecycle set lifecycle.json gs://my-bucketThe patterns that show up on Associate Cloud Engineer exam questions are these. Move logs from Standard to Nearline after 30 days. Move backups from Nearline to Coldline after 90 days. Move long-term archives to Archive storage after a year. Delete temporary files after a fixed number of days.
The numbers map to the minimum storage durations of the classes. Nearline requires a minimum of 30 days. Coldline requires 90. Archive requires 365. If you transition objects below these thresholds, you still pay for the full minimum, so the lifecycle rules tend to align with those numbers.
If you see a question about automatically moving older data to a cheaper storage class, lifecycle rules are the answer. The clue is the word automatically combined with some kind of age-based criterion.
If you see a question about deleting old objects on a schedule, lifecycle rules with a Delete action are the answer. Doing this manually with a Cloud Function or a cron job is technically possible but it is the wrong answer when lifecycle rules exist for exactly this purpose.
If you see a question about reducing Cloud Storage costs for backup data that gets accessed less over time, the answer involves a lifecycle rule that transitions data through Nearline, then Coldline, then potentially Archive as it ages.
The pattern to look for: any time the question describes some condition based on object age and an action that should happen automatically, lifecycle rules are the right tool. If the action is something other than a class change or a deletion, like processing the object or copying it elsewhere, lifecycle rules are not the right tool. That is when Cloud Functions triggered on storage events come in.
Lifecycle rules are evaluated once per day, not in real time. An object that just hit its 30-day mark might not transition for up to 24 hours. This is rarely tested on the exam, but it does come up occasionally as a wrong-answer trap when a question implies real-time transitions.
Lifecycle rules automate Cloud Storage class transitions and object deletions based on conditions like age. The common patterns are Standard to Nearline at 30 days, Nearline to Coldline at 90, and Delete at 365. If an Associate Cloud Engineer exam question describes any kind of age-based automatic action on objects in a bucket, lifecycle rules are the answer.
My Associate Cloud Engineer course covers lifecycle rules in the Cloud Storage section alongside storage classes, retention policies, and object versioning.
