Google Cloud resource hierarchy: IAM inheritance, service accounts and Shared VPC
Understand Google Cloud organizations, folders and projects through IAM inheritance and Shared VPC. Diagnose a cross-project deployment by separating caller permissions, runtime identity and packet connectivity.
TL;DR: A project owns resources and provides a permission boundary, while Shared VPC lets its workloads use networking owned by another project. Diagnose the specific caller, permission and target resource before changing access; successful provisioning does not establish runtime connectivity.
Draw ownership before the packet path
Google Cloud's resource hierarchy places projects under an organization, optionally through folders. A folder can collect production projects under common administration, while individual projects retain separate resource ownership. A billing account is associated with a project for charging; it is not another parent in the resource hierarchy. See the Resource Manager hierarchy.
Allow-policy grants accumulate down this hierarchy. Removing a project-level binding does not remove access granted by a folder above it. Inspect the principal's inherited bindings before declaring access revoked. Applicable deny policies and conditions also matter; the union of allow grants alone is not a complete authorization evaluator. Google's IAM inheritance examples explain that distinction.
Organization Policy constrains supported resource configurations. It can restrict a deployment even when its caller has an IAM permission. Granting a broader IAM role does not fix a prohibited configuration. The Organization Policy overview distinguishes these controls.
The hierarchy arrows identify ownership. The subnet and API arrows represent two different dependencies. Sharing a network does not merge the projects' permissions.
Separate the deployment identity from the running workload
A delivery job might create a VM while a service account attached to that VM later reads objects. The job needs permission to provision the resource and, where required, act as the chosen service account. The running application needs permission on the bucket. Making the delivery identity powerful does not automatically grant the attached identity access to data.
Shared VPC adds a host-project dependency. The network team owns the VPC and subnets in the host project; service projects own workloads using those subnets. Subnet use is authorized separately, commonly through the Network User role at a suitable scope. Additional service-agent permissions vary by product, so a VM permission checklist is not a complete GKE or serverless checklist. Consult the Shared VPC roles and ownership model.
| Failed operation | Identity to establish | Resource or control to inspect |
|---|---|---|
| Create a VM | Delivery principal | Compute permissions in the service project |
| Attach the chosen subnet | Principal named in the denial | Host-project subnet access |
| Read an object after startup | Runtime service account | Bucket/object authorization and conditions |
| Connect to a private endpoint | Running workload and packet path | DNS, routes, firewall policy and listener |
Google Cloud VPC networks are global resources; subnets are regional. A VM uses a subnet in its region. This differs from an AWS regional VPC, so redraw the design when moving between providers. VPC specifications describe the scopes and connectivity requirements.
Investigate a cross-project rollout
In this fictional case, a build identity creates instances in orders-prod, but its first deployment fails while referencing a subnet in network-prod. The error names a missing subnet-use permission. The team grants Owner on orders-prod and retries. Nothing changes: the missing permission applies to a resource in the host project.
Identify the exact failing principal from the operation, then have the network owner grant the smallest supported access on the intended subnet. Keep application data access separate. Once the VM starts, an object-read denial may reveal a second issue: the attached runtime identity was never granted access to the bucket.
A third failure can appear as a connection timeout. At that point, inspect DNS resolution, endpoint addresses and network policy rather than continuing to widen IAM. A completed TLS connection returning an authorization error and a TCP connection that never establishes are different observations. Record both the error layer and the requested resource.
Explain the correction without claiming total access
An interview follow-up can remove the folder grant and ask whether the workload still works. Recompute access from the actual remaining bindings, identities and dependencies. A successful test under a human administrator's credentials proves little about the service account used in production.
Self-check: a project policy contains no binding for an engineer, but a parent folder grants that engineer Viewer. Does the empty project policy deny the inherited permission? No. Allow grants are inherited. Review the ancestor grant and any applicable deny or condition, then test with the intended identity. A project policy is not an override that clears all parent permissions.