Cloud Storage: Retention Policies & Bucket Lock

Lab Introduction

As you can imagine, there are situations where you really need to be sure that data is kept and not deleted, either intentionally or by accident. Company financial records, medical records and legal evidence are all examples. Sometimes your GCP environment gets audited, and the data for that audit absolutely has to be preserved for the duration of the audit.

That is where retention policies come in. A retention policy on a Cloud Storage bucket sets a minimum length of time that every object must be kept, counted from the moment each object is uploaded. Until that time has passed, the object cannot be deleted or overwritten. It is a property of the bucket rather than a permission, so it applies to everybody: no amount of IAM access gets you around it.

You can also take the extra step of locking your retention policy with bucket lock, which truly means that nobody can delete the data in the bucket you have locked, for the duration of the retention policy. Not even a Project Owner, and not Google support. The bucket itself cannot be deleted while any object inside it is still within its retention period, so short of deleting the entire project there is no way to get rid of the data early.

In this lab you will set a retention policy, watch it refuse to let you delete a file, then lock it and find out exactly what "irreversible" means in practice.

Requirements to Pass This Lab

Before You Begin

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:

Start Lab

Instructions

Step 1: Open Google Cloud Console

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

Step 2: Create a Bucket

  1. Go to Navigation menu (☰) > Cloud Storage > Buckets and click CREATE
  2. Under Get started, enter a name beginning with gcpstudyhub-lab-retention- followed by your own numbers, for example gcpstudyhub-lab-retention-4821. Note what the console asks for: a globally unique, permanent name. Bucket names are shared across the whole of Google Cloud rather than just your project, so if the name you pick is already taken by someone else's bucket anywhere in the world, you will be told to choose another
  3. Below the name is Labels (optional). Labels are key:value pairs that let you group related buckets together, or group them with other Google Cloud resources, usually so that costs can be broken down later. You do not need any here, so leave that section alone and click Continue
  4. Choose where to store your data defaults to Multi-region in us. Change Location type to Region and pick us-central1 (Iowa), then Continue
  5. Leave the remaining sections at their defaults: storage class Standard, Public access prevention on, access control Uniform
  6. Stop at Choose how to protect object data, because all three options here are easy to confuse with each other and only one of them is this lab's subject:
    • Soft delete policy (For data recovery) keeps deleted objects recoverable for a while, 7 days by default. It is a safety net against your own mistakes, and it is already on
    • Object versioning (For version control) keeps the old copy when an object is overwritten. That is the subject of Cloud Storage Versioning
    • Retention (For compliance) is the one this lab is about, and the wording tells you how different it is: "For preventing the deletion or modification of the bucket's objects for a specified period of time". The first two help you undo things. This one stops you doing them at all
    Leave all three alone for now. You could set retention here at creation time, but you will add it from the Protection tab in a moment, because that is also where you will lock it later
  7. Click CREATE. If a dialog about public access appears, click CONFIRM

This is the same bucket creation you did in Cloud Storage Basics, so it is compressed here. If any of it is unfamiliar, go back and review that lab.

Step 3: Set a Retention Policy

The policy goes on before there is anything in the bucket, so that every object is covered from the moment it lands. A retention period is counted from each object's own upload time, not from when you set the policy, so a policy added afterwards would leave the files you already had sitting there unprotected until you touched them again.

  1. Click the Protection tab
  2. Under Retention (For compliance), click Set retention policy
  3. Read the dialog. It says it wants "the minimum period of time that this bucket's objects must be retained after they're uploaded"
  4. Enter 60 and leave the units on seconds, then click SAVE

The Protection tab now shows:

Retention period    1 minute
Effective date      <the moment you saved>
Retention mode      Unlocked

Note Retention mode: Unlocked. Right now this policy is a rule you set and can unset. That changes in Step 7.

Sixty seconds is absurdly short for real compliance, where retention is measured in years. It is used here so you can watch the whole lifecycle inside one lab. Everything you are about to see works identically at a period of years.

Look at the top of the page: Protection now reads Soft Delete, Bucket retention.

Step 4: Upload Two Files

You need two files: one to delete, and one to leave alone as a control. Download both:

Download keep-me.txt Download delete-me.txt
  1. Go to your bucket's Objects tab, click UPLOAD and then Upload files
  2. Select both files you just downloaded and confirm they appear in the list

Both are now protected, and their sixty seconds started the moment they finished uploading.

The names matter. The lab checker will look for these exact filenames.

Step 5: Try to Delete Them

Do this straight away, while both files are still inside their sixty seconds.

  1. In the Objects tab, tick the checkbox in the header row to select both files
  2. Click DELETE in the blue bar, then confirm

Nothing disappears. A banner reports the deletion failed, and both files are still in the list.

The banner alone does not say why, but the reason is one click away. Open the failure details from that banner:

Deletion progress
0 of 2 objects

Failures
2 objects

Status                          Sample error message
Failed    Retention policy not met (2 errors)
          Object '<your-bucket>/delete-me.txt' is subject to bucket's
          retention policy or object retention and cannot be deleted or
          overwritten until <timestamp 60s after you uploaded it>

Read the two halves of that. Retention policy not met is the diagnosis in four words. The message below it names the object, names the cause, and gives you the exact moment the object becomes deletable, which is the one fact you actually need in order to know what to do next.

This is the pattern to take away, and it is not unique to Cloud Storage: the toast tells you something failed, and the details view tells you why. When an operation in the console fails and the message looks useless, look for the link into the details before you start guessing.

Step 6: Wait, Then Delete One

  1. Wait a minute. The retention period on both objects is expiring
  2. Tick delete-me.txt only, click DELETE, then confirm
  3. This time it succeeds and disappears from the list

Leave keep-me.txt where it is. It is the control: it was uploaded at the same moment, under the same policy, and it is just as deletable now as delete-me.txt was. The only reason it survives is that you chose not to delete it, and that is the point. The policy never decided which file mattered. It only ever decided when.

Nothing about the bucket changed between your two attempts. The only difference is that time passed. That is the whole idea: the policy protects each object for a fixed period after upload, then stops.

Step 7: Lock the Policy

So far the policy is a rule you set and can unset. Locking removes that escape hatch permanently.

  1. Return to the Protection tab
  2. Note the three buttons: Edit, Delete and Lock
  3. Click Lock and read the dialog carefully before doing anything

It warns you, in its own words:

This action is permanent. By locking the policy, you'll incur storage
costs for the full retention period of the bucket's objects.
  1. To confirm, you must type the bucket name into the box. Do that, then click LOCK POLICY

Typing the resource name is a pattern Google uses for actions that cannot be undone. When you meet it anywhere in the console, slow down.

Why you are allowed to do this at all. Locking a retention policy is genuinely irreversible. Not by you, not by the project owner, not by Google support. A bucket with a locked policy cannot be deleted until every object in it has finished its retention period, and that period can be set as high as 100 years.

In a lab environment that would be a disaster, because the project you are working in gets recycled for the next student. A bucket locked for a century would make that project unusable forever.

So GCP Study Hub applies a custom organization policy constraint to every lab project, which denies any lock longer than 60 seconds. That is why you can safely perform a permanent operation here: the guardrail bounds the damage to one minute, while everything you are learning is exactly what happens in production.

Organization policy constraints are how real companies do this too. They sit above IAM and restrict what can be done with a resource, regardless of who is asking. If you try to lock a longer period in this lab, the request will be refused, and the refusal will name the constraint.

Step 8: See What Locking Took Away

Look at the Protection tab again. Retention mode now reads Locked, and the row of buttons above it has changed.

  1. The Lock button is gone, because there is nothing left to lock
  2. Delete is greyed out. The button you used a moment ago to remove the policy is dead, permanently
  3. Edit still works, but only in one direction. You can make the retention period longer, never shorter

That last point is the part people miss. Locking does not freeze the policy, it makes it one-way. A mistake can still be made worse, just never undone.

There is one more consequence, and it is the one that turns a locked policy from an inconvenience into a real problem: the policy now controls whether the bucket itself can be deleted.

Deleting a bucket means deleting everything in it first, and the console does that for you as part of the same operation. So a bucket is deletable only when every object in it has already met its retention period. If you try while even one object is still inside its window, the whole thing stops, and the failure details name the object holding it up:

Deletion progress
0 of 1 buckets

Failures
1 buckets

Buckets                                            Status
<your-bucket> (failed to delete 1 object)          Failed
    Retention policy not met (1 error)
    Object '<your-bucket>/delete-me.txt' is subject to bucket's retention
    policy or object retention and cannot be deleted or overwritten until
    <timestamp 60s after that object was uploaded>

That is the same Retention policy not met you saw in Step 5, now blocking the bucket rather than a single file. With your sixty second policy it clears itself in under a minute. Read the period as something realistic instead, and a locked bucket is undeletable by anyone for as long as that period lasts.

This is why the sixty second cap described in Step 7 exists. An unlocked policy can be removed, so an unlocked bucket can always be emptied and deleted. A locked one cannot, and there is no identity anywhere that can override it. Locked plus a long retention period is precisely the combination that would leave a lab project holding a bucket nobody can remove.

Validate Your Work

Get Your Completion Token

Click the button below to open the lab checker in a new window. Sign in with Google to verify your work and get your completion token.

Open Lab Checker

Submit Your Token

Paste your token below and click Validate. If valid, a button will appear to mark the lesson complete.

What You Learned

Troubleshooting

My delete succeeded when it was supposed to fail

The retention clock runs from the moment each object was uploaded, so if more than a minute passed between uploading delete-me.txt and clicking delete, it was no longer protected. Upload the file again and try deleting it immediately.

The Lock button is refused

If you set a retention period longer than 60 seconds, locking is blocked by the organization policy described in Step 7, and the error will name custom.prohibitBucketLock. Set the retention period back to 60 seconds and lock it then.

I see a red error about "cross bucket replications"

On the Configuration tab you may see "Failed to fetch cross bucket replications: Permission 'storagetransfer.jobs.list' denied". This is expected and harmless. Your lab account intentionally does not have Storage Transfer Service permissions and nothing in this lab uses that feature.

Validation Fails

If your validation fails, check that: