Private Services Access (PSA) is a networking mechanism that allows resources within a Virtual Private Cloud (VPC) network to communicate privately with managed service producers, such as 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 Classless Inter-Domain Routing (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 virtual machine (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. If an organization connects to multiple distinct service producer organizations, administrators must assign a separate allocated IP range to each producer 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 (PGA) or a Cloud NAT gateway. If build steps must access external third-party systems from a single, static public IP, administrators can deploy a self-managed NAT gateway VM in the VPC and define a custom default route (0.0.0.0/0) directed to that VM instance.
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 (VIP) 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. Multicast domains are grouped into domain groups to spread packet processing across high-availability shards, and VPC firewall rules must explicitly allow UDP multicast traffic along with IGMP queries (224.0.0.1) and leave messages (224.0.0.2).
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. Administrators can also enable Layer 7 packet inspection capabilities within Cloud NGFW to analyze deeper application-layer traffic patterns.
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—regardless of whether they allow or deny, ingress or egress—to export connection metadata, verify policy behavior, and perform security audits.
StudyCerts
StudyCerts/24 (with /16 recommended for Google services)./64 CIDR block; when configured with external IPv6, Google Cloud divides the block into two /65 ranges dedicated separately to VM instances and Cloud Load Balancing.private.googleapis.com or restricted.googleapis.com VIPs over TCP port 443, requiring additional routes to 34.126.0.0/18 and 2001:4860:8040::/42.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.
Service accounts enforce identity-based access control managed through IAM permissions, preventing VM users from bypassing firewall rules. In contrast, standard network tags can be edited by any user with basic Compute Engine instance editing permissions.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills