Lifecycle Rule to Archive Objects After 90 Days
You are managing your company's archival records that are stored in a Cloud Storage bucket using the Multi-Regional storage class. These objects are rarely accessed after 90 days but must be retained indefinitely to meet regulatory compliance requirements. You need to implement a cost-effective process that automatically transitions these objects to the lowest-cost storage class suitable for long-term retention immediately after the 90-day period. What should you do?
Community Insight
The task requires automatic, cost-based storage class transition without data loss, and the trap is choosing options that delete data, add needless versioning, or replace built-in lifecycle automation with custom code.
This question tests how to automatically move rarely accessed Cloud Storage objects to the cheapest long-term storage class after 90 days while keeping them retained. The correct approach is a bucket-level Object Lifecycle Management rule using an age condition of 90 days with the SetStorageClass action targeting Archive storage.
Option A is the most tempting wrong answer: enabling Object Versioning and using daysSinceNoncurrentTime only transitions noncurrent (superseded) versions, so the live archival records would never move to Archive and would keep incurring Multi-Regional costs. Option D is even more dangerous because the Delete action destroys records that must be retained indefinitely.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option B uses the native Object Lifecycle Management feature, which is designed exactly for this scenario: a rule evaluated daily on the bucket with an age condition of 90 days and a SetStorageClass action that transitions matching objects to Archive storage. Archive is the lowest-cost Cloud Storage class suited to long-term retention of rarely accessed data that must still be retrievable, and because the rule transitions rather than deletes, the regulatory indefinite-retention requirement is satisfied. Lifecycle rules are free of charge, managed entirely by Cloud Storage, and require no application code or scheduling infrastructure, making this the most cost-effective and operationally simple answer.
Why the Other Options Are Wrong
Option A adds Object Versioning and applies daysSinceNoncurrentTime, which only affects noncurrent versions — objects that have been overwritten. Since these archival records are not being replaced, they remain current versions and would never be transitioned, and versioning itself adds storage costs and complexity. Option C builds a nightly Cloud Run function with Cloud Storage API calls to rewrite storage classes, which duplicates built-in functionality, adds runtime and egress costs, and introduces failure points such as a missed schedule or permission errors — the opposite of cost-effective. Option D uses the createdBefore condition with a Delete action, which permanently removes the objects and directly violates the requirement that records be retained indefinitely for regulatory compliance.
Community Comment Notes
The lone community comment, from lucas_0102, simply asks "Can someone go over why this is the correct answer?" without asserting an answer, so it provides no competing rationale to weigh. That question is answered by the key distinction in this scenario: lifecycle rules act on current versions via an age-based condition, whereas versioning and noncurrent-time conditions address a different problem entirely.
Official Reference
Exam Strategy
On GCP cost-optimization questions, always prefer the managed, declarative service feature (here, Object Lifecycle Management) over custom code, and reject any option whose action is Delete when the prompt requires indefinite retention. Match the transition target to the access pattern: Archive for rarely accessed long-term data.
Frequently Asked Questions
Why is Object Versioning with daysSinceNoncurrentTime wrong for this archival scenario?
daysSinceNoncurrentTime applies only to noncurrent (overwritten) versions. Archival records that are never overwritten stay as current versions, so the rule would never move them to Archive storage.
Why not use a Cloud Run function to change storage classes after 90 days?
Cloud Storage lifecycle rules already do this automatically and for free. Custom code adds runtime costs, scheduling, IAM permissions, and failure points with no benefit over the built-in SetStorageClass action.
Is Archive storage truly the lowest-cost class for indefinite retention?
Among Cloud Storage classes suitable for rarely accessed, long-term retained data (Nearline, Coldline, Archive), Archive has the lowest storage cost per month, making it the right target for regulatory archives that are rarely retrieved.
Related Analysis
Practice All ACE Questions
Access 84 questions with complete answers and detailed explanations.
View Full ACE Practice Test →