Professional Cloud Network Engineer
Private Services Access (PSA) is a networking mechanism that lets resources inside a Virtual Private Cloud (VPC) network communicate privately with managed Google Cloud services like Cloud SQL without using external IP addresses. Administrators allocate a dedicated internal IP address range for the service producer using the gcloud compute addresses create command with the --purpose=VPC_PEERING flag. This allocation reserves a CIDR block that can be specified manually or assigned automatically by Google Cloud based on a requested prefix length. Once allocated, this address range is reserved exclusively for service producers and cannot be used for local subnets or custom static route destinations. For managed Google services, a /16 block is recommended, and the allocation must be at least a /24 block to prevent address exhaustion.
A private connection establishes a direct VPC Network Peering link between a consumer VPC network and a service producer VPC network. When the private connection is created, the service producer provisions resources inside an isolated tenant project and assigns them private IP addresses from the consumer's allocated range. The consumer VPC network automatically imports routes from the producer network, allowing VM instances to access the managed services entirely across Google's internal network backbone. A single consumer VPC network can establish a private connection to only one managed service instance of a specific type, so connecting to multiple distinct service producer organizations requires separate allocated IP ranges to prevent routing conflicts.
A private worker pool in Cloud Build executes container builds within a secure, dedicated environment that is peered directly to a consumer VPC network. Administrators create these pools using the gcloud builds worker-pools create command and attach them to a network using the --peered-network flag. To isolate the build environment completely from the public internet, administrators can supply the --no-public-egress flag, which removes external IP addresses from the worker nodes. When workers lack public IP addresses, outbound traffic targeting Google APIs must route through Private Google Access or a Cloud NAT gateway.
A custom mode VPC network gives administrators full manual control over IP address schemes, regional subnet placement, and routing boundaries by creating an empty network without default subnets. Administrators create a custom network using the gcloud compute networks create --subnet-mode=custom command and subsequently add regional subnets with explicit primary and secondary IPv4 ranges. Subnet ranges can be selected from standard private IP space (RFC 1918), shared address space (RFC 6598, 100.64.0.0/10), or specialized protocol ranges (RFC 6890, 192.0.0.0/24). Subnet CIDR blocks must never overlap with other subnets in the same network, static route destinations, or peered networks. Administrators should also avoid the 10.128.0.0/9 block to prevent conflicts with auto mode networks, and avoid 172.17.0.0/16 if host workloads run internal container runtimes like Docker.
IPv6 networking in Google Cloud provides dual-stack address assignments across VPC networks, subnets, and VM network interfaces. When IPv6 is enabled with Unique Local Addresses (ULAs), Google Cloud assigns the VPC network an immutable /48 range selected from fd20::/20. Subnets configured for dual-stack operation receive a /64 CIDR block, which uses either internal ULA addresses or external Globally Unique Addresses (GUAs). When an external /64 IPv6 block is assigned, Google Cloud divides the range into two /65 allocations, dedicating the first half to VM instances and the second half to Cloud Load Balancing. Compute Engine VM interfaces receive a /96 prefix, and the primary address is assigned automatically through DHCPv6. Once created, a subnet's IPv6 access type (internal or external) cannot be modified, dual-stack internal subnets cannot revert to IPv4-only, and subnets cannot operate in an IPv6-only state.
Specialized subnets and private virtual IP ranges allow internal compute instances to reach Google APIs and managed services without sending traffic over the public internet. When migrating workloads to Private Service Connect (PSC), administrators create dedicated consumer subnets with the purpose explicitly set to PEER_MIGRATION, reserving those subnets solely for PSC endpoint deployment. For Private Services Access deployments, administrators must allocate an internal IP range of at least /18 managed by the servicenetworking API. Private Google Access allows private VMs without external IPs to reach Google services through the domain endpoints private.googleapis.com (199.36.153.8/30 IPv4, 2600:2d00:0002:2000::/56 IPv6) or restricted.googleapis.com (199.36.153.4/30 IPv4, 2600:2d00:0002:1000::/56 IPv6). Both domain options require custom VPC routes for 34.126.0.0/18 and 2001:4860:8040::/42, support only HTTP-based protocols over TCP port 443, and require egress firewall rules allowing TCP port 443.
Google Cloud supports complex multi-network architectures and UDP multicast message delivery through Network Connectivity Center (NCC) hubs. In a multicast architecture, publisher instances transmit UDP packets to Class D multicast groups (224.0.0.0/4) without joining the group, while subscriber instances join the group using Internet Group Management Protocol version 2 (IGMPv2). When deployed across multiple VPCs in an NCC star topology, administrator and producer VPC networks attach to an NCC hub as center spokes, while consumer VPCs connect as edge spokes. Administrators configure export filters on the spokes to define the exact subnet CIDR blocks shared through the hub, preventing cross-network IP conflicts.
Cloud Next Generation Firewall (Cloud NGFW) provides a fully distributed firewall architecture that enforces security policies at the organization, folder, and VPC network levels. Hierarchical firewall policies are inherited down the resource hierarchy: organization policies apply to all nested folders and projects, folder policies apply to child projects, and VPC policies apply only to the specific network. Policy evaluation follows strict priority ordering where lower priority numbers are processed first, allowing higher levels of the organization to enforce mandatory security controls. Rules define specific action types (allow or deny) and directional filtering (ingress or egress). Administrators at lower resource levels can override inherited rules only when the parent policy explicitly delegates or omits conflicting higher-priority rules.
Traditional VPC firewall rules operate as a stateful, distributed firewall applied to individual VM network interfaces across Layer 3 and Layer 4. Because the firewall is stateful, allowing an egress request automatically permits the corresponding inbound return traffic regardless of incoming deny rules. The firewall enforces an implied deny rule that blocks all inbound traffic from outside the VPC unless explicitly matched by an ingress allow rule. Cloud NGFW rules are enforced directly on the virtual interface hardware, protecting VMs regardless of guest operating system state or whether the operating system has finished booting.
Target segmentation allows security teams to apply firewall rules to specific subsets of VM instances without altering the underlying subnet topology. Administrators can segment traffic using network tags, which are user-defined strings, or secure tags, which are IAM-governed labels that prevent unauthorized modification. IAM service accounts provide an identity-based targeting mechanism where firewall rules attach to the service account assigned to a VM. Using service accounts as firewall targets ensures that security policies follow the VM's functional identity rather than its network location, establishing strict workload isolation within a shared subnet.
Firewall rule optimization reduces management overhead and stays within VM programming limits by consolidating multiple ports and protocols into broader, single-rule definitions. Rather than creating separate rules for each individual application port, administrators should combine multiple target ports into a single multi-port rule. A structured policy design begins with broad rules applied across the entire VPC network, followed by group rules applied via service accounts or secure tags, and concludes with narrow rules assigned to specific instances like NAT gateways or bastion hosts. Administrators can enable Firewall Rules Logging on individual rules to export connection metadata, verify policy behavior, and perform security audits.
VPC Network Peering establishes private, low-latency connectivity between VPC networks across projects and organizations within Google Cloud, enabling scalable communication without using external IP addresses or traversing the public internet. Two primary patterns organize multiple VPC networks: the peering mesh and hub-and-spoke topology. In a peering mesh, every VPC network peers directly with every other VPC network, which provides the shortest path for traffic but becomes complex to manage as the number of networks grows. In a hub-and-spoke topology, a central hub VPC network peers with multiple spoke VPC networks, but the spokes do not peer directly with each other; all inter-spoke traffic must route through the hub. This centralizes network management and security policy enforcement but adds an extra hop for traffic between spokes, which can increase latency.
VPC Network Peering provides private connectivity within Google Cloud, but hybrid connectivity extends this private network to on-premises data centers or other clouds using Cloud VPN or Cloud Interconnect. In a hub-and-spoke design, the hub VPC typically hosts the hybrid connectivity gateway. The Cloud VPN gateway or Cloud Interconnect attachment resides in the hub VPC, allowing on-premises networks to access all peered spoke VPCs through the hub. Traffic flow in this integrated model follows a defined path: when an on-premises system communicates with a resource in a spoke VPC, the traffic first enters Google Cloud via the Cloud VPN tunnel or Interconnect VLAN attachment in the hub VPC, then the hub's routing table directs the traffic over the appropriate VPC Network Peering connection to the target spoke VPC, and the return traffic flows symmetrically back through the same path.
Shared VPC allows you to designate a single host project containing the shared VPC network, while service projects use subnets and resources from that shared network. When combined with VPC Network Peering, Shared VPC enables you to build large-scale, multi-project architectures with centralized control. This approach centralizes ownership of core networking components like firewall rules, routes, and hybrid gateways in the host project's Shared VPC, which is managed by a central networking team. Service project teams can then deploy their workloads into designated subnets without needing broad network permissions.
VPC Network Peering is a networking feature that enables private connectivity between two VPC networks in Google Cloud, allowing resources in each network to communicate using internal IP addresses without traversing the public internet. When you create a peering connection, the two VPC networks exchange subnet routes automatically, enabling seamless communication between instances in both networks.
To establish VPC Network Peering, you must create a peering configuration on both VPC networks involved in the connection, as the connection is only established when both sides have a matching configuration. The process involves creating a peering connection on the consumer network first, then creating a corresponding peering connection on the producer network; only then does the peering state change from INACTIVE to ACTIVE. Once the peering becomes ACTIVE, subnet routes and custom routes are exchanged between the networks according to your configuration.
A VPC Network Peering connection progresses through specific lifecycle states that indicate the status of the connection. The peering starts in an INACTIVE state when you create the first side of the peering, because the other VPC network does not yet have a matching configuration. When the other network creates a corresponding peering configuration, the state changes to ACTIVE in both networks, confirming that the connection is established and traffic can flow.
VPC Network Peering requires that the two VPC networks have non-overlapping CIDR ranges; if the IP address spaces overlap, the peering cannot be established because routing would be ambiguous. Additionally, VPC Network Peering is non-transitive, meaning that if VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot reach VPC C through VPC B—each pair of networks must have a direct peering connection to communicate.
When VPC networks are peered, they always exchange subnet routes, which allows resources in each network to reach any subnet in the peer network. You can optionally configure the peering to import and export custom routes, which include both static routes you define and dynamic routes learned from Cloud Router; however, custom routes are only exchanged when both networks are configured to do so. Exporting custom routes is particularly important when you need to advertise routes to on-premises networks connected via Cloud VPN or Cloud Interconnect, so that the peer network can route traffic to your on-premises environment.
VPC networks are project-level resources with fine-grained, project-level IAM controls, including roles such as networkAdmin, securityAdmin, networkUser, and networkViewer. By default, IAM controls apply to all VPC networks within a project. If you require independent IAM controls per VPC network, you should create the VPC networks in different projects, which provides isolation for security-sensitive or compliance-regulated environments.
A VPC Network Peering connection requires matching configurations in both participating VPC networks before active communication and route exchange can begin. When an administrator creates a peering connection in a local network, its lifecycle state remains INACTIVE until the administrator of the peer network creates a reciprocal connection pointing back to the local network. Once both sides configure the peering, the lifecycle state transitions to ACTIVE, triggering an automatic exchange of all subnet routes between the two networks.
Custom route import and export settings control whether static and dynamic routes propagate across a VPC Network Peering boundary. Peered VPC networks do not share custom static routes or dynamic routes learned from Cloud Router by default; both networks must explicitly opt in to the exchange. For traffic to flow using custom routes, the source VPC network must enable the Export custom routes flag, and the destination peer VPC network must enable the Import custom routes flag.
VPC Network Peering is strictly non-transitive, meaning intermediate networks cannot forward traffic between two separate peered VPC networks. If network A peers with network B, and network B peers with network C, workloads in network A cannot reach network C through network B across the peering relationship alone. In architectures where on-premises traffic arrives at a hub VPC network via Cloud VPN or Cloud Interconnect, custom routes must be exported to the peered VPC network to extend private connectivity.
Diagnosing peering connectivity failures requires validating route export states, active subnet allocations, and underlying firewall policies. If a private service endpoint or hybrid destination is unreachable, administrators must confirm that the appropriate static or dynamic route appears in the exported and imported routes views in the VPC Network Peering console. Furthermore, because each peered network manages its own security boundary, administrators must configure ingress firewall rules or network firewall policies to explicitly permit incoming traffic, such as allowing Identity-Aware Proxy access from 35.235.240.0/20 or allowing application traffic from the peer subnet ranges.
A Shared Virtual Private Cloud (Shared VPC) centralizes network management by allowing a designated host project to share its network with attached service projects. Setting up this architecture requires enabling the host project, associating service projects, and delegating specific administrative permissions across the organization.
A host project is a Google Cloud project that owns and shares one or more VPC networks across multiple projects. A Shared VPC Admin activates this functionality by running the gcloud compute shared-vpc enable command against the target host project. Once enabled, the host project serves as the central control plane for all subnets, routes, Cloud VPN gateways, and firewall rules. Network security teams maintain exclusive ownership of these infrastructure components within the host project boundary.
A service project is a standard Google Cloud project attached to a host project to consume its shared network infrastructure. A Shared VPC Admin attaches a service project using the gcloud compute shared-vpc associated-projects add command. After this attachment is established, workloads in the service project can connect to host project subnets without creating their own independent networks.
IAM separates host network administration from application management inside service projects. The Shared VPC Admin manages host enablement, project attachments, and network configurations across the environment. In contrast, Service Project Admins manage local compute resources such as virtual machines and internal load balancers. Administrators can grant the Compute Network User role at the project level to share all subnets or assign it at the individual subnet level to enforce least-privilege access.
Workloads deployed inside service projects allocate their primary internal IP addresses directly from the shared host subnets. A VM instance in a service project must be provisioned in a zone that resides within the exact region of its assigned host subnet. For example, a VM utilizing a subnet located in us-west1 must be placed in a zone such as us-west1-a. Existing standalone VM instances cannot be retroactively moved into a Shared VPC; they must be deleted and recreated to bind to the shared subnets.
Granular subnet sharing allows organizations to restrict service projects to specific host subnets rather than exposing an entire VPC network. This access model enforces least-privilege security boundaries between different application teams using the same underlying network.
The relationship between host and service projects creates a strict boundary between network infrastructure ownership and workload execution. The host project administrator determines which subnets are accessible to specific service projects. Service Project Admins consume those authorized IP spaces to launch resources without gaining permissions to alter the host network topology.
Subnet-level permission delegation grants a service project access to explicit subnets while blocking visibility into the rest of the host network. This model uses the compute.networks.use and compute.subnetworks.use permissions, which are packaged inside the Compute Network User role. Administrators assign this role to specific user accounts, groups, or service accounts on targeted subnets in the host project.
Cross-project access requires the Compute Network User role to be assigned on the host project or its subnets, not on the service project. Because the underlying network resources exist inside the host project, permissions must be verified against the host project's resource hierarchy. When a principal in a service project launches a compute instance, the system checks the host project's IAM policy to validate subnet access.
Private Service Connect endpoints provisioned in service projects require coordinated permissions across project boundaries. The Service Project Admin must reserve an internal IP address inside the service project that references a subnet located in the host project. This internal IP address must match the region of the target service producer's service attachment.
Cross-project resource provisioning allows complex workloads like container clusters and load balancers to run in service projects while consuming host network IP ranges and security rules. This setup requires specialized service accounts, secondary IP configurations, and host firewall rules.
Google Kubernetes Engine (GKE) clusters running in service projects consume primary subnet ranges for nodes and secondary IP ranges for Pods and Services from the host project. Clusters in a Shared VPC require VPC-native traffic routing, which is enabled by default in Autopilot clusters and must be specified during creation for Standard clusters. The host subnet must provide two dedicated secondary IPv4 ranges that do not overlap with each other, existing subnets, or the reserved 172.17.0.0/16 range. Private GKE clusters additionally require a non-overlapping /28 IPv4 prefix dedicated to the control plane, and existing clusters cannot be migrated into a Shared VPC after creation.
Cross-project GKE provisioning depends on granting specific IAM roles to service project service accounts at the host project level. A Shared VPC Admin must grant the Compute Network User role to both the service project's Google APIs service account and the service project's GKE service account. Additionally, the service project's GKE service account must receive the Kubernetes Engine Host Service Agent User role at the host project level. If these roles are missing or the host project's GKE API is disabled, cluster creation fails during network metadata validation.
Static IP address objects allow service project workloads to maintain consistent internal or external entry points across reboots. When creating an internal static IP address in a service project, the address object resides in the service project, but its value is allocated from the host project's subnet. The principal creating the reservation must hold the compute.subnetworks.use permission on the host subnet.
Centralized firewall rules created in the host project control all ingress and egress traffic for cross-project workloads. For Cloud Load Balancing, host firewall rules must allow ingress traffic from the health check IP ranges 35.191.0.0/16 and 130.211.0.0/22 on destination ports 80 and 443. To permit administrative access without public IP addresses, host firewalls must allow ingress from 35.235.240.0/20 on TCP ports 22 and 3389 for Identity-Aware Proxy (IAP) TCP forwarding.
IAM delegation is the process of granting permissions to automated service accounts so they can create network-attached resources inside a Shared VPC. In a Shared VPC setup, the network is owned by a central host project, but resources like VMs or clusters are created in separate service projects. For this to work, the service accounts that perform these automated tasks need specific permissions in the host project to attach network interfaces to the correct subnets.
The core permission needed to use a Shared VPC subnet is the Compute Network User role. A Shared VPC administrator can grant this role in two ways: at the host project level, which gives the service account access to all subnets, or at the individual subnet level for more precise control, restricting the account to only specific subnets. Custom service accounts managed by users must have this role on the target subnets before they can create VM instances.
The Google APIs Service Agent is a Google-managed account that handles backend automation for a project, identified by SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com. When a managed instance group (MIG) in a service project needs to create VM instances using a Shared VPC subnet, this agent performs the network attachment. The Shared VPC Admin must grant this agent the Compute Network User role on the specific host project subnet used in the instance template.
The Kubernetes Engine Service Agent, identified as service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, manages cluster infrastructure like nodes and load balancers in a Shared VPC. It needs multiple permissions in the host project: the Compute Network User role on the shared subnets, the Host Service Agent User role on the host project's own GKE service agent, and additional permissions for managing firewall rules.
The Dataproc Service Agent needs cross-project permissions to deploy managed clusters into a Shared VPC network. It must be granted the Compute Network User role on the host project. If the clusters are configured to run using custom VM service accounts from other projects, the Dataproc Service Agent also needs the Service Account User and Service Account Token Creator roles on those custom accounts.
Subnet-level versus project-level network user role provisioning refers to the decision of where to assign the Compute Network User role within a Shared VPC host project. This choice determines whether a service account can access all subnets or only specific ones.
Subnet-level provisioning means granting the Compute Network User role directly on a single subnet resource. This creates a strict, least-privilege boundary. A principal with this binding can only attach resources to that particular subnet. This granular approach prevents the principal from accessing other, potentially more sensitive subnets within the same Shared VPC, enforcing strong network segmentation between different workloads or environments.
Project-level provisioning grants the Compute Network User role on the entire Shared VPC host project resource. This gives the principal permission to use any subnet within that host project's Shared VPC. This approach offers broad network access and simplifies administration by requiring only one IAM policy binding. It is suitable when all service projects are equally trusted and require uniform access to the entire network.
The choice between subnet-level and project-level provisioning is a trade-off between security and management ease. Subnet-level is the secure default for implementing least-privilege access; it is necessary when service projects host workloads of different sensitivity levels that must be isolated. Project-level provisioning reduces administrative overhead but increases risk, as it allows any authorized principal to attach resources anywhere in the network.
Administrative role separation in Google Cloud involves assigning distinct IAM roles across Shared VPC host and service projects to enforce security boundaries while allowing resource deployment. This governance model separates network administration duties from service project operations using predefined roles.
The Shared VPC Admin role allows principals to associate service projects with a host project. Typically granted at the organization level, this role enables the network team to manage the Shared VPC relationship but does not grant permissions to manage the network resources themselves.
The Network Admin role grants the ability to view and manage all networking resources in a project, such as VPCs, subnets, and routes. In a Shared VPC, Network Admins create and modify the shared subnets in the host project. They can view firewall rules but not modify them, maintaining a separation from security policy administration.
The Security Admin role is distinct from the Network Admin role and allows principals to manage firewall rules and security policies. This separation lets organizations divide network configuration responsibilities from security enforcement. Security Admins can create and modify firewall rules that control traffic to instances in both host and service projects.
The Network User role enables principals to use shared subnets without administrative control. Developers in service projects need this role granted on the host project to access the subnets, and also on their own service project to deploy resources.
Effective Shared VPC IAM configuration uses three separate policies at different hierarchy levels. One policy at the organization level grants the network team the Shared VPC Admin and Network Admin roles, and the security team the Security Admin role. A second policy on the host project grants developers the Network User role. A third policy on each service project grants developers both the Network User and Instance Admin roles.
Using Google Groups to manage principals in IAM policies is recommended over using individual user accounts. Administrators add users to groups and then reference these groups in the IAM policy bindings. When personnel change, only the group membership needs updating, which reduces administrative work and the risk of inconsistent permissions.
Private Google Access allows virtual machines without external IP addresses to reach Google APIs and services through Google's private network infrastructure. When enabled on a subnet, instances in that subnet can access services like Cloud Storage, BigQuery, and Cloud SQL without traffic leaving Google's network. The traffic routes to the reserved IP addresses 199.36.153.8/30 for private.googleapis.com or 199.36.153.4/30 for restricted.googleapis.com, depending on whether you need access to all Google Cloud services or only the ones supported by VPC Service Controls. Both options require custom routes for the address ranges 34.126.0.0/18 and 2001:4860:8040::/42, and firewall rules must allow egress on TCP port 443.
After creating a VPC subnet, administrators can expand the primary IP address range to accommodate growing workloads without recreating the subnet or disrupting existing resources. The expansion process involves specifying a new, larger CIDR range that includes the original range, ensuring no overlap with other subnets in the VPC or with peered network ranges. Google Cloud automatically propagates the updated route to all instances in the subnet, and existing IP addresses remain unchanged. Secondary IP ranges for pods and services in GKE can also be expanded independently, providing additional IP capacity for container workloads.
VPC Service Controls create security perimeters around Google Cloud resources to prevent data exfiltration and restrict access from unauthorized networks. Administrators define perimeters that encompass specific projects and services, then add access levels or ingress/egress policies that control which identities and networks can access the protected resources. Traffic between resources inside a perimeter stays within Google's network, while attempts to access resources from outside the perimeter are evaluated against the configured policies. Egress policies can restrict which domains or IP addresses resources inside the perimeter can reach, and ingress policies can require that incoming requests meet specific conditions like coming from trusted identities or IP ranges.
Overlapping IP address ranges cause routing conflicts that make parts of the allocated range unreachable. This prevents service producers from provisioning new resources within the tenant project and results in allocation exhaustion errors.
No. Once a subnet is configured with an internal IPv6 access type, it cannot be converted back to IPv4-only, its IPv6 access type cannot be changed between internal and external, and it cannot be transitioned to an IPv6-only state.
In a peering mesh, every VPC network peers directly with every other network, providing the shortest path but becoming complex to manage as the number of networks grows. In a hub-and-spoke topology, a central hub VPC peers with multiple spoke VPCs, and all inter-spoke traffic must route through the hub, which centralizes management but adds an extra hop and makes the hub a potential bottleneck.
The Compute Network User role must be granted on the host project or on individual subnets within the host project. Because network resources belong to the host project, assigning permissions within the service project does not authorize a user to consume host subnets.
Subnet-level provisioning grants the Compute Network User role on a specific subnet, allowing a principal to attach resources only to that subnet. Project-level provisioning grants the role on the entire host project, allowing the principal to attach resources to any subnet within that project's Shared VPC.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts