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.

Vpc Ip Allocation Alias Ranges Multi Nic | Professional Cloud Security Engineer

Vpc Ip Allocation Alias Ranges Multi Nic

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

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.

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.

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.

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.

Professional Cloud Security Engineer

Vpc Ip Allocation Alias Ranges Multi Nic

Related questions