DEV Community

Lucas Bennett
Lucas Bennett

Posted on

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

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

OrganizationFoldersProjectsResources

💡 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:

  1. 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.
  2. 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).
  3. 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.

Top comments (0)