Google Professional Cloud Network Engineer 1-10

By default, GKE performs SNAT (source NAT) on egress traffic from Pods destined for RFC 1918 private ranges outside the cluster (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), translating the source IP to the node’s IP.
To reach 192.168.0.0/24 using the node’s source IP, this default SNAT must remain in effect.
By keeping the Pod range within 10.0.0.0/8 (an RFC 1918 range different from the destination) and not setting the –disable-default-snat flag, GKE performs SNAT so that the node’s IP becomes the source.
If you set the flag, the Pod’s own IP becomes the source, which does not meet the requirement.
GKE documentation – IP masquerade agent

For an instance without an external IP to reach Google APIs such as BigQuery and Cloud Storage, you must provide an egress path.
Private Google Access is configured per subnet and cannot be set at the whole-VPC level, so the correct approach is to enable it on all subnets.
This allows access to Google APIs without an external IP.
Alternatively, creating a Cloud NAT and routing traffic through the NAT gateway achieves egress without assigning an external IP.
Option B has the wrong configuration unit for Private Google Access, Option C’s Private Services Access is for managed services, and Option D’s peering cannot be used against BigQuery.
VPC documentation – Private Google Access

Hierarchical firewall policies are centrally managed at the organization or folder level and cannot be overridden by lower-level rules.
To delegate only intra-VPC decisions to each business unit, set the action to “goto_next” for traffic matching that VPC’s private CIDRs, which hands off evaluation to the lower-level VPC firewall rules.
Then, with the lower-priority rule blocking other sources, you can cut off communication between VPCs.
Option C’s “allow” makes the decision final at that point and does not delegate to the business unit.
Options A and B use per-VPC rules that the business units can change, so they do not provide centralized blocking.
Cloud NGFW documentation – Hierarchical firewall policies

To route only a specific instance’s traffic through the appliance, create a custom route more specific than the system-generated subnet route, with the next hop set to instance-B.
By setting the network tag applied to instance-A on that route, you can limit its scope to instance-A only and avoid affecting other instances.
The system-generated subnet route cannot be deleted, so Option C is not possible; tagless Option A affects all instances; and Option D is an overly complex configuration that is unnecessary for this requirement.
VPC documentation – Routes

To exchange routes dynamically between on-premises and Google Cloud, use BGP.
By creating a Cloud Router, adding a VPN tunnel, and configuring a BGP session, route information is automatically exchanged between the two environments.
Global dynamic routing is a setting for the VPC’s route-propagation mode across the entire VPC, and is not the direct step that establishes the dynamic exchange itself.
Option D’s static routes do not provide dynamic exchange.
Option B does not require a second HA VPN gateway and does not meet the requirement.
Cloud VPN documentation – Creating HA VPN

Even within the same VPC, you can distinguish production from non-production by subnet IP range.
By creating two IP-range-based access levels and binding each to a perimeter with an ingress policy, you can limit the production subnet to the production buckets only and the non-production subnet to the non-production buckets only, achieving this without significantly changing the existing configuration.
Options B, C, and D involve deleting perimeters, creating new VPCs, or migrating workloads, so they require significant effort and struggle to meet the isolation requirement.
VPC Service Controls documentation – Access levels

To increase Cloud VPN bandwidth, provide multiple tunnels and distribute traffic across them using ECMP (equal-cost multi-path).
By adding a second on-premises gateway with a different public IP and creating a second tunnel on the existing Cloud VPN gateway that forwards the same IP ranges, you can distribute load across multiple tunnels and expand bandwidth.
Option A’s MTU change does not increase bandwidth.
Simply adding to the same destination IP or moving to another region is a configuration for redundancy and is not suited to this bandwidth-expansion requirement.
Cloud VPN documentation – Classic VPN topologies

By creating a Google Group and granting IAM roles to that group, you can centrally manage permissions, and since the same group also functions as an email distribution list, you can integrate permission management and email distribution most efficiently.
Adding and removing members is reflected in both simply through group operations.
Creating a domain as in Options B and C is excessive and unnecessary for centralizing permissions and distribution for a single team.
Option D’s custom role is a definition of permissions and does not contribute to centralizing email distribution.
IAM documentation – Access control with groups

The 10 Gbps and lowest-latency requirements call for Dedicated Interconnect.
By adopting a Shared VPC and consolidating the Dedicated Interconnect and VLAN attachment in the host project, a single interconnect can be shared by all service projects, providing connectivity to each department most cost-effectively while centralizing network management.
Having a separate interconnect per project as in Options C and D leads to duplicate investment, is inefficient, and violates the centralized-management requirement.
Cloud Interconnect documentation – Using interconnects with other projects

Cloud Armor security policies are applied to load balancers.
In GKE, the Ingress resource provisions an external Application Load Balancer, so you use GKE Ingress (associated via BackendConfig) as the target of the Cloud Armor policy.
Nodes, Pods, and clusters are not load balancers, so they cannot be targets for Cloud Armor.
You configure this by combining GKE’s default Ingress controller with the security policy.
GKE documentation – Ingress features