Task 2.3: Establishing private connectivity.

• AResolve *.googleapis.com on premises to private.googleapis.com

  Incorrect

  private.googleapis.com also serves APIs that VPC Service Controls does not support, which the requirement forbids.

• BResolve *.googleapis.com on premises to restricted.googleapis.com

  Correct

  restricted.googleapis.com points to 199.36.153.4/30 and serves only APIs supported by VPC Service Controls.

• CAdvertise 199.36.153.4/30 from Cloud Router to the on-premises routers

  Correct

  A custom route advertisement tells the on-premises routers that the restricted range is reached through the interconnect.

• DEnable Private Google Access on the subnet that the Interconnect's VLAN attachment uses

  Incorrect

  The subnet setting covers VMs in that subnet; on-premises hosts depend on DNS and route advertisements instead.

• EDeploy Cloud NAT in the region so that the on-premises servers' API calls leave through Google's addresses

  Incorrect

  Cloud NAT sends traffic to the internet, the opposite of keeping API calls on the private interconnect path.

Private Google Access for on-premises hosts works through two virtual IP ranges. restricted.googleapis.com (199.36.153.4/30) serves only APIs that VPC Service Controls supports, and private.googleapis.com (199.36.153.8/30) serves most Google APIs. On-premises DNS must map the API names to the chosen range, and Cloud Router must advertise that range over the VPN or interconnect.

• ANothing, because Google encrypts all traffic on Dedicated Interconnect links by default

  Incorrect

  Traffic on Cloud Interconnect is not encrypted by default; that is the reason MACsec and HA VPN over Interconnect exist.

• BHA VPN over Cloud Interconnect, with enough IPsec tunnels to carry the firm's peak traffic

  Incorrect

  HA VPN over Interconnect does encrypt the traffic, but it is the IPsec tunnel design the network team refuses.

• CMACsec for Cloud Interconnect

  Correct

  MACsec encrypts traffic at layer 2 between the firm's routers and Google's edge routers, on 10-, 100- and 400-Gbps circuits, without IPsec tunnels.

• DPartner Interconnect through a provider whose network encrypts traffic between its sites

  Incorrect

  Changing to a partner connection does not by itself encrypt the link, and the provider's own encryption is outside the firm's control.

Cloud Interconnect gives private connectivity but does not encrypt traffic by itself. MACsec for Cloud Interconnect encrypts it at layer 2 between the on-premises router and Google's peering edge router, while HA VPN over Cloud Interconnect adds IPsec tunnels for organizations that need IPsec.

• AExternal IP addresses on each VM, with a firewall rule that denies all ingress traffic

  Incorrect

  Giving each VM an external address adds addresses to register and leaves the VMs one firewall mistake away from being reachable.

• BPrivate Google Access on the VMs' subnet, so that downloads use Google's network

  Incorrect

  Private Google Access reaches Google APIs and services only, not a third-party repository.

• CPublic NAT with automatic IP address allocation for the VMs' subnet

  Incorrect

  Automatically allocated NAT addresses can change as Cloud NAT scales, so the vendor's allowlist would break.

• DPublic NAT for the VMs' subnet, with manually assigned regional external IP addresses

  Correct

  Cloud NAT gives outbound access only, and manually assigned addresses stay fixed so they can be registered with the vendor.

Public NAT lets VMs without external IP addresses make outbound connections to the internet and accept only the responses, never new inbound connections. With manual NAT IP address assignment, the company controls exactly which external addresses its traffic uses.

• AA Private Service Connect endpoint for Google APIs, using the vpc-sc bundle

  Correct

  PSC endpoints for Google APIs use a global internal address that the customer chooses, and the vpc-sc bundle includes only services that VPC Service Controls supports.

• BA Private Service Connect endpoint for Google APIs, using the all-apis bundle

  Incorrect

  The all-apis bundle includes APIs that VPC Service Controls does not support, which the requirement forbids.

• CPrivate Google Access on every subnet, with DNS pointing to the default public API addresses

  Incorrect

  Private Google Access uses the default or fixed Google addresses, not an address from the bank's plan.

• DPrivate services access, with an allocated range peered to Google's service producer network

  Incorrect

  Private services access connects to managed services such as Cloud SQL over peering; it is not how Google APIs are reached.

Private Service Connect can create an endpoint for global Google APIs with an internal IP address of the customer's choice. The endpoint targets an API bundle: all-apis for most Google APIs, or vpc-sc for those that VPC Service Controls supports.

• AClassic VPN with route-based tunnels to both devices

  Incorrect

  Classic VPN does not offer the 99.99% SLA that HA VPN provides.

• BA tunnel from each of the HA VPN gateway's two interfaces

  Correct

  The 99.99% SLA requires a tunnel from both interfaces of the HA VPN gateway to the peer gateway.

• CStatic routes on each tunnel, so that no routing protocol is needed

  Incorrect

  HA VPN supports only dynamic routing; static routing is for Classic VPN.

• DA single tunnel with a larger maximum transmission unit for throughput

  Incorrect

  One tunnel is a single point of failure and does not meet the SLA requirements.

• EBGP sessions on a Cloud Router for every tunnel

  Correct

  HA VPN uses dynamic routing, with a Cloud Router running BGP over each tunnel.

HA VPN gateways have two interfaces, and the 99.99% availability SLA on the Google Cloud side requires a tunnel from each interface to the peer. HA VPN supports only dynamic routing, so a Cloud Router exchanges routes with the peer over BGP on every tunnel.

• AA public IP address on the instance, with each team's NAT addresses listed as authorized networks

  Incorrect

  Any public IP exposes the instance to the internet path, which the requirement forbids.

• BPrivate services access in one network, with that network peered to the other two

  Incorrect

  Private services access is based on VPC Network Peering and allows connections from only one VPC network; reaching it from the other two would need additional configuration.

• CPrivate Service Connect for the instance, with an endpoint in each team's network

  Correct

  Google recommends Private Service Connect for Cloud SQL: it can serve several VPC networks through their own endpoints without peering.

• DThe Cloud SQL Auth Proxy on each application host, connecting to the instance's public IP address

  Incorrect

  The Auth Proxy secures and authorizes connections, but over a public IP the instance still has an internet-facing address.

Cloud SQL offers two private IP options. Private services access, the earlier one, uses VPC Network Peering and allows connections from one VPC network. Private Service Connect lets several VPC networks, including cross-project ones, connect through endpoints; Google recommends it and makes it the default private option for new projects.

• AVPC Network Peering between the two networks, with firewall rules that allow only the API's port

  Incorrect

  Peering cannot connect networks with overlapping subnet ranges, and it exposes routes to the whole network.

• BA published service with a service attachment, and an endpoint on the consumer side

  Correct

  With Private Service Connect, the consumer reaches only the published service through an endpoint address in its own network, even when the two networks' ranges overlap.

• CAn HA VPN connection between the two networks, with custom route advertisements for the API's subnet

  Incorrect

  VPN routing also struggles with overlapping ranges and connects networks rather than a single service.

• DA Shared VPC that both organizations' projects attach to as service projects

  Incorrect

  Shared VPC attaches service projects from the host's own organization, apart from temporary migration cases, and it shares whole subnets rather than one service.

Private Service Connect lets a service producer publish a service behind an internal load balancer through a service attachment. Consumers in other projects or organizations create endpoints with internal addresses in their own networks, so the networks need no peering, their ranges may overlap, and only the published service is exposed.