Implementing a Virtual Private Cloud practice questions

Set up VPC peering between the two regions.

Why wrong: VPC peering is used between separate VPCs, not within the same VPC.

No additional configuration is needed because internal IPs are routable within the VPC.

Why wrong: While internal IPs are routable, firewall rules must permit the traffic. Default rules allow it, but if custom rules are applied, they may block it.

Enable Cloud NAT for the VPC.

Why wrong: Cloud NAT is for internet access, not internal communication.

The rule must be applied using network tags on instances in Subnet-A.

Why wrong: Incorrect. While network tags can be used to target firewall rules, they are not required. The rule can target instances based on service accounts or IP ranges.

The rule must be an ingress rule with source set to Subnet-A IP range and destination set to Subnet-B IP range.

Why wrong: Incorrect. Ingress rules do not have a destination field; the destination is the instances to which the rule applies via targets. The condition as stated is invalid.

The rule must also allow return traffic from Subnet-B to Subnet-A.

Why wrong: Incorrect. Google Cloud firewall is stateful, so return traffic for allowed connections is automatically handled. No separate rule is needed.

A custom route must be added to route between subnets.

Why wrong: No custom routes are needed; VPC automatically routes within the network.

A firewall rule must be added to allow traffic between subnets.

Why wrong: Default firewall rules already allow internal traffic.

VPC peering is required for communication between subnets.

Why wrong: VPC peering is for connectivity between different VPCs, not within the same VPC.

Use VPC subnet secondary IP ranges.

Why wrong: Secondary IP ranges are for additional IP space, not for access control.

Use VPC Network Tags on the VM instances.

Why wrong: Tags are for firewall rule targeting, not for controlling subnet usage by projects.

Use VPC firewall rules with service accounts to restrict access.

Why wrong: Firewall rules control network traffic, not subnet assignment permissions.

Create a private services access connection.

Why wrong: Incorrect: Private services access is used for accessing Google-managed services like Cloud SQL and Cloud Memorystore, not for enabling Private Google Access.

Create a Cloud NAT.

Why wrong: Incorrect: Cloud NAT is not required for Private Google Access; it is used for outbound internet connectivity without public IPs, but Private Google Access uses the default route.

Enable VPC flow logs.

Why wrong: Incorrect: VPC flow logs are used for logging and monitoring network traffic, but they are not required for Private Google Access.

Multi-Exit Discriminator (MED) on the Google Cloud side.

Why wrong: Multi-Exit Discriminator (MED) is used to influence inbound traffic to the on-premises network, not outbound traffic from on-premises to Google Cloud. It is set by the Google Cloud side, not the on-premises side.

Static routes pointing to the VPC subnet in each region.

Why wrong: Static routes do not consider dynamic latency measurements and would not automatically route to the nearest region. BGP dynamic routing is required for this scenario.

BGP AS Path prepending to make one path appear longer.

Why wrong: AS Path prepending is typically applied by the route advertiser (Google Cloud) to make a path appear longer. The on-premises router cannot effectively use AS Path prepending to influence its own outbound path selection; local preference is the appropriate attribute.

Assign a static internal IP address and use it as the public IP via DNS.

Why wrong: Internal IP addresses are not directly accessible from the internet.

Configure Cloud NAT to assign a static IP for inbound traffic.

Why wrong: Cloud NAT is used for outbound internet access, not for assigning static public IPs for inbound traffic.

Use the instance's internal IP address as the public IP by configuring the VPC firewall.

Why wrong: An instance's internal IP cannot be used as a public IP via VPC firewall configuration.

Use a Shared VPC with separate subnets in different projects for each tier.

Why wrong: Shared VPC is for multi-project environments, not for tier isolation within one organization.

Use a single VPC and connect the database tier via Cloud VPN to on-premises.

Why wrong: Cloud VPN does not address isolation between tiers within a VPC.

Use a single VPC with separate subnets for each tier and configure firewall rules to restrict traffic.

Why wrong: Single VPC does not provide network isolation at the VPC level; firewall rules alone can be misconfigured.

Custom mode subnet

Why wrong: Custom mode gives full control but requires manual range expansion.

Dynamic subnet

Why wrong: No such subnet mode exists in Google Cloud.

Legacy network

Why wrong: Legacy networks are deprecated and not recommended.

Create the subnet with primary range 10.0.2.0/24 and then update it to add the secondary range.

Why wrong: Subnets cannot be updated after creation to add secondary ranges.

Create two subnets: one with 10.0.2.0/24 for primary and another for the secondary range.

Why wrong: Secondary ranges are part of the same subnet, not separate subnets.

Create an auto mode subnet and let Google Cloud assign the secondary range automatically.

Why wrong: Auto mode does not automatically assign secondary ranges.

Cloud NAT

Why wrong: Cloud NAT provides internet access for private instances, not VPN routing.

VPC peering

Why wrong: VPC peering connects two VPC networks directly, but it does not terminate an on-premises VPN tunnel or support BGP session establishment with an external gateway. The scenario requires a Cloud VPN gateway with dynamic routing, which VPC peering cannot provide. This option is tempting because VPC peering is commonly used to link separate networks, and one might mistakenly think it can extend connectivity to an on-premises site; it would be correct only for connecting two Google Cloud VPCs without VPN or on-premises involvement.

VPC Flow Logs

Why wrong: Flow Logs record traffic metadata, not routing.

Configure Cloud NAT for the VPC.

Why wrong: Cloud NAT provides outbound internet, not inbound.

Enable Private Google Access on the subnet.

Why wrong: Private Google Access is for accessing Google APIs, not for general internet inbound.

Assign a static internal IP address to the VM.

Why wrong: Internal IP is not needed for inbound internet access.

Cloud VPN

Why wrong: Cloud VPN is for connecting on-premises, not for multi-project VPC.

VPC peering

Why wrong: VPC peering is not needed when using Shared VPC.

Use Dedicated Interconnect with VLAN attachments to the SaaS provider.

Why wrong: Dedicated Interconnect is a direct physical connection, not IPsec VPN, and may not be supported by the SaaS provider.

Deploy a Classic VPN tunnel with policy-based routing.

Why wrong: Classic VPN does not support BGP dynamic routing, so failover is not automatic.

Deploy a single Cloud VPN tunnel and use static routing.

Why wrong: Static routing does not support automatic failover; single tunnel is a single point of failure.

Use Cloud DNS with geo-routing to direct users to regional load balancers.

Why wrong: DNS-based routing does not provide the performance of proximity-based anycast on Google's network; it also has caching issues.

Set up Cloud NAT with multiple static IP addresses for each region.

Why wrong: Cloud NAT is for outbound traffic only, not for inbound user traffic.

Assign a global anycast IP address to all instances and use BGP to advertise it.

Why wrong: Global anycast IP addresses are not supported in Google Cloud for direct instance assignment; BGP advertising is not possible.

The subnet IP range overlaps with the on-premises network.

Why wrong: Default VPC uses Auto mode subnets with non-overlapping ranges; overlap is unlikely but would cause routing issues, not firewall.

The instance has IP forwarding disabled.

Why wrong: IP forwarding is required only for instances acting as routers, not for general communication.

The default VPC does not have a default route to the internet.

Why wrong: Default VPC has a default route (0.0.0.0/0) to the internet via the default internet gateway.

Use VPC Network Peering between two different VPCs.

Why wrong: Peering adds a slight overhead; same VPC is better.

Place instances in different VPCs and use a VPN between them.

Why wrong: VPN adds encryption overhead and extra latency.

Assign external IP addresses to both instances and communicate over the internet.

Why wrong: External IPs traverse the internet gateway, increasing latency.

Cloud DNS forwarding zone to forward requests to Google APIs' public DNS.

Why wrong: Private Google Access does not require DNS changes; it works with standard DNS resolution.

Firewall rule allowing ingress from on-premises to 0.0.0.0/0.

Why wrong: Firewall rules need to allow only the specific Google API IP ranges, not all destinations.

Cloud NAT configured in the VPC.

Why wrong: Cloud NAT is not required for private Google Access; it is for internet access.

The service account 'app-sa' does not have permissions to send traffic through the VPN.

Why wrong: Service accounts do not control network traffic; firewall rules do.

IAP is blocking traffic from the app tier because it is not configured for that subnet.

Why wrong: IAP is used for SSH access, not for general traffic to on-premises.

The Cloud Router is not advertising the 10.0.2.0/24 subnet to on-premises.

Why wrong: The Cloud Router is configured to advertise all subnets, so 10.0.2.0/24 should be advertised.

Set up a Cloud VPN tunnel with Cloud Router and use BGP to advertise routes between the two regions.

Why wrong: Incorrect. Cloud VPN with BGP is designed for hybrid cloud or multi-network connectivity, not for optimizing routing within the same VPC. It adds latency and cost without benefit.

Create a VPC peering connection between the frontend and backend VPCs.

Why wrong: Incorrect. VPC peering connects separate VPC networks; the frontend and backend are already in the same VPC, so peering provides no advantage.

Enable Cloud CDN on the backend load balancer to cache database responses.

Why wrong: Incorrect. Cloud CDN caches static content from HTTP(S) load balancers; it cannot cache database responses or reduce latency for dynamic queries.