IAM, Organization Policy, and VPC Service Controls are all governance and security mechanisms in Google Cloud, but they answer different questions. IAM decides who can perform an action. Organization Policy constrains how resources can be configured. VPC Service Controls adds a context-aware service perimeter intended to reduce data exfiltration.
Architecture becomes confusing when one control is expected to solve another control’s problem. A Google Cloud PCA should be able to identify the layer where a requirement belongs before selecting the mechanism.
IAM answers who can do what
Identity and Access Management is the primary authorization system for Google Cloud resources.
Allow policies grant roles containing permissions to principals. Policies can be applied at resources and inherited through the organization, folder, and project hierarchy. Deny policies and Principal Access Boundary policies add additional controls.
Conditions can further limit when an allow binding applies. That means IAM architecture can express not only identity and role but also contextual requirements tied to supported resource or request attributes. The more conditions an organization uses, the more important Policy Troubleshooter and documentation become because a visible binding may not apply to every request.
IAM is the correct tool for questions such as:
- Can this group create Compute Engine instances?
- Can this service account read objects from a bucket?
- Can this operator administer a project?
- Can this workload impersonate another service account?
Google Cloud service accounts provide useful identity context. The architectural point is broader: IAM is about authorization of principals against resources.
Organization Policy defines configuration guardrails
Organization Policy does not grant a user permission to perform an action.
Instead, it lets administrators enforce constraints across the resource hierarchy. Common examples include limiting resource locations, restricting service account usage, controlling which domains can be granted IAM roles, or disabling selected capabilities.
This is a governance layer. A project owner might have IAM permission to create a resource but still be unable to create it in a prohibited region because an organization policy constraint blocks that configuration.
Organization Policy supports both Google-provided constraints and, for suitable services, custom constraints. That lets platform teams encode rules that are closer to organizational standards instead of relying only on human review. Constraints should still be versioned, tested, and rolled out deliberately because a broad policy at the organization root can affect hundreds of projects at once.
That separation is powerful. Security teams can define non-negotiable rules centrally while delegating day-to-day project administration.
When troubleshooting, this also means an IAM role can be correct while the operation still fails because the requested configuration violates policy.
VPC Service Controls protects service data boundaries
VPC Service Controls adds a different kind of boundary.
Google describes it as an additional defense against data exfiltration for supported Google Cloud services. Service perimeters can restrict access based on context such as network origin, identity, device, and ingress or egress rules.
The control is independent of IAM. A principal might have an IAM role that allows reading sensitive data, but a VPC Service Controls perimeter can still block the request when it originates from an unauthorized context or attempts to move data outside the perimeter.
This is why VPC Service Controls should not be described as "network firewall rules for APIs." It protects access to supported multi-tenant services and controls data movement at the service perimeter layer.
Ingress and egress rules are especially important in real environments. Sensitive projects rarely operate in complete isolation; pipelines may need to call shared services, central security projects, or approved external contexts. Those paths should be expressed explicitly instead of weakening the perimeter with broad exceptions. Access levels can add context such as network or device trust where appropriate.
Google recommends combining IAM and VPC Service Controls for defense in depth rather than treating either as a replacement for the other.
The resource hierarchy connects all three
Organization, folders, and projects provide the governance structure in which these controls are applied.
IAM policies can be inherited down the hierarchy.
Organization Policy constraints can also be inherited and enforced at organization, folder, or project scope.
VPC Service Controls configurations are managed through access policies and service perimeters, with organization-level governance and scoped administration options.
This means architecture should deliberately design the hierarchy before policy sprawl begins. If projects are grouped logically by environment, business unit, sensitivity, or regulatory boundary, higher-level controls become easier to apply consistently.
A poorly designed hierarchy often forces teams into many project-specific exceptions.
A policy can allow an identity while another control blocks the operation
Consider a developer who has a role permitting creation of a virtual machine.
IAM says the developer may call the necessary Compute Engine methods.
An Organization Policy constraint might prohibit external IP addresses, restrict resource locations, or limit which service accounts can be attached. The create request can therefore fail even though the developer has the correct IAM permission.
Now consider a data analyst with permission to read a protected storage or analytics resource. IAM may allow the read, but a VPC Service Controls perimeter may reject the request from an unmanaged network or prevent data from being copied to a project outside the perimeter.
The failure only makes sense when the operator knows which policy layer is being evaluated.
VPC Service Controls is not a complete network or metadata boundary
Service perimeters are powerful, but they are deliberately scoped.
Google notes that VPC Service Controls is focused primarily on controlling data movement for supported services, not providing comprehensive control over all metadata. It also does not replace VPC firewall rules, route policy, IAM, or service-specific configuration.
Architects should therefore avoid broad claims such as "everything inside the perimeter is private."
A service perimeter also does not automatically make a VPC network private. Network ingress to VMs is still governed by firewall policy and routing. Likewise, a resource can be inside a service perimeter while a principal still lacks IAM permission. Keeping these layers separate prevents both false confidence and unnecessary duplicate controls.
The correct design identifies the protected services and data, the allowed ingress and egress paths, and the Google APIs required by workloads. Dry-run configurations are particularly useful because they reveal what would be blocked before enforcement begins.
This is closer to a data-security control plane than a universal network segmentation mechanism.
Dry run and staged enforcement reduce policy outages
Organization-wide controls can break workloads at scale if introduced without observation.
Organization Policy changes should be tested against representative projects and automation. VPC Service Controls supports dry-run configurations that log violations without enforcing them, allowing teams to identify dependencies and legitimate cross-boundary traffic.
That staged approach is important because production systems may call unexpected Google APIs, use shared automation projects, or exchange data between services in ways not obvious from architecture diagrams.
A strong rollout records expected exceptions and avoids using permanent broad bypasses to solve temporary migration issues.
The rollback plan should be defined before enforcement. Teams should know how to identify denied requests in logs, who owns perimeter changes, how quickly an emergency exception can be approved, and how that exception will later be removed. Governance that cannot be operated during an incident eventually gets disabled or bypassed.
The Google Cloud Security Engineer perspective is especially useful here: security controls should be enforceable and operable, not merely strict on paper.
Use each control for its native question
When a requirement is written clearly, control selection becomes easier.
"Only the data engineering group may administer this dataset" is an IAM requirement.
"Projects in this folder must not create resources outside approved regions" is an Organization Policy requirement.
"Sensitive data in these managed services must not be accessed or copied from unauthorized contexts" is a VPC Service Controls requirement.
"VMs in this subnet must not accept inbound traffic from the internet" is a VPC firewall requirement, not any of the three controls discussed here.
This classification prevents policy duplication and makes incident response more predictable. It also makes exception handling clearer because each exception has an owner and a policy layer where it belongs.
Defense in depth works when layers stay understandable
The strongest architecture often uses all three mechanisms, but with distinct responsibilities.
IAM grants the minimum principal permissions.
Organization Policy sets structural guardrails so delegated administrators cannot create prohibited configurations.
VPC Service Controls surrounds selected sensitive services with a contextual data perimeter.
Logging, Security Command Center, and policy analysis then provide visibility into how those controls behave.
The goal is not to maximize the number of policies. It is to make the security model explainable: who has access, what configurations are permitted, and under what context sensitive service data may cross a boundary. When those three questions have clear owners, Google Cloud governance becomes easier to scale.
Review cadence matters as much as initial design. IAM bindings should be recertified, organization-policy exceptions should expire or be justified, and VPC Service Controls ingress and egress rules should be checked against current data flows. Otherwise temporary accommodations become permanent architecture and the control model slowly stops matching the organization it was meant to protect.