Bootstrap and Maintain a Google Cloud Organization
Hierarchy first, policy second
Every Google Cloud tenant has a single organization node tied to a Cloud Identity or Workspace domain. Below it, folders model business units or environments (prod/non-prod, sandbox), and projects are the unit of API enablement, billing linkage, and quota. Design the tree before creating resources: moving a project later is possible, but IAM bindings, org policies, and Shared VPC attachments must all be re-validated.
Three guardrail layers matter most. IAM bindings are additive and inherited downward, so grant to Google Groups at folder scope and prefer predefined roles; custom roles are for genuine gaps. Organization policies are constraints evaluated on the effective policy inherited from ancestors, and a child cannot loosen a boolean constraint enforced by an ancestor. VPC Service Controls and Shared VPC (a host project owns the network, service projects attach to it) cover data-exfiltration and network centralization. A billing account must be linked before most resources can be created, so export billing data to BigQuery and attach budgets for chargeback.
Operational hygiene: centralize logs with aggregated sinks at folder or org level into a log bucket owned by a security project, enable Data Access audit logs selectively because they are billed, set Essential Contacts so Google can reach the right humans, and manage everything with Terraform in a pipeline rather than console clicks.
Trap: questions often place a constraint at the org node while asking for a single-project exception. You cannot unenforce it below; put the constraint at the highest common ancestor of the projects that must comply. Also, the Organization Administrator role does not grant org-policy edit rights.
Rule of thumb: if a policy needs exceptions, enforce it no higher than the folder that contains only compliant projects.