Prepare and test your skills
Prepare and test your skills
Storage Class Selection and Data Lifecycle Management is the practice of matching each object in Cloud Storage to the lowest-cost tier that still meets its access needs. Standard storage and Nearline storage are intended for frequent access, while Coldline storage and Archive storage are intended for infrequent and rare access. Storage Intelligence advisor (opens in a new tab) detects misalignment, Object Lifecycle Management applies administrator-defined transition and deletion rules, and Autoclass automatically adjusts classes based on observed use.
Analyzing access patterns means comparing how often data is read and written against the storage class it sits in. Storage Intelligence advisor surfaces a Spike in Class A or B operations on Coldline or Archive data finding when data in cold tiers behaves like hot data. That pattern means the workload is paying frequent operation costs for a tier designed for rare access, so the fix is to move the data up to Standard storage or Nearline storage.
| Storage class | Intended access frequency | Signal the class is too cold |
|---|---|---|
| Standard storage | Frequent access | Rarely wrong for hot data, but expensive for rarely used objects |
| Nearline storage | Frequent but less continuous access than Standard | Consider Standard storage if Class A or B operations stay consistently high |
| Coldline storage | Infrequent access | Spike in Class A or B operations means move to Standard storage or Nearline storage |
| Archive storage | Rare access | Spike in Class A or B operations means move to Standard storage or Nearline storage |
Data flows from applications to the bucket in its current class, and every read or write in the wrong class can increase operation cost and latency. Location is a second selection rule because traffic between regions is billed as egress. When a Compute Engine instance in us-central1 frequently accesses a bucket in us-east1, the fix is to colocate compute and storage in the same region using bucket relocation.
Exam tip: A spike in Class A or B operations on Coldline or Archive data means move the data up to Standard or Nearline, not down to a colder tier.
Object Lifecycle Management is the policy engine that automatically moves objects to colder storage or deletes them when age, version state, or other conditions are met. A common trigger is the Total bytes stored increased above trend over the last 30 days finding, which means storage consumption has grown beyond history. For example, a bucket may keep noncurrent object versions indefinitely after new versions are uploaded, so Object Lifecycle Management can delete those old versions or move them to a colder class.
Autoclass is the automatic alternative that manages storage classes for a bucket based on access patterns without manual rules. When access frequency drops, Autoclass transitions objects to lower-cost tiers on its own, and when access rises it keeps data in a tier suited for frequent use. Object Lifecycle Management depends on administrator-defined conditions and applies to objects in its attached bucket, while Autoclass depends on observed access and applies continuously. Choose Object Lifecycle Management when retention, version cleanup, and colder-tier moves must follow business rules, and choose Autoclass when per-object access is unpredictable.
Storage Intelligence advisor is the central monitoring interface for Cloud Storage across a project, folder, or organization. The advisor works without custom data pipelines, BigQuery scripts, or manual log queries. Two time-series charts show where growth is happening: Cumulative object count tracks total object count, and Storage volume over time tracks stored bytes across locations and storage classes.
Cost and reliability signals flow from storage activity into advisor findings that point to a specific fix:
Project-level resources inside a VPC Service Controls (VPC SC) service perimeter retain perimeter protection for the advisor API, while folder-level and organization-level management relies on Identity and Access Management (IAM). Oversight can therefore stay centralized across the hierarchy even when network protection applies only at the project level.
Cost Monitoring and Architectural Efficiency is the practice of tracking cloud spending in detail and designing applications so they use only the resources they need. In Google Cloud, this balance rests on cost optimization (opens in a new tab) through three goals: Efficiency through automation and data analysis, Performance by scaling to meet demand, and Scalability to handle growth. Monitoring tools reveal waste and spending patterns, while right-sizing, autoscaling, and careful placement of resources prevent waste from recurring.
Right-sizing means continuously matching resource allocation to actual demand. Over-provisioning creates unnecessary cost, while under-provisioning creates bottlenecks that hurt user experience. Cloud Monitoring provides real-time visibility into utilization metrics such as CPU and memory, which lets teams track usage patterns and spot inefficiencies. Recommender, delivered as Active Assist, analyzes that utilization data at no cost and produces idle VM recommendations and machine-type recommendations for Compute Engine. Teams can extend this loop with custom metrics for application-specific behavior and alerts that notify administrators when thresholds are met.
Cloud Billing is the collection of tools that tracks current and projected spending, including reports, invoices, cost breakdowns, and exports for deeper analysis. Cloud Billing reports and the FinOps hub give finance teams and auditors a unified view of spend by service, project, or cost center. For granular analysis, billing data can be exported to BigQuery, where custom queries aggregate cost by label, project, or time period and surface anomalies. Raw spending data becomes decisions through an ordered refinement flow:
us-central1 for USD 70.Tags and labels are key-value pairs attached to resources such as projects or departments that make this attribution possible. By applying consistent labels like team, environment, or product and enforcing them with automation such as Terraform, teams can break down costs by label, perform chargebacks and audits, and build custom dashboards that track key performance indicators (KPIs).
Cost allocation and budgeting create accountability by assigning every dollar of spend to the team, project, or individual that caused it. When costs flow from shared billing accounts to specific owners through labels, hierarchy, and chargeback mechanisms, each owner has an incentive to manage resources responsibly. Cloud Billing budgets and alerts support this control by defining spending limits for teams or projects and sending notifications when actual spend approaches or exceeds those limits. Regular review of billing reports, budget alerts, and custom reports lets stakeholders detect variances and take corrective action before significant overruns occur.
Autoscaling adjusts capacity in response to workload fluctuations so applications have resources when needed and release them when demand drops. Compute Engine managed instance groups (MIGs) manage groups of virtual machines (VMs) as a single entity with policies that set minimum and maximum VM counts. The MIG adds VMs when CPU utilization crosses an upper threshold and removes them when it drops below a lower threshold. Google Kubernetes Engine (GKE) autoscaling adjusts cluster resources through four tools that work together:
Cloud Run provides built-in serverless autoscaling where instance count follows incoming traffic. Cloud Run scales up under load and scales down to reduce cost, including scaling to zero when a service receives no traffic. Together these options improve performance during peaks and save cost during idle periods.
Architectural efficiency also means paying the lowest valid rate for needed capacity and minimizing expensive data movement such as inter-region egress. Network traffic between regions is billed as egress, so concentrating closely related resources that exchange data in the same region avoids inter-region charges. Choosing single-region Cloud Storage buckets and single-region or single-zone deployments when workloads do not require multi-region reliability reduces replication costs, while choosing a lower-priced region is valid only when latency and regulatory requirements allow. Regular review of pricing and the Google Cloud Pricing Calculator helps teams decide whether savings from a cheaper region outweigh added egress.
| Option | How the discount works | Choose when |
|---|---|---|
| Committed use discounts (CUDs) | Commit to minimum quantity or spend for one year or three years; resource-based CUDs apply in a specific region and are shared across projects, spend-based CUDs apply at the billing account level | Usage is predictable and steady and can be committed |
| Sustained use discounts | Automatic credits for Compute Engine after continuous use beyond duration thresholds in the billing cycle | Resources run consistently but without a formal commitment |
| Spot VMs | Access unused VM capacity at more than 80% lower cost, but Compute Engine can preemptively stop or delete the VMs to reclaim capacity | Workloads are fault-tolerant, flexible, and can tolerate preemption, such as batch jobs |
Exam tip: Committed use discounts require a one-year or three-year commitment, sustained use discounts apply automatically for continuous use, and Spot VMs offer the deepest discount but can be preempted.
Compute Resource Optimization and Scaling Strategies is the practice of matching Compute Engine capacity to actual workload demand so performance stays steady while idle resources stay low. This work centers on three choices: the Compute Engine (opens in a new tab) machine type that sizes each virtual machine (VM), the provisioning model that prices that VM, and the scaling configuration that adds or removes VMs as traffic changes.
Compute Engine machine type recommendations help align VM size with observed workload needs. The recommendation engine reviews utilization of existing VM instances and suggests a machine type that matches compute requirements, which reduces overprovisioning. For workloads with predictable CPU and memory needs, custom machine types let you specify cores and memory independently instead of accepting a predefined size. This independent sizing is especially useful when licensing costs depend on core count, because you pay for only the cores you need.
Spot VMs are discounted Compute Engine VMs for fault-tolerant workloads that can handle interruptions. Spot VMs offer the same machine types, options, and performance as regular VMs, but at significantly lower cost because Compute Engine can preemptively stop or delete them to reclaim zone capacity. Traffic flows from the managed instance group (MIG) controller to available Spot VMs, so when zone capacity is limited, the MIG depends on spare capacity and might not scale out to its target size until capacity returns. Choose Spot VMs when the application runs in the web or application tiers, runs batch jobs, tolerates preemption, and does not require high availability; keep regular VMs when availability must be assured.
Autoscaling in managed instance groups (MIGs) automatically adjusts VM count to match traffic and minimize idle capacity. When demand rises, the autoscaler creates VMs in the stateless MIG to handle the increase gracefully; when demand falls, the autoscaler deletes VMs so you stop paying for unneeded resources. This capability applies only to stateless MIGs, where any VM can serve any request, and the group depends on identical, replaceable VMs. Stateful MIGs preserve per-VM disks and state, so the autoscaler cannot add or remove them automatically.
Exam tip: Stateless MIGs support autoscaling to reduce idle cost, while stateful MIGs cannot be autoscaled because their disks preserve state.
The compute platform decision balances configuration flexibility against management effort across VMs, containers, and serverless options. Google Kubernetes Engine (GKE) runs containerized applications and automates deploying, scaling, and managing containers, while Cloud Run runs code on a preconfigured serverless platform with minimal infrastructure management. VMs and containers provide more configuration flexibility, but the team remains responsible for managing the resources; serverless shifts that management to the platform so the team focuses on data and applications.
| Platform | Management responsibility | Choose when |
|---|---|---|
| Compute Engine VMs | Team manages VMs, scaling, and patching | The workload needs full OS and infrastructure control |
| Google Kubernetes Engine (GKE) | Team manages clusters, platform automates container deployment and scaling | The workload is containerized and needs orchestration |
| Cloud Run | Platform manages infrastructure | The workload can run on a preconfigured platform with minimal operations |
A reservation complements these choices when assured capacity matters more than elasticity. A Compute Engine reservation holds capacity in a specific zone for a specified number of VMs of a chosen machine type, and the reservation can be specific to one project or shared across multiple projects. Use reservations to guarantee placement for critical VMs, and use Spot VMs plus autoscaling for elastic tiers where cost and scale matter most.
A spike means data in Coldline storage or Archive storage is being accessed frequently and may belong in Standard storage or Nearline storage. Coldline storage is intended for infrequent access and Archive storage is intended for rare access, so the fix is to move the frequently accessed data up to Standard storage or Nearline storage.
Object Lifecycle Management is a policy engine that automatically moves objects to colder storage or deletes them when administrator-defined conditions such as age or version state are met, while Autoclass automatically adjusts storage classes for a bucket based on observed access without manual rules. Choose Object Lifecycle Management when retention, version cleanup, and colder-tier moves must follow business rules, and choose Autoclass when per-object access is unpredictable.
Spot VMs offer more than 80 percent lower cost than regular virtual machines with the same machine types, options, and performance, but Compute Engine can preemptively stop or delete them to reclaim zone capacity. Choose Spot VMs when the workload runs batch jobs or web or application tiers, is fault-tolerant and flexible, and can tolerate preemption, and keep regular virtual machines when availability must be assured.
Autoscaling applies only to stateless managed instance groups (MIGs) where virtual machines are identical and replaceable, automatically creating virtual machines when demand rises and deleting them when demand falls to minimize idle capacity. Stateful managed instance groups (MIGs) cannot be autoscaled because they preserve per-virtual machine disks and state.
Last updated