This chapter covers Cloud Storage retention policies and retention locks, two critical features for enforcing data retention compliance in Google Cloud. On the ACE exam, roughly 5-7% of questions touch on storage governance, including retention policies, lifecycle management, and bucket lock. Understanding the difference between a retention policy (which can be modified) and a retention lock (which makes the policy immutable) is essential. This chapter explains the mechanism, configuration steps, and common exam traps.
Jump to a section
Imagine a library archive room where each document is stored in a locked box. The librarian can set a retention policy: 'This box must stay locked for 7 years.' During those 7 years, the box cannot be opened—documents cannot be deleted or modified. However, the librarian can still change the lock combination (the retention policy) as long as the box stays locked. Now, the library wants to prevent even the librarian from changing the policy, so they apply a 'tamper-proof seal'—a physical lock that cannot be cut or unlocked by anyone, including the librarian. Once the seal is applied, the box is locked for exactly 7 years, and no one—not even the library director—can shorten the duration or remove the lock. The only way to remove the seal is to wait until the 7 years expire, at which point the seal automatically breaks and the box can be unlocked. If someone tries to destroy the box (delete the bucket), they can't because the seal prevents the box from being removed from the archive room. This mirrors Google Cloud Storage's retention policies: a policy sets a minimum retention period for objects; a retention lock permanently prevents the policy from being reduced or removed, ensuring compliance even against administrative actions.
What Are Cloud Storage Retention Policies?
A retention policy is a bucket-level configuration that enforces a minimum duration (in seconds) for which objects in the bucket must be retained. Once set, objects cannot be deleted or overwritten until they have existed for the duration specified by the policy. The policy applies to all objects in the bucket, including those uploaded before the policy was set.
Why Retention Policies Exist
Organizations often have regulatory or legal requirements to retain data for a specific period (e.g., 7 years for financial records). Without a retention policy, an administrator could accidentally or maliciously delete objects prematurely. Retention policies provide a guardrail: they prevent deletion or overwrite of objects until the retention period has elapsed.
How Retention Policies Work Internally
When a retention policy is set on a bucket, Cloud Storage tracks the creation time of each object. For a delete or overwrite operation to succeed, the object must have existed for at least the retention duration. The check is performed server-side: the object's creation timestamp is compared to the current time. If the difference is less than the retention period, the operation fails with a 403 error and a message like "The object is under retention policy and cannot be deleted or overwritten."
Retention policies are independent of object hold mechanisms (temporary holds and event-based holds). A retention policy is a bucket-wide setting; holds are per-object. Both must be satisfied for deletion to be allowed. For example, if a retention policy requires 30 days and an object also has a temporary hold, the object cannot be deleted until both the 30-day period expires AND the hold is removed.
Key Components and Defaults
- Retention period: Specified in seconds. Minimum is 1 second, maximum is 3,155,760,000 seconds (100 years). - Default event-based hold: Not a retention policy, but related. It associates a hold with an object that is released when a specified event occurs. - Retention policy mode: There are two modes: - *Unlocked*: The policy can be reduced or removed at any time. - *Locked*: The policy cannot be reduced or removed; it becomes immutable. - Retention lock: The operation that transitions a policy from unlocked to locked. Once locked, the policy is permanent for the bucket. The lock is irreversible.
Configuration and Verification
To set a retention policy on a bucket using gsutil:
gsutil retention set 365d gs://my-bucketThis sets a 365-day retention policy. The duration can be specified in seconds (e.g., 31536000) or using time suffixes: d (days), m (months), y (years).
To view the retention policy:
gsutil retention get gs://my-bucketTo lock the policy:
gsutil retention lock gs://my-bucketAfter locking, the policy cannot be reduced or removed. To verify the lock status, use:
gsutil bucketinfo gs://my-bucket | grep "Retention Policy"In the Google Cloud Console, retention policies are configured under the Bucket > Configuration > Protection tools > Retention policy. The lock is applied by clicking "Lock Policy" after setting a policy.
Interaction with Lifecycle Management
Retention policies interact with lifecycle rules. Lifecycle actions (Delete, SetStorageClass) are subject to retention policies. If a lifecycle rule attempts to delete an object that is still within the retention period, the action is deferred until the retention period expires. The lifecycle rule remains in place, but the deletion is postponed. Similarly, if a lifecycle rule changes the storage class, that is allowed even during the retention period because it does not delete the object.
Interaction with Object Holds
Object holds are per-object settings that prevent deletion or overwrite. There are two types: - Temporary hold: Set and removed manually. - Event-based hold: Automatically released when a specified event occurs (e.g., after a custom action).
Retention policies and object holds are independent. An object cannot be deleted if either the retention policy period has not elapsed OR the object has an active hold. For deletion, both conditions must be met: the retention period must have passed AND no holds must be active.
Bucket Lock and Compliance
A retention lock is used for compliance scenarios where even bucket administrators must be prevented from altering the retention period. Once locked, the retention period can only be increased (extended), never decreased. The lock applies to the entire bucket; individual objects cannot be locked separately. The lock is permanent; there is no way to unlock a bucket.
Important Timers and Values
Retention period maximum: 100 years (3,155,760,000 seconds).
Retention period minimum: 1 second (though practically, use cases require longer).
Time units: s, m, h, d, m (month as 30 days), y (year as 365 days).
Lock is irreversible once applied.
Exam Tips
The ACE exam often tests:
The difference between unlocked and locked retention policies.
That a locked policy can only be increased, not decreased.
That retention policies prevent deletion/overwrite, not reads.
That lifecycle deletion actions are deferred, not cancelled, by retention policies.
That object holds and retention policies are independent and both must be satisfied.
The exact gsutil commands: gsutil retention set, gsutil retention get, gsutil retention lock.
The maximum retention period (100 years).
Set an Unlocked Retention Policy
First, create or identify an existing Cloud Storage bucket. Use the gsutil command `gsutil retention set <duration> gs://<bucket-name>` to apply an unlocked retention policy. The duration can be specified in seconds or using time suffixes (d, m, y). For example, `gsutil retention set 365d gs://my-bucket` sets a 365-day retention period. At this point, the policy is unlocked, meaning you can later reduce the duration or remove the policy entirely. The policy immediately applies to all objects in the bucket, including existing objects. Any attempt to delete or overwrite an object that has not existed for at least 365 days will fail with a 403 error.
Verify the Retention Policy
Use `gsutil retention get gs://my-bucket` to display the current retention period and whether it is locked. The output shows the duration and the locked status (true or false). Alternatively, use `gsutil bucketinfo gs://my-bucket` to see the full bucket configuration, including the retention policy. In the Google Cloud Console, navigate to the bucket's 'Configuration' tab under 'Protection tools' to see the retention policy and lock status. Verification ensures the policy is correctly applied before proceeding to lock it.
Lock the Retention Policy
Once you are certain the retention period is correct, lock the policy using `gsutil retention lock gs://my-bucket`. This command is irreversible. After locking, the retention period cannot be reduced or removed; it can only be increased (extended). The lock applies to the entire bucket. The command will prompt for confirmation (unless the -q flag is used). Once confirmed, the bucket's retention policy is locked permanently. Any future attempt to decrease the retention period or remove the policy will fail with an error.
Confirm Lock Status
After locking, verify that the policy is indeed locked by running `gsutil retention get gs://my-bucket` again. The output should show `locked: true` along with the retention duration. You can also check via the Console under 'Protection tools' where the lock status is displayed. This step is critical because once locked, there is no going back. If the lock status is not confirmed, you might mistakenly believe the policy is immutable when it is not.
Test Retention Enforcement
To validate that the retention policy is enforced, attempt to delete an object that was just uploaded (or one that is newer than the retention period). Use `gsutil rm gs://my-bucket/object-name`. The command should fail with an error message similar to: 'The object is under retention policy and cannot be deleted or overwritten.' Also test overwriting: `gsutil cp new-file gs://my-bucket/object-name` should also fail. This confirms that both deletion and overwrite are blocked. Note that reading the object is still allowed.
Extend Retention Period (If Needed)
If the retention period needs to be increased after locking, you can do so by setting a new, longer period. Use `gsutil retention set <longer-duration> gs://my-bucket`. The duration must be greater than or equal to the current locked period. It cannot be decreased. For example, if the locked period is 365 days, you can set it to 400 days but not to 300 days. The extension applies to all objects, even those created before the extension. This is useful for extending compliance deadlines.
Enterprise Scenario 1: Financial Services Compliance
A bank must retain all transaction records for 7 years under SEC Rule 17a-4. The bank uses Cloud Storage buckets to store transaction logs. The compliance team sets a retention policy of 7 years (2555 days) on the bucket. However, they are concerned that a disgruntled administrator might delete the bucket or reduce the retention period. To prevent this, they apply a retention lock immediately after setting the policy. Once locked, even the project owner cannot shorten the retention period or delete the bucket. The bank also sets up lifecycle rules to move older objects to Nearline and Coldline storage classes to save costs, but the retention policy prevents deletion. The bank tests that lifecycle deletion actions are deferred if objects are still within the 7-year retention window. In production, the bucket holds millions of objects; performance is not impacted because retention checks are lightweight and server-side. A common misconfiguration is forgetting to lock the policy, leaving it vulnerable to accidental reduction. The bank uses Cloud Audit Logs to monitor any attempts to modify the retention policy (which would fail after locking).
Enterprise Scenario 2: Healthcare Data Retention
A healthcare provider stores patient records in Cloud Storage and must comply with HIPAA, which requires retaining medical records for at least 6 years. The provider sets a retention policy of 6 years on the bucket. However, they also need the ability to place temporary holds on specific records under litigation (legal hold). They use object holds (temporary hold) on those specific objects. The retention policy and object holds work together: the object cannot be deleted until both the 6-year retention period has passed AND the temporary hold is removed. The provider uses event-based holds for records that are automatically released when a patient's treatment ends. A key challenge is managing the interaction: if a temporary hold is forgotten, the object remains undeletable indefinitely. The provider uses Cloud Functions to automatically remove temporary holds after a court case concludes. They also use lifecycle rules to delete objects after the retention period plus an additional 30 days, but they must ensure the lifecycle rule's delete action is deferred if a hold is still active.
Enterprise Scenario 3: Media Archival
A media company archives raw footage for 10 years. They set a retention policy of 10 years on the bucket. They do not lock the policy because they occasionally need to delete defective footage earlier (with proper approvals). However, they accidentally set the retention period to 100 years (the maximum) for a test bucket and then locked it. They realized the mistake but could not reduce the period. They had to wait for the bucket to be empty (which would take 100 years) or delete the bucket (which was also blocked because the bucket had a retention lock). They eventually had to contact Google Cloud support to delete the bucket, which required special procedures. This highlights the critical importance of double-checking the retention period before locking. In production, they now use a two-person approval process for locking policies and set up alerts for any changes to retention policies.
What the ACE Exam Tests
The ACE exam (objective 2.2: Planning Solutions - Storage) tests your ability to configure and manage Cloud Storage retention policies and locks. Specific areas include:
- Objective 2.2.1: Differentiate between unlocked and locked retention policies.
- Objective 2.2.2: Understand the effects on object deletion and overwrite.
- Objective 2.2.3: Identify the correct commands (gsutil retention set, lock, get).
- Objective 2.2.4: Know the maximum retention period (100 years).
- Objective 2.2.5: Understand interaction with lifecycle management and object holds.
Common Wrong Answers and Traps
"A locked retention policy can be removed by a project owner." This is false. Once locked, no one (not even the project owner or Google support) can remove or reduce the policy. The only way to remove it is to wait for the retention period to expire and then delete the bucket (if no objects under retention remain).
"Retention policies prevent reading objects." False. Retention policies only prevent deletion and overwrite. Reading is always allowed.
"You can lock a bucket without first setting a retention policy." False. The gsutil retention lock command requires a retention policy to be set on the bucket. If no policy exists, the command fails.
"Lifecycle deletion rules override retention policies." False. Lifecycle actions are subject to retention policies. If a lifecycle rule tries to delete an object under retention, the deletion is deferred until the retention period expires.
"Object holds can replace retention policies." False. They are independent. Both must be satisfied for deletion.
"The retention period is based on the object's last modification time." False. It is based on the object's creation time. The creation time is immutable.
Specific Numbers and Terms to Memorize
Maximum retention period: 3,155,760,000 seconds (100 years).
Minimum retention period: 1 second.
Time suffixes: d (days), m (month = 30 days), y (year = 365 days).
Commands: gsutil retention set, gsutil retention get, gsutil retention lock.
Lock is irreversible.
Lifecycle deletion is deferred, not cancelled.
Edge Cases the Exam Loves
What happens if you lock a bucket with a 0-second retention policy? You cannot set a 0-second policy; minimum is 1 second. But if you set 1 second and lock, objects are effectively protected for only 1 second? No, because the lock prevents reduction, but objects can be deleted after 1 second. This is a trick: the lock does not extend the retention period; it only prevents reduction.
Can you increase the retention period after locking? Yes, you can only increase it. This is a common exam scenario.
What if a lifecycle rule tries to delete an object that is under both a retention policy and an object hold? The deletion is deferred until both conditions are met: retention period expired AND hold removed.
How to Eliminate Wrong Answers
If an answer says "removed" or "reduced" after locking, it's wrong.
If an answer says "read blocked," it's wrong.
If an answer says "lifecycle overrides retention," it's wrong.
If an answer says "lock can be applied without a policy," it's wrong.
Look for keywords: "immutable," "irreversible," "minimum retention period."
Retention policies set a minimum duration for object retention, preventing deletion or overwrite.
Retention lock makes the policy immutable: it cannot be reduced or removed, only increased.
Maximum retention period is 100 years (3,155,760,000 seconds).
Lifecycle deletion actions are deferred, not cancelled, by retention policies.
Object holds and retention policies are independent; both must be satisfied for deletion.
Use `gsutil retention set`, `gsutil retention get`, `gsutil retention lock` commands.
Lock is irreversible; always verify the retention period before locking.
Retention policies do not prevent reading objects.
These come up on the exam all the time. Here's how to tell them apart.
Unlocked Retention Policy
Can be reduced or removed at any time
Does not provide permanent compliance
Suitable for non-critical retention needs
Can be modified without special procedures
Default state after setting a retention policy
Locked Retention Policy
Cannot be reduced or removed (only increased)
Provides immutable compliance guarantee
Required for regulatory compliance (e.g., SEC, HIPAA)
Irreversible; double-check before applying
Must explicitly lock after setting policy
Mistake
A retention lock can be removed by the bucket owner if needed.
Correct
A retention lock is irreversible. Once applied, the retention period cannot be reduced or removed by anyone, including Google Cloud support. The only way to remove the lock is to delete the bucket after the retention period has expired and all objects are deleted.
Mistake
Retention policies prevent objects from being read.
Correct
Retention policies only prevent deletion and overwrite. Objects can always be read, regardless of the retention policy.
Mistake
Lifecycle management deletion rules can bypass retention policies.
Correct
Lifecycle rules are subject to retention policies. If a lifecycle rule attempts to delete an object that is still under retention, the deletion is deferred until the retention period expires. The rule is not cancelled, just delayed.
Mistake
Object holds and retention policies are interchangeable.
Correct
They are independent mechanisms. Object holds are per-object and manually managed; retention policies are bucket-wide and time-based. Both must be satisfied for an object to be deleted.
Mistake
You can lock a bucket without setting a retention policy first.
Correct
The `gsutil retention lock` command requires an existing retention policy on the bucket. If no policy is set, the command fails with an error. You must first set a policy (even if it is a very short duration) before locking.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but only after the retention period has expired for all objects in the bucket. If any object is still within the retention period, the bucket cannot be deleted. Once the retention period has passed and all objects are deleted, the bucket can be deleted. However, if the bucket is empty, you can delete it immediately even with a locked policy, because there are no objects under retention.
The retention policy applies to all objects in the bucket, including existing ones. The retention period is calculated from the creation time of each object. So if an object was created 100 days ago and you set a 365-day retention policy, that object must be retained for an additional 265 days (365 - 100).
Yes, changing the storage class (e.g., from Standard to Nearline) is allowed during the retention period because it does not delete or overwrite the object. The retention policy only blocks deletion and overwrite.
Retention policies apply to each version of an object independently. If versioning is enabled, each version has its own creation time. A non-current version cannot be deleted if it is still under the retention period. However, you can delete a non-current version if its retention period has expired, even if the current version is still under retention.
A retention policy is a bucket-wide setting that enforces a time-based retention for all objects. A temporary hold is a per-object setting that prevents deletion until the hold is manually removed. Both must be satisfied for deletion. Temporary holds are often used for legal holds, while retention policies are for regulatory compliance.
No, once a bucket is locked, you cannot set a new retention policy (because one already exists). You can only increase the existing retention period using `gsutil retention set` with a longer duration.
The Console will display an error message stating that the object cannot be deleted because it is under a retention policy. The delete button may be grayed out or show a tooltip explaining the restriction.
You've just covered Cloud Storage Retention Policies and Locks — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?