ExamFinch.com My Study

Study guide

12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies

Practice this exam

Google Cloud Associate Cloud Engineer ACE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan

2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity

2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups

3 Chapter 3: APIs, Quotas & Billing Configuration

3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts

4 Chapter 4: Planning Compute & Storage Resources

4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types

5 Chapter 5: Planning Network Resources

5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard

6 Chapter 6: Deploying Compute Engine Workloads

6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration

7 Chapter 7: Deploying Google Kubernetes Engine Workloads

7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE

8 Chapter 8: Deploying Serverless & Event-Driven Applications

8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

9 Chapter 9: Deploying Data Solutions

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud

10 Chapter 10: Deploying Networking Resources & Infrastructure as Code

10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

11 Chapter 11: Managing Compute Engine & GKE in Production

11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE

12 Chapter 12: Managing Cloud Run, Storage & Database Operations

12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)

13 Chapter 13: Networking Operations, Monitoring & Logging

13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

14 Chapter 14: IAM Policies & Role Types

14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles

15 Chapter 15: Service Accounts & Security Configuration

15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials

16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy

16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist

12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies

Key Takeaways Explain This Topic AI

Uniform bucket-level access (IAM-only) is the recommended default; enabling it disables legacy per-object ACLs entirely for that bucket.

Signed URLs grant time-boxed access to a single object for identities outside Google Cloud, capped at 7 days (604,800 seconds) under V4 signing.

A lifecycle rule pairs AND-combined conditions (age, matchesStorageClass, numNewerVersions, and others) with one action: Delete, SetStorageClass, or AbortIncompleteMultipartUpload.

Nearline/Coldline/Archive carry 30/90/365-day minimum storage durations; moving or deleting an object early still bills the remainder.

Retention policies (Bucket Lock) and object holds prevent early deletion; lifecycle rules cause eventual deletion — compliance setups typically combine both.

Last updated: July 2026

Why This Matters for the ACE Exam

Domain 4 of the official exam guide lists two Cloud Storage bullets under "Ensuring successful operation of a cloud solution": managing and securing objects, and setting object lifecycle management policies. Chapter 4 covered choosing a storage class; this section covers what happens after data lands in a bucket — who is allowed to touch it, how to share a single file without opening the whole bucket, and how to make aging data cheaper automatically instead of manually re-uploading it every few months.

Access Control: IAM, ACLs, and Signed URLs

Cloud Storage supports two overlapping access-control systems, plus a bridge mechanism for external sharing:

Uniform bucket-level access — the recommended default. Once enabled on a bucket, only IAM policies grant access; legacy per-object ACLs stop applying entirely, and any attempt to set or read an ACL on that bucket or its objects fails.

Fine-grained access — the older model, where per-object access control lists (ACLs, using roles like READER and OWNER ) work alongside IAM. This is only available when uniform bucket-level access is not enabled.

Signed URLs — a way to grant time-boxed access to one specific object to a party who has no Google Cloud identity at all (a customer downloading an invoice, for example). A signed URL is neither an IAM grant nor an ACL; it is a cryptographically signed link with a built-in expiration.

  • IAM role Permission level
  • roles/storage.admin Full control of buckets and objects
  • roles/storage.objectAdmin Full control of objects only (create, read, delete, list)
  • roles/storage.objectCreator Upload-only — cannot read or delete existing objects
  • roles/storage.objectViewer Read-only access to objects

For signed URLs , the current V4 signing scheme allows a maximum expiration of 604,800 seconds — 7 days — because the signing mechanism itself is only valid for that long. In practice, best practice is to use a far shorter window than the maximum: minutes for a one-time upload link, an hour or less for a download link, and never the full 7 days for anything sensitive.

Object Lifecycle Management

A lifecycle configuration is a set of independent rules attached to a bucket. Each rule pairs one or more conditions (combined with AND logic — every condition in the rule must match) with exactly one action . Multiple rules on the same bucket are evaluated independently (effectively OR'd), so a bucket commonly has several rules working together to build a full aging pipeline.

  • Condition Meaning
  • age Object has existed for N days since creation
  • createdBefore Object was created before a specific date
  • customTimeBefore / daysSinceCustomTime Based on a user-set Custom-Time metadata value
  • isLive True for the current (live) version, false for noncurrent versions
  • matchesStorageClass Object is currently in a specified storage class
  • matchesPrefix / matchesSuffix Object name matches a prefix or suffix pattern
  • noncurrentTimeBefore / daysSinceNoncurrentTime Based on when a versioned object became noncurrent
  • numNewerVersions At least N newer versions exist (requires object versioning)
  • Action Effect
  • Delete Removes the object (subject to any active retention policy or hold)
  • SetStorageClass Transitions the object to a cheaper (or different) storage class

AbortIncompleteMultipartUpload Cancels stalled uploads; only usable with age , matchesPrefix , or matchesSuffix

Two operational facts matter for scenario questions: Cloud Storage evaluates rules regularly rather than instantly, so a lifecycle configuration change can take up to 24 hours to take effect , and even once effective, the action itself runs asynchronously — there can be a lag between the moment an object meets a condition and the moment the action fires.

Storage Class Minimums and Cost

Each non-Standard class carries a minimum storage duration ; deleting or transitioning an object out early still bills for the remaining minimum period as an early-deletion charge.

  • Class Minimum storage duration
  • Standard None
  • Nearline 30 days
  • Coldline 90 days
  • Archive 365 days
  • A typical exam-style lifecycle policy tiers objects down automatically as they age: {
  • "rule": [
  • { "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
  • "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]} },
  • { "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
  • "condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]} },
  • { "action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
  • "condition": {"age": 365, "matchesStorageClass": ["COLDLINE"]} },
  • { "action": {"type": "Delete"},
  • "condition": {"age": 2555} }
  • ]
  • }

Here the matchesStorageClass condition is essential — without it, an object already in Archive would keep re-matching the age: 30 rule and be pushed back down to Nearline.

Retention Policies and Holds: Not the Same as Lifecycle

A lifecycle policy eventually deletes data; a retention policy (Bucket Lock) does the opposite — it prevents deletion or overwriting of any object in the bucket until a configured retention period elapses, even by a project owner. Object holds (temporary or event-based) block deletion of a specific object regardless of any lifecycle rule, until the hold is explicitly released. Compliance scenarios often combine both: a retention policy guarantees data isn't deleted too early , while a lifecycle rule guarantees it eventually is deleted once the requirement expires.

Common Traps

Enabling uniform bucket-level access and then trying to run an ACL command against that bucket — it fails, because ACLs are disabled entirely, not merged with IAM.

Assuming a lifecycle action fires the instant a condition is met — configuration changes take up to 24 hours to activate, and actions run asynchronously afterward.

Forgetting that versioning-related conditions ( numNewerVersions , isLive , noncurrentTimeBefore ) only do anything on a bucket with object versioning enabled.

Treating a signed URL as equivalent to an IAM grant — it is a separate, time-limited mechanism capped at 7 days for external, identity-less sharing.

Key Takeaways

Uniform bucket-level access (IAM-only) is the recommended default; enabling it disables legacy ACLs entirely for that bucket.

Signed URLs grant time-boxed access to a single object for non-Google-Cloud identities and cap out at 7 days under V4 signing.

A lifecycle rule = conditions (AND) + one action ( Delete , SetStorageClass , or AbortIncompleteMultipartUpload ); rules on a bucket act independently.

Nearline/Coldline/Archive carry 30/90/365-day minimum storage durations; deleting early still bills the remainder.

Retention policies and holds prevent early deletion; lifecycle rules cause eventual deletion — compliance setups typically use both together.