Prepare and test your skills
Prepare and test your skills
Determining the appropriate storage class means matching how often data is read and how long it must be kept to the lowest-cost class that still meets access needs. Cloud Storage (opens in a new tab) provides Standard, Nearline, Coldline, and Archive storage, ordered from warmest to coldest. Access measurement, automatic tiering, and retention rules work together so frequently read data stays fast and rarely read data stays cheap.
Storage class options in Cloud Storage form a progression from active data to long-term retention data. All new objects start in Standard storage, which is optimized for repeated reads. Nearline storage is the next colder step for infrequently accessed data, while Coldline storage and Archive storage are the coldest options for rarely accessed data. The four classes differ by access fit and cost role:
| Storage class | Access suitability | Cost and retention role |
|---|---|---|
| Standard | Frequently accessed data | Higher storage cost; starting point for all Autoclass objects |
| Nearline | Infrequently accessed data | Lower storage cost than Standard; default terminal class where Autoclass objects rest until read |
| Coldline | Rarely accessed data | Colder than Nearline; frequent reads create excess Class A or B operation costs |
| Archive | Rarely accessed long-term retention data | Coldest option; frequent reads create excess Class A or B operation costs |
A mismatch between access frequency and class increases cost. The Storage Intelligence advisor reports a Spike in Class A or B operations on Coldline or Archive data when cold data is read frequently, which means the data belongs in Standard or Nearline storage.
Exam tip: Frequent reads from Coldline or Archive storage indicate the data belongs in Standard or Nearline storage, not in a colder class.
Autoclass in Cloud Storage automatically manages the storage class of each object in a bucket based on access patterns. Autoclass follows three consistent rules that control how objects cool and warm:
By default the terminal storage class is Nearline storage, so objects cool to Nearline and stay there until accessed. The terminal class can optionally be configured to Archive storage for longer retention with colder storage. Reading or editing only object metadata does not promote the object; only reading object data moves it back to Standard storage.
Retention and size rules in Cloud Storage control how long objects stay in colder classes and when they should be removed. Objects smaller than 128 KiB do not transition to colder classes and remain permanently in Standard storage, with only object data counted toward that size limit. Soft-deleted objects retain their existing storage classes until the end of their retention duration, while a restored object begins again in Standard storage regardless of its prior class. Retaining noncurrent versions indefinitely increases total bytes stored above trend, so Object Lifecycle Management deletes noncurrent versions or moves them to colder storage.
Monitoring confirms whether data behaves as hot or cold. Cloud Monitoring collects resource usage and Recommender highlights opportunities to right-size resources, while tiering statistics show current hot-tier data and current cold-tier data. For tiered volumes, data flows from the hot tier to the cold tier after it has not been accessed for a set period, and data can flow back from the cold tier to the hot tier when it is read again. To review tiering statistics in the Google Cloud console:
The cooling threshold in NetApp Volumes is the number of days without access before data moves from the hot tier to the cold tier, with a default of 31 days. A threshold that is too short limits savings, serves still-needed data from the slower cold tier, and increases transfer costs from frequent moves between tiers.
Configuring deletion rules means creating automatic expiration policies that remove data after a set period to lower cost and enforce retention. Cloud Storage (opens in a new tab) uses Object Lifecycle Management to delete objects based on conditions, while BigQuery (opens in a new tab) uses table and partition expiration to remove structured data. The policy applies to the container, either the bucket or the table, and the service performs deletion without manual cleanup jobs.
Lifecycle rules in Cloud Storage are automatic bucket rules that move or delete objects after a set period. The Cloud Storage service watches object age and other object properties, then moves the object to a lower-cost class or deletes the object when the condition is met. Because the service evaluates the rule continuously, cost control does not depend on a person remembering to delete files. Lifecycle rules are best when data has a known useful lifetime, such as temporary load files or backups kept for a fixed period.
Cloud Storage is the staging layer that feeds BigQuery, and data flows from the source environment to a Cloud Storage bucket and then from the bucket into BigQuery:
Cloud Storage commonly holds staging files for loads, external data referenced by external tables, and export files written from BigQuery for backup. Because external tables and exports depend on the bucket, the bucket lifecycle rule directly affects whether BigQuery can still read that data. Safe cleanup depends on location and permissions: create the bucket closest to the data source and when possible in the same location as the BigQuery dataset, and grant the transfer identity storage.objects.get, storage.objects.list, and storage.objects.delete.
Exam tip: A transfer can delete source files from Cloud Storage after success only when the identity also has storage.objects.delete; without that permission, files remain and continue to incur storage costs.
Granular expiration removes targeted data subsets instead of deleting whole tables or buckets. BigQuery table expiration is metadata stored with each table and configurable when the table is created, and the data retention policy for a table is determined by the configuration of the dataset that contains the table. Partition-level expiration removes only the targeted subset, which lowers storage cost without affecting recent partitions. Teams often pair expiration with aggregation, where detailed rows are summarized into smaller metrics tables and then row-level data is expired.
Cloud Storage object versioning keeps a live version and older archived versions of the same object in the same bucket. BigQuery load jobs and the BigQuery Data Transfer Service work only with live objects, so including a generation number in the Cloud Storage URI causes the load job to fail. Metadata caching for BigLake and object tables also follows the live version boundary, so queries that use the cache read data for the cached version even if a newer version becomes live afterward. Accessing the newer version requires a metadata cache refresh.
Time travel and fail-safe provide two ordered retention stages after deletion in BigQuery. Data that is replaced or removed first enters the time travel window, where it remains queryable and recoverable, and then enters the fail-safe period for emergency recovery only. The time travel window can be configured to balance cost with retention needs, while the fail-safe period is a fixed seven days and cannot be configured or extended. Data in fail-safe storage cannot be queried directly, and recovery from fail-safe requires contacting Cloud Customer Care for table-level recovery.
Deletion methods in Cloud Storage fall into two categories chosen by object count and workflow need. Traffic flows from the chosen tool to the bucket, and the bucket depends on the deletion request to change object state from stored to deleted.
| Method | Scope | Choose when |
|---|---|---|
| Single-object deletion | One object per DELETE request | Correcting an error, cleaning up a temporary file, handling an application event such as a deleted profile photo, or removing sensitive data |
| Bulk object deletion | Many objects with higher throughput | Removing old logs, enforcing a 30-day retention period, clearing a bucket for migration, or cleaning up pipeline intermediates |
Manual tools require a person or application to start each deletion, while lifecycle policies let the Cloud Storage service evaluate and delete without further action. Single-object deletion can be performed with the Google Cloud console, gcloud storage rm, client libraries in Python, Java, Go, and Node.js, and REST APIs using the JSON API or XML API. Manual bulk options include console deletion of up to one million objects in the background, gcloud storage rm --recursive for small-to-medium deletions by prefix, multi-object delete XML API for up to 1,000 objects in a single POST, and storage batch operations for millions or billions of objects asynchronously.
For versioned buckets, lifecycle conditions must distinguish between states so the policy does not delete active data. Configure deletion rules with the isLive condition set to False so the rule applies only to noncurrent versions. This boundary keeps the live object on one side and expired history on the other, allowing teams to keep current data while automatically removing old versions.
Evaluating archiving services means matching business needs for cost, access frequency, and compliance to the right storage class and lifecycle approach. Cloud Storage (opens in a new tab) is the central object storage service for storing and preserving long-term archival data on highly redundant infrastructure. Location, encryption, and access controls work with storage to meet requirements for durability and regulatory compliance.
Object Lifecycle Management policies in Cloud Storage are automatic rules that manage stored objects over time to lower cost and meet retention needs. A policy watches the objects in a bucket and takes an action when its conditions are met. The two main actions are transitioning an object to a colder storage class and deleting an object. Conditions based on age and current storage class let data start in active storage and move to cheaper archive storage as it gets older.
Storage classes (opens in a new tab) serve as both a condition and a destination, so an object stored as Standard can later move to Nearline, Coldline, or Archive for long-term archiving. Standard storage is for high-frequency access, Nearline and Coldline storage are for low-frequency access, and Archive storage is for lowest-frequency access. Nearline fits backup scenarios where data is read at most about once a month, such as regular recovery testing. A rule can move 90-day-old Standard objects to Nearline and later move older Nearline objects to Archive, then delete objects after the required retention period ends.
Protection features control what happens when lifecycle actions, users, or errors delete or overwrite objects. The Soft Delete feature preserves deleted and overwritten objects for a specified period, so data remains recoverable after accidental deletion. The Object holds feature prevents deletion or updates to an object while a hold is in place, which supports strict retention and regulatory needs.
Exam tip: Nearline, Coldline, and Archive storage have lower storage rates but add retrieval charges and minimum storage duration charges, so early retrieval or deletion still incurs a cost.
Business requirements for archive storage are the needs that must be checked before selecting a storage class and lifecycle policy. This evaluation connects the business need to the storage choice, so infrequently accessed or regulated data is kept in a suitable and cost-effective place. Three requirements shape the decision:
When these three requirements are understood together, the archive design can select the right class and policy. Data that is rarely accessed and kept mainly for compliance fits a lower-cost archival choice, while data that must be accessed more often fits a choice that balances retention cost with retrieval needs.
Redundant infrastructure is the platform design that keeps archived data safe from hardware, software, and network failures. Redundancy applies across every layer of the platform, with backup server capacity, copies of stored data, alternate network paths, and software exception handling that shifts control planes swiftly from one facility to another. Data centers are geographically distributed to reduce the impact of natural disasters or local outages, and customers can deploy resources across multiple regions and zones for resilience.
Location and boundary controls determine where archived data can be stored and moved. Customers select the region when they create a resource, such as us-east1 or europe-west1, or use multi-regions such as asia and europe. The resource locations constraint can allow or deny those locations at the organization, project, or folder level, which enforces data residency. VPC Service Controls creates a service perimeter that defines the virtual boundaries from which a service can be accessed, and it can restrict import and export through storage APIs so data stays within selected network locations.
Encryption and access protection keep archived data confidential and visible only to approved users. Google Cloud services encrypt customer content at rest and in transit automatically, with no customer action required. Organizations with sensitive data can add customer-managed encryption keys (CMEK) and manage those keys with Cloud Key Management Service (Cloud KMS), store them in a hardware security module with Cloud HSM, or keep them outside Google infrastructure with Cloud External Key Manager (Cloud EKM). Access Approval requires explicit approval before Google personnel access data, while Access Transparency creates near-real-time audit logs that record office location and reason for access.
isLive condition to False so only noncurrent versions are deleted and live data is preserved.Use Standard storage in Cloud Storage for frequently accessed data, Nearline storage for infrequently accessed data, Coldline storage for rarely accessed data, and Archive storage for rarely accessed long-term retention data. All new objects start in Standard storage, and frequent reads from Coldline or Archive storage create excess Class A or B operation costs, which means the data belongs in Standard or Nearline storage.
Autoclass in Cloud Storage starts all new objects in Standard storage and cools unaccessed objects to progressively colder classes ending at the terminal storage class, which defaults to Nearline storage. An object whose data is read transitions back to Standard storage if it is not already there, while reading or editing only object metadata does not promote the object.
Data that is replaced or removed in BigQuery first enters the time travel window, where it remains queryable and recoverable, and then enters the fail-safe period for emergency recovery only. The time travel window can be configured to balance cost with retention needs, while the fail-safe period is a fixed seven days and cannot be configured or extended. Data in fail-safe storage cannot be queried directly, and recovery from fail-safe requires contacting Cloud Customer Care for table-level recovery.
Last updated