Why I’m Documenting My Google Cloud Journey (And What I’m Learning

Lucas Bennett — Thu, 30 Jul 2026 03:10:47 +0000

Hey everyone! 👋

When I first started learning Google Cloud Platform (GCP), I quickly realized that memorizing high-level service names wasn’t enough. To truly master cloud architecture, you need to understand the underlying mechanics, practical trade-offs, and common architectural traps.

Instead of sharing just a high-level study roadmap, I want to dive straight into 3 key structural lessons and practical takeaways I’ve compiled during my GCP journey so far.

1. Identity & Access Management (IAM): The Hierarchy & Inheritance Trap

One of the most crucial foundational concepts in GCP is how resource hierarchy affects permissions.

The Core Structure

Organization ➔ Folders ➔ Projects ➔ Resources

💡 Crucial Takeaways & Practical Pitfalls:

Permissions Are Inherited Downward: If you assign a user the Roles/Viewer role at the Folder level, they automatically inherit Read access to all Projects inside that folder. You cannot deny an inherited permission at a lower level.
Primitive Roles vs. Predefined Roles:
- Primitive Roles (Owner, Editor, Viewer) are broad and dangerous for production. Granting Editor at the Project level gives write access to almost every service.
- Best Practice: Always use Predefined Roles (e.g., roles/storage.objectViewer) or Custom Roles following the Principle of Least Privilege (PoLP).
Service Accounts are Both Identities AND Resources: A Service Account can act as an identity (assigned permissions to run VMs) AND as a resource (where users need iam.serviceAccountUser permissions to act as that service account).

2. Cloud Storage (GCS): Choosing the Right Storage Class

Google Cloud Storage (GCS) is simple on the surface, but choosing the wrong storage class or lifecycle policy can dramatically impact cost and latency.

Quick Decision Framework:

Storage Class	Minimum Storage Duration	Typical Use Case	Access Frequency
Standard	None	Hot data, active website assets	Multiple times a day
Nearline	30 days	Monthly backups, infrequent reports	Less than once a month
Coldline	90 days	Disaster recovery, quarterly archives	Less than once a year
Archive	365 days	Regulatory compliance, long-term logs	Rare (highest retrieval cost)

💡 Practical Cost Traps:

Early Deletion Fees: If you delete an object in Coldline storage after 10 days, GCP will still charge you for the remaining 80 days of storage.
Lifecycle Rules for Cost Savings: Automate storage tiering using Object Lifecycle Management. For example: Set a rule to transition logs from Standard to Nearline after 30 days, and delete them after 360 days.

3. BigQuery: Architecture & Cost-Optimization Rules

BigQuery is Google's serverless data warehouse. Because compute and storage are decoupled, it scales effortlessly—but inefficient SQL queries can quickly drain your budget.

How BigQuery Charges You:

On-Demand Pricing: You are charged based on the number of bytes scanned by your query (typically $6 per TB scanned).

💡 3 Rules to Prevent Massive BigQuery Bills:

Never Run SELECT *: BigQuery is a columnar database. SELECT * forces the engine to scan every single column in the table, drastically increasing query cost. Only select the explicit columns you need.
Use Partitioning and Clustering:
- Partitioning: Divide large tables by date or integer ranges (e.g., partition by event_timestamp). This ensures queries only scan data within the specified date range.
- Clustering: Sort data within partitions based on high-cardinality columns (e.g., user_id).
Preview Data for Free: Use the Preview tab in the BigQuery console or table metadata to inspect table content without incurring query costs.

🚀 Summary & What's Next

Understanding these nuanced behaviors—how IAM permission inheritance works, how early deletion penalty fees apply in GCS, and how columnar scanning impacts BigQuery pricing—is what separates a theoretical learner from a practical cloud architect.

This is my first deep-dive post here on DEV.to! I will continue publishing technical breakdowns and architectural notes as I progress.

DEV Community: Lucas Bennett