An enterprise is designing a multi-tier perimeter security architecture in Google Cloud for containerized workloads hosted on Compute Engine VMs, alongside a dedicated virtual security appliance. The deployment must satisfy the following networking and boundary requirements: Due to RFC 1918 address space exhaustion on-premises, custom VPC subnets must utilize alternative valid private address ranges, such as RFC 6598 (100.64.0.0/10), without violating Google Cloud subnet allocation rules. Individual containers running on each host VM must each receive their own dedicated, internally routable IP address from a secondary subnet range for granular firewall policy enforcement without adding physical network interfaces. The virtual security appliance VM must connect directly to two distinct VPC networks (vpc-untrusted and vpc-trusted) to inspect and filter transit traffic between them. Which configuration should the enterprise implement to satisfy these requirements?

Configure custom mode VPC subnets using primary ranges from RFC 6598 (100.64.0.0/10) with secondary IPv4 ranges, assign alias IP ranges from the secondary ranges to nic0 of the container host VMs, and deploy the security appliance VM at creation time with nic0 attached to vpc-untrusted and nic1 attached to vpc-trusted.: What This Architecture Is This architecture leverages Custom Mode VPC subnets, RFC 6598 Shared Address Space, VPC Alias IP ranges, and Multi-NIC Compute Engine instances to build a secure, isolated network topology that overcomes RFC 1918 address exhaustion. How It Meets the Requirements Alternative Private Address Space: Custom mode subnets support valid non-RFC 1918 address ranges, including RFC 6598 (100.64.0.0/10) and privately used public IP ranges. This eliminates conflicts with existing on-premises RFC 1918 subnets. Workload Isolation with Alias IP: Defining secondary IPv4 ranges on the subnets allows container hosts to assign alias IP ranges directly to nic0. Each container gets a discrete internal IP address that VPC firewall rules can independently target using IP filters or service accounts. Multi-VPC Appliance Attachment: Multi-NIC VM instances allow dual-homing across isolated VPC perimeters. Specifying nic0 in vpc-untrusted and nic1 in vpc-trusted during VM instantiation satisfies the rule that each vNIC must belong to a unique VPC network. Key Advantages and Capabilities No Overlay Overhead: Alias IP ranges provide native VPC routability for container endpoints without requiring complex overlay encapsulation. Strict Perimeter Isolation: Dual-homed security appliances bridge separate VPCs while keeping routing tables and network perimeters strictly segregated. Flexible Subnet Expansion: Secondary ranges can be added or adjusted dynamically on subnets to accommodate container growth. Standardized Security Policies: VPC distributed firewall rules can inspect and filter traffic destined for individual alias IP addresses assigned to containers. Why This Is Optimal This design complies strictly with Google Cloud network constraints: it avoids prohibited address spaces, adheres to the rule that vNICs cannot be added after VM creation, and utilizes native secondary subnet ranges for container addressing.

Alias IP Ranges and Multi-NIC VMs for Containers

Container Alias IPs and Dual VPC Appliances

An enterprise is designing a multi-tier perimeter security architecture in Google Cloud for containerized workloads hosted on Compute Engine VMs, alongside a dedicated virtual security appliance. The deployment must satisfy the following networking and boundary requirements:

Due to RFC 1918 address space exhaustion on-premises, custom VPC subnets must utilize alternative valid private address ranges, such as RFC 6598 (100.64.0.0/10), without violating Google Cloud subnet allocation rules.
Individual containers running on each host VM must each receive their own dedicated, internally routable IP address from a secondary subnet range for granular firewall policy enforcement without adding physical network interfaces.
The virtual security appliance VM must connect directly to two distinct VPC networks (vpc-untrusted and vpc-trusted) to inspect and filter transit traffic between them.

Which configuration should the enterprise implement to satisfy these requirements?

Configure custom mode VPC subnets using primary ranges from RFC 6598 (100.64.0.0/10) with secondary IPv4 ranges, assign alias IP ranges from the secondary ranges to nic0 of the container host VMs, and deploy the security appliance VM at creation time with nic0 attached to vpc-untrusted and nic1 attached to vpc-trusted.

Deploy auto mode VPC networks to automatically generate RFC 6598 subnets across all regions, allocate ephemeral external IPs to containers to bypass internal exhaustion, and attach dynamic NICs to the security appliance across projects.

Create a broad custom subnet spanning 100.0.0.0/8 to encompass RFC 6598 and public ranges within a single primary CIDR, provision additional vNICs (nic1, nic2) in the same subnet for each container workload, and attach both appliance interfaces to vpc-untrusted.

Configure subnets with primary ranges from the link-local range (169.254.0.0/16), assign secondary ranges as primary VM interface IPs, and dynamically add a second vNIC to the security appliance VM after initial deployment.

Explanations

Configure custom mode VPC subnets using primary ranges from RFC 6598 (100.64.0.0/10) with secondary IPv4 ranges, assign alias IP ranges from the secondary ranges to nic0 of the container host VMs, and deploy the security appliance VM at creation time with nic0 attached to vpc-untrusted and nic1 attached to vpc-trusted.

What This Architecture Is

This architecture leverages Custom Mode VPC subnets, RFC 6598 Shared Address Space, VPC Alias IP ranges, and Multi-NIC Compute Engine instances to build a secure, isolated network topology that overcomes RFC 1918 address exhaustion.

How It Meets the Requirements

Alternative Private Address Space: Custom mode subnets support valid non-RFC 1918 address ranges, including RFC 6598 (100.64.0.0/10) and privately used public IP ranges. This eliminates conflicts with existing on-premises RFC 1918 subnets.
Workload Isolation with Alias IP: Defining secondary IPv4 ranges on the subnets allows container hosts to assign alias IP ranges directly to nic0. Each container gets a discrete internal IP address that VPC firewall rules can independently target using IP filters or service accounts.
Multi-VPC Appliance Attachment: Multi-NIC VM instances allow dual-homing across isolated VPC perimeters. Specifying nic0 in vpc-untrusted and nic1 in vpc-trusted during VM instantiation satisfies the rule that each vNIC must belong to a unique VPC network.

Key Advantages and Capabilities

No Overlay Overhead: Alias IP ranges provide native VPC routability for container endpoints without requiring complex overlay encapsulation.
Strict Perimeter Isolation: Dual-homed security appliances bridge separate VPCs while keeping routing tables and network perimeters strictly segregated.
Flexible Subnet Expansion: Secondary ranges can be added or adjusted dynamically on subnets to accommodate container growth.
Standardized Security Policies: VPC distributed firewall rules can inspect and filter traffic destined for individual alias IP addresses assigned to containers.

Why This Is Optimal

This design complies strictly with Google Cloud network constraints: it avoids prohibited address spaces, adheres to the rule that vNICs cannot be added after VM creation, and utilizes native secondary subnet ranges for container addressing.

View source documentation

Deploy auto mode VPC networks to automatically generate RFC 6598 subnets across all regions, allocate ephemeral external IPs to containers to bypass internal exhaustion, and attach dynamic NICs to the security appliance across projects.

What This Option Proposes

This approach relies on Auto Mode VPC networks for subnet provisioning, assigns ephemeral external IPv4 addresses directly to container workloads to mitigate private address exhaustion, and attempts to use Dynamic NICs to bridge perimeters.

Why It Doesn't Meet the Requirement

Auto Mode IP Space is Fixed: Auto mode VPC networks automatically create subnets strictly within the predefined 10.128.0.0/9 range (which is RFC 1918 space). They cannot automatically create subnets using RFC 6598 (100.64.0.0/10).
Security Exposure via External IPs: Exposing container microservices with external IPv4 addresses violates internal isolation principles, creates unnecessary public attack surfaces, and incurs external IP billing.
Auto Mode VPC Limitations: Auto mode networks do not support secondary IPv4 ranges required for native container alias IP allocation.

Key Characteristics and Limitations

Auto mode subnets use fixed RFC 1918 allocations (10.128.0.0/9) with a /20 mask per region.
Custom mode VPCs are required when custom address schemes, RFC 6598, or secondary IP ranges are needed.
Public external IPs do not solve private internal communication requirements.

This Answer Would Be Correct If

The architecture required rapid prototyping with default Google Cloud regional subnets and all workloads required direct, unfiltered outbound and inbound public internet reachability.

View source documentation

Create a broad custom subnet spanning 100.0.0.0/8 to encompass RFC 6598 and public ranges within a single primary CIDR, provision additional vNICs (nic1, nic2) in the same subnet for each container workload, and attach both appliance interfaces to vpc-untrusted.

What This Option Proposes

This option attempts to allocate a supernet range spanning multiple address types (100.0.0.0/8), use multiple virtual network interfaces (vNICs) attached to the same subnet for container networking, and attach multiple interfaces of an appliance VM into a single VPC network.

Why It Doesn't Meet the Requirement

Invalid Subnet Range: Google Cloud subnets must not span an RFC range and a public IP range, nor can they span multiple RFC classifications. 100.0.0.0/8 improperly encompasses both RFC 6598 (100.64.0.0/10) and public routable IPv4 blocks, making it an invalid CIDR configuration.
vNIC Multi-Tenancy Limits: In standard VPCs, Compute Engine does not permit multiple vNICs on the same instance to attach to the same VPC network or subnet.
Lack of Multi-VPC Perimeter Bridging: Connecting both interfaces of the security appliance to vpc-untrusted prevents it from acting as an inline inspection gateway between vpc-untrusted and vpc-trusted.

Key Characteristics and Limitations

Subnet ranges must be valid, unique CIDR blocks contained entirely within RFC 1918, RFC 6598, or designated non-RFC 1918 private spaces.
Multi-NIC instances require each interface to terminate in a unique VPC network.
Containers require alias IP ranges rather than dozens of physical/virtual NICs per host VM.

This Answer Would Be Correct If

The workload was running on specialized bare-metal instances utilizing RDMA network profiles where multi-NIC attachments to the same subnet are supported.

View source documentation

Configure subnets with primary ranges from the link-local range (169.254.0.0/16), assign secondary ranges as primary VM interface IPs, and dynamically add a second vNIC to the security appliance VM after initial deployment.

What This Option Proposes

This option proposes using the link-local range (169.254.0.0/16) for primary subnet CIDRs, assigning secondary ranges directly to primary network interfaces, and dynamically attaching a second vNIC to an existing VM after deployment.

Why It Doesn't Meet the Requirement

Prohibited Subnet Range: 169.254.0.0/16 (RFC 3927 link-local) is a prohibited and restricted range in Google Cloud VPCs and cannot be used as a subnet primary or secondary range.
Secondary Range Inversion: Primary VM internal IPv4 addresses must always come from the subnet's primary range, not secondary ranges. Secondary ranges are reserved exclusively for alias IP allocations.
vNIC Immutability: Standard vNICs cannot be added or removed after instance creation. All required vNICs must be declared at the time the VM is created.

Key Characteristics and Limitations

Link-local (169.254.0.0/16), multicast (224.0.0.0/4), and loopback (127.0.0.0/8) ranges are strictly restricted from subnet creation.
Compute Engine assigns the primary internal IP from the subnet's primary range via DHCP.
Modifying VM interface counts requires deleting and recreating the instance or using Dynamic NIC VLAN subinterfaces where supported.

This Answer Would Be Correct If

The VMs were operating on an on-premises hypervisor that supports live hot-plugging of virtual NICs and automatic link-local auto-configuration.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Container Alias IPs and Dual VPC Appliances

Due to RFC 1918 address space exhaustion on-premises, custom VPC subnets must utilize alternative valid private address ranges, such as RFC 6598 (100.64.0.0/10), without violating Google Cloud subnet allocation rules.
Individual containers running on each host VM must each receive their own dedicated, internally routable IP address from a secondary subnet range for granular firewall policy enforcement without adding physical network interfaces.
The virtual security appliance VM must connect directly to two distinct VPC networks (vpc-untrusted and vpc-trusted) to inspect and filter transit traffic between them.

Which configuration should the enterprise implement to satisfy these requirements?

Explanations

Configure custom mode VPC subnets using primary ranges from RFC 6598 (100.64.0.0/10) with secondary IPv4 ranges, assign alias IP ranges from the secondary ranges to nic0 of the container host VMs, and deploy the security appliance VM at creation time with nic0 attached to vpc-untrusted and nic1 attached to vpc-trusted.

What This Architecture Is

How It Meets the Requirements

Alternative Private Address Space: Custom mode subnets support valid non-RFC 1918 address ranges, including RFC 6598 (100.64.0.0/10) and privately used public IP ranges. This eliminates conflicts with existing on-premises RFC 1918 subnets.
Workload Isolation with Alias IP: Defining secondary IPv4 ranges on the subnets allows container hosts to assign alias IP ranges directly to nic0. Each container gets a discrete internal IP address that VPC firewall rules can independently target using IP filters or service accounts.
Multi-VPC Appliance Attachment: Multi-NIC VM instances allow dual-homing across isolated VPC perimeters. Specifying nic0 in vpc-untrusted and nic1 in vpc-trusted during VM instantiation satisfies the rule that each vNIC must belong to a unique VPC network.

Key Advantages and Capabilities

No Overlay Overhead: Alias IP ranges provide native VPC routability for container endpoints without requiring complex overlay encapsulation.
Strict Perimeter Isolation: Dual-homed security appliances bridge separate VPCs while keeping routing tables and network perimeters strictly segregated.
Flexible Subnet Expansion: Secondary ranges can be added or adjusted dynamically on subnets to accommodate container growth.
Standardized Security Policies: VPC distributed firewall rules can inspect and filter traffic destined for individual alias IP addresses assigned to containers.

Why This Is Optimal

View source documentation

Deploy auto mode VPC networks to automatically generate RFC 6598 subnets across all regions, allocate ephemeral external IPs to containers to bypass internal exhaustion, and attach dynamic NICs to the security appliance across projects.

What This Option Proposes

Why It Doesn't Meet the Requirement

Auto Mode IP Space is Fixed: Auto mode VPC networks automatically create subnets strictly within the predefined 10.128.0.0/9 range (which is RFC 1918 space). They cannot automatically create subnets using RFC 6598 (100.64.0.0/10).
Security Exposure via External IPs: Exposing container microservices with external IPv4 addresses violates internal isolation principles, creates unnecessary public attack surfaces, and incurs external IP billing.
Auto Mode VPC Limitations: Auto mode networks do not support secondary IPv4 ranges required for native container alias IP allocation.

Key Characteristics and Limitations

Auto mode subnets use fixed RFC 1918 allocations (10.128.0.0/9) with a /20 mask per region.
Custom mode VPCs are required when custom address schemes, RFC 6598, or secondary IP ranges are needed.
Public external IPs do not solve private internal communication requirements.

This Answer Would Be Correct If

The architecture required rapid prototyping with default Google Cloud regional subnets and all workloads required direct, unfiltered outbound and inbound public internet reachability.

View source documentation

Create a broad custom subnet spanning 100.0.0.0/8 to encompass RFC 6598 and public ranges within a single primary CIDR, provision additional vNICs (nic1, nic2) in the same subnet for each container workload, and attach both appliance interfaces to vpc-untrusted.

What This Option Proposes

Why It Doesn't Meet the Requirement

Invalid Subnet Range: Google Cloud subnets must not span an RFC range and a public IP range, nor can they span multiple RFC classifications. 100.0.0.0/8 improperly encompasses both RFC 6598 (100.64.0.0/10) and public routable IPv4 blocks, making it an invalid CIDR configuration.
vNIC Multi-Tenancy Limits: In standard VPCs, Compute Engine does not permit multiple vNICs on the same instance to attach to the same VPC network or subnet.
Lack of Multi-VPC Perimeter Bridging: Connecting both interfaces of the security appliance to vpc-untrusted prevents it from acting as an inline inspection gateway between vpc-untrusted and vpc-trusted.

Key Characteristics and Limitations

Subnet ranges must be valid, unique CIDR blocks contained entirely within RFC 1918, RFC 6598, or designated non-RFC 1918 private spaces.
Multi-NIC instances require each interface to terminate in a unique VPC network.
Containers require alias IP ranges rather than dozens of physical/virtual NICs per host VM.

This Answer Would Be Correct If

The workload was running on specialized bare-metal instances utilizing RDMA network profiles where multi-NIC attachments to the same subnet are supported.

View source documentation

Configure subnets with primary ranges from the link-local range (169.254.0.0/16), assign secondary ranges as primary VM interface IPs, and dynamically add a second vNIC to the security appliance VM after initial deployment.

What This Option Proposes

Why It Doesn't Meet the Requirement

Prohibited Subnet Range: 169.254.0.0/16 (RFC 3927 link-local) is a prohibited and restricted range in Google Cloud VPCs and cannot be used as a subnet primary or secondary range.
Secondary Range Inversion: Primary VM internal IPv4 addresses must always come from the subnet's primary range, not secondary ranges. Secondary ranges are reserved exclusively for alias IP allocations.
vNIC Immutability: Standard vNICs cannot be added or removed after instance creation. All required vNICs must be declared at the time the VM is created.

Key Characteristics and Limitations

Link-local (169.254.0.0/16), multicast (224.0.0.0/4), and loopback (127.0.0.0/8) ranges are strictly restricted from subnet creation.
Compute Engine assigns the primary internal IP from the subnet's primary range via DHCP.
Modifying VM interface counts requires deleting and recreating the instance or using Dynamic NIC VLAN subinterfaces where supported.

This Answer Would Be Correct If

The VMs were operating on an on-premises hypervisor that supports live hot-plugging of virtual NICs and automatic link-local auto-configuration.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Container Alias IPs and Dual VPC Appliances

Explanations

What This Architecture Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Deploy auto mode VPC networks to automatically generate RFC 6598 subnets across all regions, allocate ephemeral external IPs to containers to bypass internal exhaustion, and attach dynamic NICs to the security appliance across projects.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Create a broad custom subnet spanning 100.0.0.0/8 to encompass RFC 6598 and public ranges within a single primary CIDR, provision additional vNICs (nic1, nic2) in the same subnet for each container workload, and attach both appliance interfaces to vpc-untrusted.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Configure subnets with primary ranges from the link-local range (169.254.0.0/16), assign secondary ranges as primary VM interface IPs, and dynamically add a second vNIC to the security appliance VM after initial deployment.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Private VMs Without External IPs Architecture

Serverless VPC Access Private Google Access

Workforce Pool PrincipalSet Group Binding

VPC Service Controls with Private Google Access

Privileged Access Manager JIT Elevation

Google Cloud Multi-Tenant Resource Hierarchy

Container Alias IPs and Dual VPC Appliances

Explanations

What This Architecture Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Deploy auto mode VPC networks to automatically generate RFC 6598 subnets across all regions, allocate ephemeral external IPs to containers to bypass internal exhaustion, and attach dynamic NICs to the security appliance across projects.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Create a broad custom subnet spanning 100.0.0.0/8 to encompass RFC 6598 and public ranges within a single primary CIDR, provision additional vNICs (nic1, nic2) in the same subnet for each container workload, and attach both appliance interfaces to vpc-untrusted.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Configure subnets with primary ranges from the link-local range (169.254.0.0/16), assign secondary ranges as primary VM interface IPs, and dynamically add a second vNIC to the security appliance VM after initial deployment.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Private VMs Without External IPs Architecture

Serverless VPC Access Private Google Access

Workforce Pool PrincipalSet Group Binding

VPC Service Controls with Private Google Access

Privileged Access Manager JIT Elevation

Google Cloud Multi-Tenant Resource Hierarchy