Skip to content

Chapter 1: GCP Resource Hierarchy & Organization

Thành công khi manage 1000+ resources across 100+ projects yêu cầu deep understanding của GCP organizational structure.

Chapter này covers foundation của mọi GCP deployment: từ cách organize resources, authenticate services, allocate costs cho tới enforce policies.

Learning Path

Recommend theo thứ tự sau (nhưng có thể skip topics quen thuộc):

Foundation (Bắc buộc hiểu)

  1. Resource Hierarchy Fundamentals - 4-tier hierarchy (Org→Folder→Project→Resource), inheritance model, blast radius
  2. Resource Manager API - Programmatic resource management, eventual consistency, retry patterns
  3. Project Naming & Automation - Project ID constraints, soft-delete, naming conventions

Access & Security (Bắc buộc)

  1. IAM Policy Propagation - Three-layer propagation, testing strategies, timing
  2. Service Account Scoping - Keys vs tokens, impersonation, workload identity
  1. Labels, Tags, & Organization - Metadata strategy, cost allocation, conditional policies
  2. Cloud Asset Inventory - Querying resource state, compliance auditing, drift detection
  3. Organization Policies - Constraint enforcement, inheritance, custom constraints
  1. Quota Management - Rate/allocation/concurrent quotas, exhaustion handling
  2. Resource Protection - Locking, soft-delete, accidental deletion prevention
  3. Billing Hierarchy - Cost attribution, chargeback, budget alerts

Networking (For ops/platform teams)

  1. Shared VPC Model - Centralized network management, cross-project connectivity

By Use Case

I'm a backend engineer building services

→ Read: 01, 02, 04, 05, 06, 10

I'm a platform engineer managing infrastructure

→ Read: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12

I'm an ops/SRE person

→ Read: 01, 04, 07, 08, 09, 11

I'm DevOps/Infrastructure automation

→ Read: 02, 03, 05, 06, 08, 09, 11

I'm building compliance/security solutions

→ Read: 04, 06, 07, 08, 12

Key Concepts Across Chapter

Hierarchy & Inheritance

Resources organized trong 4-tier hierarchy (Org→Folder→Project→Resource). Policies inherit đi xuống (Org → Project) nhưng không đi lên ngược.

Important: Lower-level policies cannot override upper-level deny policies.

Eventual Consistency

GCP is distributed system. Resource creation/updates take 5-60 seconds propagate:

  • T+0: Instant (control plane)
  • T+5-30s: Cache layer updated
  • T+5-60s: Services acknowledge change

Implication: Automation phải retry, không assume immediate consistency.

Blast Radius Management

Hierarchy helps contain blast radius: Delete one project không impact khác. Shared policies apply across many projects → careful enforcement needed.

Metadata Strategy

Three parallel systems track resources:

  • Labels (per-resource, queryable, cost allocation)
  • Tags (hierarchical, IAM-aware, policy enforcement)
  • Network Tags (legacy, firewall-only)

Combined effectively → powerful organization + compliance.

Cost Attribution

Proper labels + billing export → accurate cost tracking by team/service/environment.

Production Patterns

Pattern 1: Immutable Infrastructure

Project-A:
- VMs created via Terraform
- Terraform manages all changes
- Manual edits detected + rejected

Benefit: Repeatable, auditable, drift-detectable

Pattern 2: Tiered Security

Production: Strict policies (CMEK, OS Login, no external IPs)
Staging: Moderate policies (encryption optional)
Dev: Minimal policies (enable experimentation)

Implemented via: Tags → Conditional Organization Policies

Pattern 3: Cost Governance

1. Mandatory labels on creation
2. Labels include cost-center
3. Monthly BigQuery report
4. Chargeback to teams
5. Alert if budget exceeded

Result: Teams own their costs

Anti-Patterns to Avoid

❌ One giant project with everything
   → Blast radius too large, hard to manage quotas

❌ Inconsistent labels
   → Cannot query resources, cost tracking fails

❌ Owner role for engineers
   → Cannot prevent destructive actions

❌ Terraform destroy without safeguards
   → Production resources accidentally deleted

❌ No backups
   → Data loss is permanent

❌ Service accounts with keys on machines
   → Keys can be stolen, hard to rotate

❌ No organization policies
   → Teams do insecure things (external IPs, weak encryption)

What's Next

After mastering Chapter 1:

  • Chapter 2: VPC & Networking deep dive
  • Chapter 3: Kubernetes (GKE) at scale
  • Chapter 4: Data engineering patterns
  • Chapter 5: Disaster recovery & availability

Quick Reference

Commands

bash
# Hierarchy navigation
gcloud projects list
gcloud resource-manager folders list
gcloud resource-manager org-policies list

# Service account operations
gcloud iam service-accounts create NAME
gcloud iam service-accounts add-iam-policy-binding SA@PROJECT.iam.gserviceaccount.com

# Billing
gcloud billing accounts list
gcloud billing projects link PROJECT_ID --billing-account=ID

# Asset inventory
gcloud asset search-all-resources --scope=organizations/ORG_ID

# Quotas
gcloud compute project-info describe --project=PROJECT_ID

Terraform

hcl
# Project creation
resource "google_project" "example" {
  name       = "My Project"
  project_id = "my-project-123"
  org_id     = "123456789"
  folder_id  = "123456789"
}

# Service account
resource "google_service_account" "example" {
  account_id = "my-sa"
  project    = google_project.example.project_id
}

# IAM binding
resource "google_project_iam_member" "example" {
  project = google_project.example.project_id
  role    = "roles/compute.admin"
  member  = "serviceAccount:${google_service_account.example.email}"
}

# Labels on resources
resource "google_compute_instance" "example" {
  labels = {
    environment = "production"
    team        = "backend"
  }
}

Document Info

  • Last Updated: 2026-06-01
  • GCP Docs Version: Based on official docs fetched 2026-05-15
  • Language: Vietnamese (Tiếng Việt)
  • Target Audience: Senior engineers, platform teams, infrastructure specialists
  • Total Content: 12 files, ~42,000 words, production-focused