Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
A decision tree that guides users through selecting the correct Cloud Storage class (Standard, Nearline, Coldline, or Archive) based on data access frequency.
Cloud Storage offers different classes based on access frequency: Standard is for frequently accessed data, Nearline for monthly access, Coldline for yearly access, and Archive for data accessed less than once a year.
For workloads requiring very low latency, Cloud Filestore or Persistent Disk provide faster access times than object storage because they attach directly to compute instances rather than being accessed over HTTP.
Object Lifecycle Management in Cloud Storage automatically moves objects to cheaper storage classes or deletes them based on age or custom conditions, which reduces costs without manual intervention, and an example policy is including rules to delete older object versions after a threshold.
Retention policies can be set at the bucket level to enforce minimum retention periods or to lock buckets so that data cannot be deleted before a specified time, while versioning keeps multiple versions of objects, which increases storage costs.
When setting up storage in GCP, the first decision involves choosing the right storage type based on how the data will be used. Cloud Storage is the primary object storage service and offers different classes: Standard for frequently accessed data, Nearline for monthly access, Coldline for yearly access, and Archive for data accessed less than once a year. Filestore provides managed file shares for applications that need traditional file storage, while Persistent Disk attaches to virtual machines as block storage for databases and enterprise applications. The allocation choice depends on performance needs, access frequency, and cost sensitivity, and moving data between storage classes later is possible but incurs transfer costs.
Storage systems in GCP rarely work alone; they connect to compute resources that process the data they hold. Cloud Storage works with Compute Engine virtual machines, Cloud Run containers, and Dataflow for batch and streaming data processing. When a compute instance needs to read or write data, it mounts or accesses the storage service through GCP's internal network, not the public internet, which keeps performance high and costs low. The compute provisioning side involves deciding whether processing happens in real-time with ephemeral compute resources or through persistent servers that maintain connections to storage over time. Understanding this relationship helps architects avoid bottlenecks where fast compute resources are slowed down by slower storage or where expensive compute sits idle because storage cannot deliver data quickly enough.
Controlling who and what can access stored data is a fundamental part of storage configuration. GCP uses Identity and Access Management (IAM) to define permissions at the project level, individual storage buckets, or even specific objects within buckets. The principle of least privilege guides this configuration: give only the permissions needed for each workload and nothing more. Beyond IAM, Cloud Storage supports customer-managed encryption keys through Cloud KMS for organizations with strict data encryption requirements, and VPC Service Controls add additional security perimeters around storage resources to prevent data exfiltration. Authentication to storage can use service accounts, which are special identities that applications use automatically, or user accounts for human administrators, and the choice affects how credentials are managed and rotated over time.
How quickly data moves between users, applications, and storage depends on network configuration and storage choices. Cloud Storage automatically uses Google's global network to move data, but performance improves when the storage bucket is in the same region as the compute resources accessing it. For workloads requiring very low latency, Cloud Filestore or Persistent Disk provide faster access times than object storage because they attach directly to compute instances rather than being accessed over HTTP. When data must be transferred into GCP from on-premises locations, Transfer Service automates large moves, while Storage Transfer Service moves data between cloud providers. The key relationship to understand is that distance between the data consumer and the storage location directly impacts latency, so geographic placement is a primary configuration decision.
Stored data does not stay static; policies determine how long it is kept and what happens to it over time. Object Lifecycle Management in Cloud Storage automatically moves objects to cheaper storage classes or deletes them based on age or custom conditions, which reduces costs without manual intervention. Retention policies can be set at the bucket level to enforce minimum retention periods or to lock buckets so that data cannot be deleted before a specified time, which supports compliance with regulations like financial record-keeping requirements. Versioning in Cloud Storage keeps multiple versions of objects, but this increases storage costs, so lifecycle policies often include rules to delete older versions after a threshold. The relationship between lifecycle policies and cost is direct: well-configured policies save money, while neglected policies can lead to unexpected billing as data accumulates.
Storage systems must account for data that grows over time, and planning involves estimating capacity and setting up mechanisms to handle growth gracefully. GCP storage services scale automatically without capacity planning for object storage, but Persistent Disk has limits on size per disk, and Filestore has tier-specific capacity ceilings that require monitoring. Setting up Cloud Monitoring alerts on storage utilization helps teams respond before hitting limits, and Cloud Billing budgets prevent unexpected costs from runaway data growth. Capacity planning also includes understanding growth patterns: some workloads grow steadily, while others grow in bursts, and compute resources must be ready to handle the processing demands that come with more data. The key relationship is between data volume, processing power, and cost, as each element must scale in balance with the others.
Protecting data from loss or corruption involves backup, recovery, and redundancy strategies. Cloud Storage stores data redundantly across multiple facilities by default, but additional protection comes from enabling versioning to keep historical copies of objects. For databases and applications using Persistent Disk, Snapshots capture point-in-time images of disks that can be used to create new disks or recover from failures. Cloud SQL and Cloud Spanner offer automated backups that can be configured with retention periods, and point-in-time recovery allows restoring to any moment within the backup window. The relationship between backup frequency and recovery point objective (RPO) is direct: more frequent backups mean less data loss in a disaster, but also more storage costs and management complexity. Choosing the right protection strategy depends on how much data loss is acceptable and how quickly recovery must complete.