Prepare and test your skills
Prepare and test your skills
Google Cloud Storage classes separate object data by how often it is accessed and how long it must be kept. Cloud Storage provides Standard, Nearline, Coldline, and Archive storage, ordered from warmest to coldest. Autoclass (opens in a new tab) follows this same progression by moving unaccessed objects to colder classes to lower storage cost and by moving accessed objects back to Standard storage to optimize future accesses.
The four Cloud Storage classes form a progression from frequently accessed data to long-term retention data. Standard storage is the entry point for new and active data, Nearline storage is the next colder step, and Coldline storage and Archive storage are the coldest options for data that is seldom read. The four classes differ by access suitability and by cost and retention role:
| Storage class | Access suitability | Cost and retention role |
|---|---|---|
| Standard | Frequently accessed data | Higher storage cost, optimized for repeated reads; 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 storage class increases cost. The Storage Intelligence advisor (opens in a new tab) reports a Spike in Class A or B operations on Coldline or Archive data when Coldline storage or Archive storage is read frequently. Data with that pattern is better suited for Standard storage 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 behavior follows three consistent rules that control how objects cool and warm:
By default, the terminal storage class for Autoclass is Nearline storage, so objects cool to Nearline storage and stay there until accessed. The terminal storage class can optionally be configured to Archive storage for longer retention with colder storage. Reading or editing only object metadata does not cause a transition to Standard storage; only reading object data promotes the object.
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.
Lifecycle pressure also affects cost when old versions are kept too long. Retaining noncurrent object versions indefinitely increases total bytes stored above trend and creates unnecessary storage cost. Object Lifecycle Management resolves this by deleting noncurrent versions or moving them to colder storage, while Autoclass can automatically manage classes from access patterns. Under Autoclass pricing, all operations are charged at the Standard storage rate, transitions to colder classes have no operation charge, and transitions from Coldline storage or Archive storage back to Standard storage or Nearline storage each incur a Class A operation charge.
Assessing data access patterns means measuring how often data is read and how quickly it must be returned when requested. Frequent, latency-sensitive data belongs in a hot tier, while rarely read data belongs in a cold tier. This assessment lets you match each dataset to the storage option with the right balance of cost and access requirements.
Hot and cold data tiers are two storage locations for the same volume that differ by access frequency and retrieval speed. Data starts in the hot tier and data flows from the hot tier to the cold tier after it has not been accessed for a set period. Data can also flow back from the cold tier to the hot tier when it is read again. The two tiers differ across price and performance:
| Tier | Price | Access speed |
|---|---|---|
| Hot tier | Higher price per stored byte | Faster access, supports full volume performance |
| Cold tier | Lower price per stored byte | Slower access, with higher latency and reduced throughput |
Because the cold tier is cheaper but slower, frequently accessed data should stay hot and infrequently accessed data should cool. Moving data between tiers also has network transfer costs, so frequent moves add cost.
The cooling threshold in NetApp Volumes is the number of days without access before data moves from the hot tier to the cold tier. The default cooling threshold value is 31 days. A shorter threshold moves data to the cold tier sooner, while a longer threshold keeps data in the hot tier longer. A threshold that is too short creates three related problems:
Choose a threshold that reflects real use: set a short threshold only when data truly becomes cold quickly, and keep a longer threshold when data is re-read within weeks.
Exam tip: The default cooling threshold is 31 days; shorter is not always cheaper because transfer costs and slower access can outweigh cold-tier savings.
Monitoring data in Google Cloud shows where bytes actually sit and how usage changes over time. Cloud Monitoring collects resource usage and Recommender, formerly Active Assist, highlights opportunities to right-size resources based on actual demand. For tiered volumes, tiering statistics show current hot-tier data and current cold-tier data, so you can see whether a dataset behaves as hot, cooling, or cold. Look up the tiering statistics of a volume in the Google Cloud console:
If most bytes stay in the hot tier, the data has a hot access pattern and needs fast retrieval. If most bytes settle in the cold tier, the data has a cold access pattern and can accept slower retrieval for lower storage cost.
Object Lifecycle Management (OLM) in Cloud Storage (opens in a new tab) automatically manages objects over time to control cost, availability, and compliance. OLM rules can move data between storage classes as access frequency drops or delete objects and noncurrent versions when retention requirements end. Retention policies and holds add minimum storage durations and immutability so regulated data cannot be deleted or replaced too early.
Object Lifecycle Management is the Cloud Storage feature that automatically applies actions to objects without manual moves. A lifecycle configuration on a bucket watches objects and then deletes them or moves them to colder storage when conditions are met. A common use is cleaning up versioned data, such as deleting noncurrent object versions that would otherwise be retained indefinitely and increase storage consumption. Use OLM when storage grows above trend because old versions or aging data are kept in a warmer, more expensive class than needed.
Autoclass is a bucket setting in Cloud Storage that automatically manages storage classes based on access patterns. When Autoclass is enabled on a bucket, objects in the bucket other than soft-deleted objects transition to Standard storage, and legacy storage classes are treated as different from Standard storage. This automatic reset means enabling Autoclass changes the starting point before access-based transitions continue. Choose Autoclass when access patterns change over time and manual rule updates would be impractical, and use Storage Transfer to move data out of legacy classes such as Durable Reduced Availability (DRA), which has lower performance with a 99% availability SLA.
Storage Intelligence advisor (opens in a new tab) is a Cloud Storage monitoring view that reports metrics, findings, and next steps across projects, folders, and organizations. Metrics are collected data points such as storage volume and object counts, findings are detected anomalies that need attention, and next steps are recommendations for fixing each finding. The At a glance view gives a daily snapshot of total storage size, total buckets with objects, total objects, and average object size for the selected scope. Top findings fall into usage optimization, which affects cost efficiency, and performance, which affects speed and operational health:
| Finding | Category | Action it points to |
|---|---|---|
| Spike in Class A or B operations on Coldline or Archive data | Usage optimization | Move frequently accessed data from Coldline storage or Archive storage to Standard storage or Nearline storage, or use cached data |
| Total bytes stored increased above trend over 30 days | Usage optimization | Use Object Lifecycle Management to delete noncurrent versions or move them to colder storage, or enable Autoclass |
| Spike in cross-region egress | Usage optimization | Colocate compute and storage in the same region by relocating the bucket |
| Spike in 429 errors for rate-limited requests | Performance | Add exponential backoff and ramp request throughput gradually |
Findings flow from the advisor to an action in Cloud Storage, such as changing a storage class, relocating a bucket, or adding an OLM rule.
Exam tip: Frequent operations on Coldline storage or Archive storage means the data is too cold for its access pattern — move that data to Standard storage or Nearline storage.
Retention controls in Cloud Storage enforce minimum storage durations and data immutability for compliance and regulatory obligations. A retention policy applies to a bucket and prevents objects from being deleted or replaced until the required duration passes, while a hold keeps an individual object immutable until the hold is released. The lifecycle flow therefore has an order: first retention and holds block early deletion, then OLM deletes or transitions the object only after the protection ends. Choose retention and holds when data must be provably unchanged for a set period, and choose OLM transitions and deletions to optimize cost after that period.
Storage class selection connects access measurement, automatic tiering, and enforced retention into one flow. Access frequency decides whether data belongs in Standard, Nearline, Coldline, or Archive storage, monitoring confirms where hot and cold bytes actually sit, and Autoclass and Object Lifecycle Management move aging data colder while retention policies and holds block early deletion until compliance ends.
Cloud Storage provides Standard, Nearline, Coldline, and Archive storage ordered from warmest to coldest by access frequency and retention need. Standard storage is for frequently accessed data with higher storage cost optimized for repeated reads, Nearline storage is for infrequently accessed data with lower storage cost than Standard, Coldline storage is colder than Nearline for rarely accessed data, and Archive storage is the coldest option for rarely accessed long-term retention data where frequent reads create excess Class A or B operation costs.
Autoclass starts all new objects in Standard storage, cools unaccessed objects to progressively colder classes ending at a terminal class that defaults to Nearline storage and can optionally be configured to Archive storage, and promotes an object back to Standard storage when its data is read. Objects smaller than 128 KiB remain permanently in Standard storage and reading or editing only object metadata does not cause a transition to Standard storage.
Use Object Lifecycle Management to automatically delete objects and noncurrent versions or move them to colder storage when retention requirements end, and use retention policies and holds when data must be provably unchanged for a set period. A retention policy applies to a bucket and prevents objects from being deleted or replaced until the required duration passes while a hold keeps an individual object immutable until the hold is released, and Object Lifecycle Management deletes or transitions the object only after that protection ends.
The cooling threshold in NetApp Volumes is the number of days without access before data moves from the hot tier to the cold tier and its default value is 31 days. Set a short threshold only when data truly becomes cold quickly and keep a longer threshold when data is re-read within weeks, because a threshold that is too short limits cost savings, serves still-needed data from the slower cold tier, and increases transfer costs from more frequent movement between tiers.
A data analytics team stores reporting archives in a Cloud Storage bucket using the Standard storage class. The team identifies that reports are accessed frequently during the first 90 days after creation, but access drops significantly after this period.
To optimize storage costs, the team needs to automatically move reports older than 90 days to the Nearline storage class. Additionally, to avoid Class A transition operation charges outweighing storage savings on small files, only objects larger than 5 MiB (5,242,880 bytes) should be transitioned.
Which Object Lifecycle Management configuration should you implement on the bucket?
Last updated