Cloud Storage: Versioning & Lifecycle Management

Step 0: Authentication

How this works: You need a Google account that uses the same email address as your GCP Study Hub account. When you sign into that Google account, the system will be able to grant you temporary access to a GCP project when you start the lab.

Click the button below to start your lab:

Step 1: Open Google Cloud Console

Once your lab starts, use the "Open GCP Console" button from the lab portal to open the Google Cloud Console with your temporary lab project already selected.

Step 2: Navigate to Cloud Storage

1. In the left navigation menu, click on the hamburger menu (three horizontal lines)
2. Scroll down and find Cloud Storage
3. Click on Buckets

Alternatively, you can search for "Cloud Storage" in the search bar at the top.

Step 3: Create a Bucket with Versioning Enabled

1. Click the CREATE button at the top of the page
2. Name your bucket:
   • Start with lab-versioned-bucket-
   • Add a unique random suffix to make it your own. Examples: lab-versioned-bucket-xyz789, lab-versioned-bucket-abc456def, lab-versioned-bucket-q7w8e9
   • If you get "name already taken," add more unique characters
3. Choose where to store your data:
   • Select Region and choose us-central1
   • In the real world, you can choose any region, dual-region, or multi-region based on your users' locations and latency needs. For this lab, we're using us-central1 for cost control and security.
4. Choose a storage class: Select Standard. Standard class provides the best performance for frequently accessed data.
5. Choose how to control access: Select Uniform. Uniform access control applies permissions consistently across all objects in the bucket.
6. Enforce public access prevention:
   • Make sure "Enforce public access prevention on this bucket" is checked (should be checked by default)
   • This prevents any objects in the bucket from being publicly accessible on the internet, which is a security best practice. Even if someone accidentally makes an object public, this setting blocks it.
7. Advanced settings:
   • Continue until you get to the Data protection section
   • Find the checkbox for Object versioning
   • Check the box to enable object versioning
   • Leave the other versioning settings as defaults - you'll learn to manage version cleanup using lifecycle rules later in this lab.
   • Retention (For compliance): Leave this unchecked. Retention policies prevent deletion or modification of objects for a specified period of time, which is useful for regulatory compliance (like HIPAA or financial regulations). We're not using it in this lab because we need the ability to delete objects during cleanup.
8. Data encryption: Leave this as the default (Google-managed encryption key). This provides encryption at rest without you having to manage keys.
9. Click CREATE at the bottom

What just happened: You created a bucket with versioning enabled. When you upload a file with the same name multiple times, Cloud Storage will keep all versions instead of replacing the old one. Each version gets a unique generation number and timestamp.

Step 4: Download Sample File

Download this sample inventory file that you'll upload and modify to demonstrate versioning:

The file will be saved to your Downloads folder. You'll upload it, then edit it locally and upload it again to create new versions.

Step 5: Upload the Initial Version

1. Click on your bucket name to open it
2. Click the UPLOAD FILES button
3. Select inventory.txt from your Downloads folder
4. Wait for the upload to complete (should be instant for this small file)
5. You should see inventory.txt listed in your bucket

What you just did: You uploaded the first version of this file. Because versioning is enabled, this version will be preserved even when you upload newer versions with the same filename.

Step 6: Edit the File and Upload Version 2

Now you'll modify the file locally and upload it again with the same filename to create a new version.

1. On your computer, find inventory.txt in your Downloads folder
2. Open it in a text editor (Notepad on Windows, TextEdit on Mac, or any text editor)
3. Change some of the numbers. For example, change "Product A: 100 units" to "Product A: 85 units"
4. Change the date at the bottom to today's date
5. Save the file (keep the same filename: inventory.txt)
6. Back in the Cloud Storage console, click UPLOAD FILES again
7. Select inventory.txt from your Downloads folder
8. You'll see a dialog: "Resolve object conflict - inventory.txt already exists"
9. Select "Overwrite object" (this creates a new version instead of truly overwriting)
10. Click UPLOAD

What you just did: You uploaded a second version of the same filename. Without versioning, the old version would be permanently deleted. With versioning enabled, the old version is preserved as an archived (noncurrent) version.

View Your Versions

1. Click on inventory.txt in the bucket
2. Click the Version history tab at the top
3. You should see 2 versions listed:
   • The top one shows (Live object) - your most recent upload
   • The older version below it with a Restore button - your original upload
4. Each version shows details:
   • Generation: Unique timestamp-based ID (microseconds since Unix epoch)
   • MD5 hash: Cryptographic fingerprint of the file contents
   • CRC32C hash: Checksum for verifying data integrity
   • Storage class: Which tier the object is stored in (Standard, Nearline, Coldline, Archive). Notice that storage class is shown at the object level - you can set storage classes per individual object or even per version, not just at the bucket level. This allows you to move older versions to cheaper storage tiers while keeping current versions in Standard.
   • Size: File size in bytes
5. Notice that both versions exist and are consuming storage space

Step 7: Create Version 3

Create one more version to see how versions accumulate:

1. Edit inventory.txt again on your computer
2. Make different changes (update different product quantities, change the date)
3. Save the file
4. Upload inventory.txt to the bucket again (select "Overwrite object" when prompted)
5. Click on inventory.txt again to open the object details
6. Click the Version history tab at the top
7. You should now see 3 versions:
   • 1 live version (most recent upload)
   • 2 noncurrent versions (your previous edits)

What you have now: You have 3 versions of this file stored in Cloud Storage. This demonstrates how versions accumulate over time, which can add up to significant storage costs.

Step 8: Restore an Old Version

Now you'll restore version 2 (your first edit) to see how version recovery works in practice.

1. In the Version history tab, find your second-oldest version (your first edit, the middle one in the list)
2. Click the Restore button next to that version
3. Confirm the restore action
4. Look at the version history again. You should now see 4 versions:
   • Live object: The restored version (your first edit is back!)
   • 3 noncurrent versions: Your original file, second edit, and third edit
5. Optional: Download the current file and open it to verify it contains your first edit's content

What just happened: Restoring didn't "undo" anything - it created a new version (version 4) that's a copy of version 2's content. The version you restored from still exists as a noncurrent version. This means you can restore as many times as you want without losing any history.

Step 9: Create a Lifecycle Rule to Delete Old Versions

Lifecycle rules automate cleanup by deleting or archiving old versions after a specified time period. You'll create a rule that deletes noncurrent versions after 7 days.

1. Go back to the bucket list (click Buckets in the left menu)
2. Find your bucket (lab-versioned-bucket-...) and click on it to open it
3. Click Lifecycle near the center of the screen
4. You'll see some default lifecycle rules that were automatically created when you enabled versioning (like "Delete object 1+ days since becoming noncurrent"). Delete all existing rules by clicking the trash icon next to each one.
5. Now click ADD A RULE to create your own custom rule
6. Select object action:
   • Check the box for Delete object
   • This action will permanently remove old versions to save storage costs
7. Click CONTINUE
8. Select object conditions:
   • Find the Days since noncurrent option
   • Check this box
   • Enter 7 in the text field
   • This means "delete versions that have been noncurrent (archived) for 7 or more days"
9. Click CONTINUE
10. Review the rule summary and click CREATE

What you just configured: Your bucket will now automatically delete old versions after they've been noncurrent for 7 days. The live (current) version is never affected by this rule.

Step 10: Review Common Lifecycle Patterns

While you created a simple delete rule, lifecycle management supports many strategies. Here are patterns used in production:

Pattern 1: Version Cleanup (what you just created)

• Action: Delete
• Condition: Noncurrent time greater than 7-30 days
• Use case: Keep recent versions for rollback, delete old ones to save costs
• Example: Database backups, application config files, user document uploads

Pattern 2: Archive Old Data

• Action: Set storage class to Nearline or Coldline
• Condition: Age greater than 90 days
• Use case: Logs, backups you rarely access but need to keep
• Cost benefit: Nearline is $0.01/GB (vs $0.02 Standard) = 50% savings

Pattern 3: Delete Temporary Files

• Action: Delete
• Condition: Age greater than 1 day
• Use case: Build artifacts, temporary uploads, cache files
• Example: CI/CD systems that generate artifacts for each build

Pattern 4: Multi-tier Strategy (Compliance)

• Rule 1: Move to Nearline after 30 days
• Rule 2: Move to Coldline after 180 days
• Rule 3: Delete after 365 days
• Use case: Regulated industries with specific retention requirements (HIPAA, GDPR, SOX)