Isolating projects on Google Cloud can happen at two different layers, and the Professional Cloud Database Engineer exam tends to test whether you can tell them apart. One approach draws a boundary at the network layer using separate VPCs, and the other draws a boundary at the service layer using VPC Service Controls. They solve related problems but are not interchangeable, so a scenario question usually comes down to matching the requirement to the right layer.
The simpler technique is to give each project its own VPC and make sure there is no peering or routing configured between them. Picture two projects, each with its own VPC network and its own subnets, and no peering connection or shared route linking the two. Because there is no network relationship between them, traffic cannot flow directly from one VPC to the other. The absence of a connection is what creates the boundary.
This works at the network layer, which means it controls whether packets can move between the networks at all. It is commonly used to separate different environments or different departments, and it can help meet security and compliance requirements by enforcing strict boundaries between projects. For many isolation needs, creating separate VPCs with no peering or routing between them is sufficient on its own.
VPC Service Controls operate at a different layer. Instead of controlling network connectivity, they let you create a security perimeter around a project that governs access to Google Cloud services. The perimeter acts as a protective boundary that prevents data exfiltration and ensures that resources in one project cannot reach resources in another project.
Consider two projects again, where the first holds services such as Cloud Run functions, Dataflow, and Cloud Run, and the second holds services such as Compute Engine, App Engine, and the managed service for Apache Spark. By placing a service control perimeter around each project, resources inside the first project are restricted from accessing resources in the second, and the reverse holds as well. Each project then operates within its own boundary with no cross-project data leakage.
The point to hold onto is that this is service layer isolation, not network layer isolation. It adds protection on top of network controls by governing access to the managed services themselves, which is the part network rules alone do not address.
The two techniques are not mutually exclusive, and the layer a question describes is usually the signal for which one applies. If the requirement is to stop traffic from moving between project networks, separate VPCs with no peering or routing handle it at the network layer. If the requirement is to prevent data exfiltration or stop one project's resources from reaching another project's services, that is the service layer, and VPC Service Controls is the tool. When a scenario calls for both strict network boundaries and protection against data leaving through a service, we would lean toward combining them, with the VPCs providing the network boundary and the service perimeters layered on top.
Our Professional Cloud Database Engineer course covers VPC project isolation alongside VPC Service Controls perimeters and network peering, with practice questions that drill these distinctions.
