1.4. Reflection Checkpoint

Key Takeaways

• Cloud computing shifts the core question from "did we buy enough hardware" to "are we paying only for what we use" — and IaaS, PaaS, and SaaS represent different altitudes of how much of that stack you manage yourself.
• The shared responsibility model always leaves identity and access configuration in your hands, no matter how much infrastructure Google manages underneath a given service.
• The resource hierarchy (Organization → Folder → Project → Resource) is fundamentally an access-control propagation mechanism — policies set high in the hierarchy flow down automatically.
• Resource scope (zonal, regional, or global) determines both blast radius during an outage and which resources can directly communicate — a VPC is global even though the VMs inside it are zonal.
• The console, Cloud Shell, gcloud/gsutil/bq, and the underlying APIs are all different doors into the same resource state, not competing sources of truth.

Connecting Forward

Phase 2 puts this foundation to work on the exam's first scored domain: setting up the actual cloud solution environment — creating the projects and organizational structure you just learned about, granting the IAM roles that make the resource hierarchy meaningful, and configuring the billing that keeps it all running.

Self-Check Questions

• Without looking back at 1.2.1, can you explain why a standalone project without an Organization above it is a valid but limited configuration — limited in what specific way?
• If a teammate insists the Google Cloud Console and the gcloud CLI can end up "out of sync" with each other, how would you correct that misunderstanding using what you learned in 1.3?