Context
A developer can have permission to create a virtual machine in a project and still be unable to attach it to the intended subnet. In Shared VPC, the workload and the network can belong to different projects with different administrators. A broad role in the service project does not automatically describe access to the host project's network.
Imagine an illustrative platform team onboarding a new application project. VM creation works on a local test network but fails on the approved shared subnet. Granting more roles inside the application project does not change the result. The investigation needs to identify which resource rejects the actual calling identity.
Draw the resource ownership boundary
Shared VPC places shared network resources in a host project while eligible application resources live in attached service projects. Google documents Network User permissions at the host-project or selected-subnet level, alongside the permissions needed to manage workload resources in the service project. Attaching a project does not automatically move its existing resources onto the shared network. 1
Write the full subnet resource reference in the onboarding record. A short subnet name can be ambiguous across projects and regions. Record the host project, service project, region, network, subnet, and the workload type being created before changing any access policy.
Identify the principal that actually makes the call
The person clicking a console button may not be the identity used by an automated deployment. Inspect the active credentials, impersonated service account, CI identity, and any service agent involved in provisioning. A permission granted to the engineer will not necessarily help a managed service acting through its own identity.
Capture the denied permission and target resource from the error or audit evidence. Avoid reducing the incident to “permission denied in project A” when the denied operation references project B. Keep the principal, permission, and resource together as one evidence item so the relevant administrator can assess the smallest change.
Separate network use from network administration
An application deployer may need to use an approved subnet without being able to alter routes, firewall rules, or every other subnet in the host project. Prefer the scope that matches the deployment responsibility. Project-wide Network User access can include more current and future subnets than a single application requires.
Document exceptions rather than accumulating broad roles until a deployment works. A temporary test with additional access should have a planned removal and a follow-up test under the intended role. The final successful run must use the final permissions; otherwise the evidence does not establish that the production access design is sufficient.
Check product-specific service agents
Managed products can require additional service-agent permissions or setup steps in a Shared VPC environment. Use the documentation for the actual product rather than treating every service as a directly created VM. Distinguish the deployer's right to request a resource from the service agent's right to provision or operate it.
Keep those grants visible in the application onboarding template. If an organization deploys several product types, use separate requirements for each. One oversized host-project role assigned to every service account makes onboarding easy to start but difficult to audit or revoke safely.
Rule out non-IAM failures
After permission is correct, provisioning can still fail because the selected subnet is in the wrong region, address capacity is exhausted, organization policy blocks the resource, or a required API is unavailable. Read the new error after each change instead of assuming every subsequent failure has the original cause.
Similarly, a successfully created VM may still lack the intended connectivity. Firewall rules, routes, DNS, and service access are separate operating controls. The onboarding test should include only the connections the application is expected to make, with unauthorized paths tested as explicit rejections where practical.
Test one complete onboarding path
Create a small representative workload using the actual deployment identity and approved subnet. Verify the resulting network interface references the intended host network. Run the required DNS and connectivity checks, then remove the test workload through the normal cleanup procedure.
Repeat the permission test for a subnet the application is not supposed to use. The expected denial demonstrates the scope boundary. Keep this test safe and read-only where possible; the purpose is to establish that access is constrained, not to probe unrelated workloads or collect their data.
Make project changes operationally predictable
When adding subnets or changing host-project policy, review whether existing grants cover more than intended or fail to include a newly approved location. When offboarding a service project, identify running resources and dependencies before removing access. Revocation and resource cleanup should be coordinated rather than performed as unrelated tickets.
An illustrative handover table might list “CI deployer: create compute in service project; use subnet X in host project; no use of subnet Y.” Add the service-agent requirements and the successful test run. This is much easier for a new engineer to understand than a list of role names without resource scope.
A focused operator exercise: A subnet-scoping acceptance example
Give a test deployment identity the intended service-project resource permissions and access to one approved host-project subnet. Deploy a small workload there, confirm its network reference, then attempt an authorized negative test against another test subnet outside the grant. The expected denial provides evidence that the access scope is real.
Remove the test workload through the normal cleanup path and verify that no broad temporary host-project role remains. Include any product-specific service-agent grant in the record. This demonstrates the complete onboarding contract: the deployer can create the required workload, use its assigned network, and cannot silently expand into every subnet in the host project.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Project boundary | Identify host and service projects | Locate the actual subnet owner |
| Effective identity | Trace the provisioning principal and service agents | Grant only required subnet access |
| Placement test | Exercise the intended subnet and a forbidden subnet | Confirm rejected placement stays rejected |
Frequently asked questions
Does project Owner in the service project solve host-network access? Do not assume it does. Investigate the actual host resource and effective principal.
Clouvenix can review the Shared VPC onboarding path and produce a scoped access matrix, helping platform and application teams resolve failures without broadening the entire host network's permissions.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.