1.2. The Google Cloud Resource Hierarchy
💡 First Principle: Every resource you create in Google Cloud lives inside a nested container structure, and permissions and policies set on an outer container automatically flow down to everything inside it — which means understanding the hierarchy is really understanding how access control propagates.
Without a resource hierarchy, managing permissions for a company with hundreds of projects and thousands of resources would mean configuring access one resource at a time — an approach that doesn't scale and virtually guarantees mistakes. The hierarchy exists so an administrator can set a policy once, near the top, and have it apply everywhere beneath it.
Think of it like a corporate filing cabinet: the Organization is the cabinet itself, Folders are the drawers (often mapped to departments or teams), and Projects are the individual folders inside each drawer holding the actual documents — the resources you create. A rule taped to the outside of the cabinet ("no confidential documents leave the building") applies to every drawer and folder inside it automatically.
⚠️ Common Misconception: Learners sometimes treat "Project" as a billing-only container with no security implications. In reality, the project boundary is also the default scope for most IAM grants and quota limits — it's simultaneously a billing unit, a security boundary, and an API-enablement boundary.
