Task 2.3: Planning and implementing networking resources.

• AAs an auto mode VPC network, keeping only the subnets of the two regions you need

  Incorrect

  Auto mode creates a subnet in every region from 10.128.0.0/9, which overlaps the on-premises range, and adds subnets in new regions.

• BAs a custom mode VPC network with one planned subnet in each of the two regions

  Correct

  A custom mode network has no subnets until you create them, so you pick the regions and ranges and can avoid the on-premises block.

• CBy using the project's default network and adding firewall rules for the VPN traffic

  Incorrect

  The default network is an auto mode network, with the same 10.128.0.0/9 overlap problem.

• DAs two VPC networks, one per region, joined with VPC Network Peering

  Incorrect

  One VPC network is global and can hold subnets in both regions; splitting it adds peering without solving the range choice.

Auto mode networks are convenient for experiments, but production networks that connect to other networks need custom mode so that every range is planned to avoid overlaps.

• AShared VPC, with a host project for the network and the five application projects as service projects

  Correct

  Shared VPC lets service projects use subnets of the host project's network, while network administration stays in the host project.

• BOne project for all five teams' workloads, with the network team as the only holder of the Compute Network Admin role

  Incorrect

  Merging the projects gives up the separate budgets and access boundaries the teams need.

• CA VPC network in each application project, created from the same Terraform module by the network team

  Incorrect

  Identical networks are still five separate networks owned by the application projects, not one centrally managed network.

• DA VPC network in each application project, peered with a hub network owned by the network team

  Incorrect

  Peering connects networks, but each application team would own and could change its own network, which is what the company wants to avoid.

Shared VPC separates who runs the network from who runs workloads. Service project admins can create resources in the shared subnets they are granted, but cannot change the network itself.

• ACreate an ingress firewall rule allowing TCP port 22 from 0.0.0.0/0 to the VMs

  Incorrect

  This opens SSH to any source, which security forbids and IAP does not need.

• BReserve a static external IP address for each VM and restrict it with a firewall rule

  Incorrect

  IAP TCP forwarding works without external IPs; adding them enlarges the attack surface the design avoids.

• CCreate an ingress firewall rule allowing TCP port 22 from 35.235.240.0/20 to the VMs

  Correct

  IAP TCP forwarding connects to VMs from that range, so the network must allow it on the SSH port.

• DGrant the administrators the IAP-secured Tunnel User role

  Correct

  IAP checks this role before it opens a tunnel, which puts access under IAM control.

• EConfigure Cloud NAT on the subnet so that SSH sessions can reach the VMs

  Incorrect

  Cloud NAT does not allow unsolicited inbound connections, so it cannot carry an SSH session to the VMs.

IAP TCP forwarding wraps SSH in an HTTPS tunnel that IAP authorizes with IAM. The VMs only need to accept port 22 from IAP's forwarding range, not from the internet.

• AAn external passthrough Network Load Balancer in each region

  Incorrect

  It cannot terminate TLS or route by URL path, both of which the site needs.

• BA regional external Application Load Balancer in each region

  Incorrect

  Regional load balancers each have their own IP in one region and do not steer users across regions.

• CA global external Application Load Balancer

  Correct

  This proxy load balancer uses one anycast IP, terminates TLS, routes by host and path, and sends requests to the closest backend with capacity.

• DA global external proxy Network Load Balancer

  Incorrect

  The proxy Network Load Balancer handles TCP traffic globally but does not route by URL path, which the site needs.

Choose a load balancer by traffic type and scope. HTTP(S) with URL routing across regions behind one IP points to the global external Application Load Balancer.

• APrivate Google Access on the subnet

  Correct

  VMs without external IPs can then reach Google APIs and services.

• BAn external IP address on each VM

  Incorrect

  External IPs would also give the VMs internet access.

• CAn ingress firewall rule allowing Cloud Storage

  Incorrect

  Ingress rules control traffic to the VMs, not their access to APIs.

• DVPC Network Peering with Google's network

  Incorrect

  You cannot peer with Google's API network this way.

Private Google Access is a subnet setting that lets internal-only VMs call Google APIs.

• AAn external passthrough load balancer in front of Google APIs

  Incorrect

  You cannot place your load balancer in front of Google's APIs.

• BCloud NAT for the subnet

  Incorrect

  This does not give an internal endpoint for Google APIs.

• CA static external IP address for each VM

  Incorrect

  External addresses do not create an internal endpoint for APIs.

• DA Private Service Connect endpoint for Google APIs

  Correct

  Private Service Connect lets you reach Google APIs through an endpoint with an internal IP address in your VPC network.

When API access must use your own internal addresses, use a Private Service Connect endpoint.

• AExpand the primary range of apps-us so that Pods and Services share it with the nodes

  Incorrect

  In a VPC-native cluster only the nodes take addresses from the subnet's primary range; Pods and Services use secondary ranges.

• BCreate custom static routes for both blocks with the cluster's nodes as next hops

  Incorrect

  Clusters that rely on custom static routes are routes-based; VPC-native Pod ranges do not depend on such routes.

• CAdd both blocks to apps-us as secondary ranges and name them when you create the cluster

  Correct

  VPC-native clusters take Pod and Service addresses from secondary ranges of the cluster's subnet, and ranges you create yourself are ones you manage.

• DCreate a separate subnet for the Pods and another one for the Services in the region

  Incorrect

  Pod and Service addresses come from secondary ranges of the cluster's subnet, not from the primary ranges of other subnets.

Subnets can carry secondary IPv4 ranges for alias IP addresses. A VPC-native cluster uses the subnet's primary range for nodes and secondary ranges for Pods and Services, which can be user-managed.

• AA regional external proxy Network Load Balancer

  Incorrect

  This proxies TCP traffic and does not route by URL.

• BA Cloud DNS public zone with records per backend

  Incorrect

  DNS records do not terminate TLS or route by URL path.

• CA global external Application Load Balancer

  Incorrect

  A global load balancer serves from Google's global edge, not one region.

• DA regional external Application Load Balancer

  Correct

  Regional load balancers keep backends and processing in one region, which suits jurisdictional compliance needs.

Choose regional load balancers when compliance requires traffic to stay in a particular region.

• ADedicated Interconnect to the company's data center

  Incorrect

  This links an on-premises network, not another cloud.

• BCross-Cloud Interconnect to the other cloud

  Correct

  Cross-Cloud Interconnect provisions a dedicated physical connection between Google's network and another cloud provider's network.

• CVPC Network Peering with the other cloud's network

  Incorrect

  Peering connects Google Cloud VPC networks only.

• DDirect Peering with Google's edge

  Incorrect

  Direct Peering reaches Google's public services, not a private link to another cloud.

Multicloud architectures can use Cross-Cloud Interconnect for private, high-bandwidth links between clouds.