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?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.

