What's changed: Created Professional Cloud DevOps Engineer Chapter 1 (Domain 1 "Bootstrap": resource hierarchy/IAM least privilege/org policies/service accounts/Workload Identity/Shared VPC/VPC peering/Private Service Connect/multi-project monitoring/data residency; IaC = Infrastructure Manager/Config Connector/Terraform/Helm/GitOps/blueprints; multi-environments/ephemeral/GKE fleets/patching; Cloud Workstations/Cloud Shell/Gemini Code Assist).
1.1Resource hierarchy, IAM, and shared networking
Understand designing an org resource hierarchy (organization/folders/projects), IAM roles and organization-level policies, creating and managing service accounts, shared networking via Shared VPC/VPC Network Peering/Private Service Connect, multi-project monitoring/logging, and data residency.
A Professional Cloud DevOps Engineer spreads practices that balance delivery speed and reliability across the organization. The foundation is bootstrapping the organization correctly first: resource hierarchy, access control, and shared networking.
1.1.1Resource hierarchy and access control
Organize resources in the organization→folders→projects→resources hierarchy, designing folders application-centrically or by team/environment. Control access with IAM least privilege (avoid basic roles; predefined/custom), and enforce org-wide constraints with organization policies (org-level), inherited down the hierarchy. Represent workload identity with service accounts, preferring Workload Identity to avoid exporting keys. Map "org-wide guardrails = organization policies" and "grants = IAM."
1.1.2Shared networking and multi-project operations
For consistent networking across projects, use Shared VPC (a host project shares its VPC with service projects); connect separate VPCs with VPC Network Peering; and reach specific services privately with Private Service Connect. Operationally, design cross-project monitoring/logging (aggregated sinks, metrics scopes), and control storage geography with data residency for compliance. Map "common network across projects = Shared VPC" and "private access to a service = Private Service Connect."
Common: requirement → means. E.g., "enforce org-wide constraints" = organization policies; "least-privilege access" = IAM predefined/custom; "workload identity" = service accounts (keyless = Workload Identity); "common VPC across projects" = Shared VPC; "connect separate VPCs" = VPC peering; "private access to a service" = Private Service Connect; "storage-region regulation" = data residency.
Watch the mix-ups: (1) IAM (grants) vs organization policies (enforced constraints) are different layers. (2) Do not confuse Shared VPC (share one VPC) with VPC peering (connect separate VPCs). (3) Downloading service-account keys is a last resort (a leak source)—prefer Workload Identity.
1.1.3Section summary
- Organize via organization/folder/project hierarchy; govern with IAM least privilege + org policies
- Workload identity = service accounts; prefer keyless Workload Identity
- Shared networking = Shared VPC/VPC peering/Private Service Connect; storage geography via data residency
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To enforce org-wide consistent constraints (e.g., disallow creation outside certain regions) via inheritance, what do you use?
Q2. To let multiple service projects use a common VPC network, which is best?
Q3. To let a workload call Google Cloud APIs without holding service-account keys, which is best?
Q4. For compliance, to store data in a specific country/region, which concept?
Q5. To reach a specific managed service privately without traversing the internet, which is best?