Professional Cloud Network Engineer — Quick review

Memory hook: Global network, regional subnet, deliberate boundaries.

Must remember

• A Google VPC is global; subnets are regional. Plan non-overlapping ranges for VMs, GKE Pods/Services, managed services and hybrid networks before deployment; reserve growth and check quotas.
• Shared VPC centralizes network administration in a host project while service projects consume permitted subnets. Network administration and subnet-use permissions are different responsibilities.
• VPC Network Peering connects compatible networks but is not automatically transitive. Network Connectivity Center (NCC) supports managed hub/spoke connectivity; Private Service Connect (PSC) exposes supported services through consumer endpoints rather than merging entire networks.
• Private Google Access enables eligible internal-only workloads to reach Google APIs. Private services access uses allocated ranges and service networking; PSC is a different connection model. VPC Service Controls restrict supported service data movement, not ordinary packet routing.
• Premium versus Standard Network Service Tiers affect traffic paths and supported load-balancer designs. Select regional/global behavior explicitly; public IP ownership does not remove egress charges.
• Plan IPv6, MTU, BYOIP or privately used public space only with supported combinations. Subnet expansion can be possible, but overlapping ranges and unsupported shrink operations complicate recovery.

Choose under exam pressure

Traps

• VPC peering does not create a general transit network.
• Private Google Access is not identical to private services access.

Practise this topic

Memory hook: Address allocation first; route selection second.

Must remember

• Routes determine next hops; firewall rules determine permitted traffic. Evaluate route applicability, destination specificity and the documented priority rules for the route type rather than comparing all numbers as one flat list.
• Cloud Router learns and advertises routes using BGP; regional/global dynamic routing mode controls where learned routes are available. It is a control-plane service, not the device through which every data packet passes.
• NCC connects VPC, hybrid and supported producer spokes. Mesh and star topologies, route filters, PSC propagation and Private NAT must match the intended reachability; inspect advertised and accepted prefixes.
• VPC-native GKE uses alias IP ranges for Pods and Services. Plan primary/secondary ranges, additional Pod ranges, Shared VPC permissions, IPv6 support and node-pool growth.
• Private nodes and private/control-plane access are separate choices. Authorized networks and DNS-based control-plane endpoints address access differently; verify the chosen endpoint’s identity and network requirements.
• GKE Dataplane V2, NetworkPolicy, IP masquerade/SNAT settings and DNS choices affect Pod traffic. Use kube-dns/Cloud DNS and NodeLocal DNSCache as appropriate; a healthy node does not prove Pod DNS or policy is correct.

Review details

Custom route exchange across peering is explicit, and imported routes do not automatically turn a peer into a transit router. Route selection considers applicability and route category before the relevant prefix/priority rules. Policy-based routes can direct matching traffic to a supported internal load-balancer next hop; appliance health and a correct return path remain essential.

For Shared VPC GKE, check the service project and required service-agent/subnet permissions as well as the network administrator. Pod IP exhaustion can happen even when CPU quota is healthy. Inspect masquerade policy when the observed source address differs from the expected Pod address.

Choose under exam pressure

Traps

• Creating a Cloud Router without a BGP peer does not establish hybrid connectivity.
• A private cluster is not automatically inaccessible to every authorized management path.

Practise this topic

Memory hook: Protocol, exposure, scope, backend.

Must remember

• Choose load balancing by application versus network protocol, proxy versus passthrough, internal versus external, and regional versus global scope. These choices determine supported backend and traffic behavior.
• Application Load Balancers use HTTP-aware routing such as URL maps, host/path rules, redirects and supported traffic splitting/mirroring. Network load balancers address transport-level needs; passthrough preserves different connection properties than a proxy.
• Backend services reference supported managed instance groups or network endpoint groups. Health checks, firewall allowances, balancing capacity, timeouts, draining and session affinity must all agree.
• GKE Gateway/Ingress controllers create managed traffic resources from Kubernetes configuration; container-native NEGs can route to Pod endpoints. Debug both Kubernetes objects and cloud backend health.
• Cloud CDN caches supported origins, including backend buckets and compatible services/NEGs. Cache keys, TTLs, signed access and invalidation determine correctness; never cache personalized content under a shared key accidentally.
• Cloud DNS public zones require registrar delegation; private zones need authorized networks. Forwarding, peering zones, inbound policies and cross-project bindings solve hybrid resolution; avoid forwarding loops and verify return routes.

Review details

Cloud DNS routing policies include supported weighted, geolocation and failover choices. They influence DNS answers, while resolvers cache by TTL and existing sessions can persist. DNSSEC signs authoritative data to support authenticity/integrity validation; it does not encrypt DNS. Correct parent DS records are part of the trust chain; an incorrect DS during migration can cause validation failure even when ordinary records look right.

The external-dns controller can reconcile supported DNS records from Kubernetes resources; use scoped DNS permissions and a clear ownership policy to avoid competing controllers. DNS peering shares resolution from another network; it is not the same as VPC Network Peering exchanging packet routes.

Choose under exam pressure

Traps

• A DNS zone existing in a project does not mean every VPC can resolve it.
• Session affinity is a performance/behavior setting, not durable state storage.

Practise this topic

Memory hook: Two paths, two failure domains, one tested plan.

Must remember

• HA VPN uses IPsec tunnels and Cloud Router BGP. Meet the documented redundant interface/tunnel topology for the desired availability; one working tunnel is not proof of a resilient design.
• Dedicated Interconnect provides physical connectivity; Partner Interconnect uses a supported provider; Cross-Cloud Interconnect addresses supported cloud-to-cloud connectivity. VLAN attachments connect the service to VPC routing.
• Interconnect is not inherently equivalent to encrypted application traffic. Evaluate MACsec support for link encryption and HA VPN over Interconnect for IPsec, alongside TLS at the application layer.
• Design independent edge locations, devices and attachments for the required SLA. Account for maintenance, regional failure, capacity during failover, BGP advertisements and route preference.
• Direct Peering/Verified Peering Provider access to Google services is different from private VPC hybrid connectivity. Choose based on the actual destination and supported service.
• NCC hybrid spokes integrate supported tunnels, attachments or appliances. Plan non-overlapping prefixes or supported Private NAT, and test hybrid DNS plus access to Google APIs through the chosen private/restricted path.

Review details

BGP recall: ASN identifies the autonomous system, peer addresses identify the session, authentication protects the configured exchange, and advertised prefixes/route attributes influence usable paths. MED affects comparable path preference; VPC best-path mode (legacy versus standard) changes relevant selection behavior. Custom advertisements do not prove the peer accepted or prefers them.

BFD on Cloud Router is supported for qualifying Dedicated/Partner Interconnect VLAN-attachment BGP sessions, not HA VPN or router-appliance sessions. It accelerates forwarding-path failure detection and needs compatible peer settings. Do not assume every BGP connection supports it.

Classic VPN includes legacy static route/policy designs; HA VPN uses dynamic BGP. For Interconnect, use the vendor's exact 99.9%/99.99% redundancy topology—including independent locations/devices and adequate surviving capacity—rather than memorizing “two links” without failure-domain context.

Choose under exam pressure

Traps

• A private circuit does not automatically encrypt every byte.
• A redundant cloud side cannot compensate for one failing on-premises router.

Practise this topic

Memory hook: Filter packets, protect apps, inspect egress.

Must remember

• VPC firewall rules are stateful and use direction, protocol, ports, targets and sources/destinations. Hierarchical and network firewall policies add organization-wide structure; understand policy evaluation and delegation before migration.
• Cloud NGFW Essentials/Standard/Enterprise expose different capabilities. Select threat intelligence or deeper inspection only when required; use supported secure tags/service-account targeting for segmentation rather than unmaintained IP lists.
• Cloud Armor protects supported load-balanced traffic with WAF rules, rate limits and other protections. Edge/backend policy placement matters; tune SQLi/XSS rules in preview before blocking legitimate traffic.
• Public Cloud NAT enables supported outbound connections for internal-only resources without accepting unsolicited inbound sessions. Monitor ports and address capacity; static versus dynamic port allocation affects scaling and exhaustion.
• Secure Web Proxy applies supported outbound web controls. It is distinct from Cloud NAT address translation and from an inbound WAF.
• Use supported multi-NIC appliances, policy-based routes or internal load-balancer next hops for inline inspection. Packet Mirroring copies traffic to collectors for out-of-band analysis; copies do not block the original flow.

Review details

Firewall selection depends on effective hierarchical, network and VPC policy evaluation, not simply the lowest number found anywhere. Within a rule model, direction, targets, matching source/destination, protocol and priority determine eligibility. Secure tags have an IAM-controlled governance model distinct from ordinary network tags; inventory labels are not automatically traffic selectors.

Cloud Armor rule preview helps assess WAF/rate/bot rules before enforcement. Supported Adaptive Protection and advanced DDoS capabilities depend on service/tier and traffic path. NAT port allocation or address exhaustion causes outbound failures even when firewall and route are valid; monitor dropped/error signals and per-VM port use.

Choose under exam pressure

Traps

• Cloud NAT is not an inbound firewall-opening mechanism.
• An out-of-band collector cannot block packets merely by observing them.

Practise this topic

Memory hook: Name, route, policy, session, application.

Must remember

• Start with source, destination, protocol, port, time and expected path. Resolve DNS, inspect routes and return routes, then evaluate firewall policy and service/backend health.
• VPC Flow Logs provide sampled/aggregated flow visibility; firewall logs explain logged rule decisions; NAT, DNS, VPN, Router and load-balancer logs reveal different layers. Absence in a sampled log is not proof no packet existed.
• Connectivity Tests analyzes supported configuration paths and can provide supported live data-plane verification; it is not a universal packet capture. Network Analyzer finds configuration issues; Firewall Insights highlights rule behavior.
• Network Topology visualizes connections/traffic; Performance Dashboard shows latency/loss; Flow Analyzer explores flow records. Use the tool that answers the specific hypothesis.
• For hybrid incidents, separate physical/link state, tunnel state, BGP session state, advertised prefixes, MTU and application health. For load balancers, inspect frontend, URL map, backend health and draining separately.
• Monitor baseline latency, loss, throughput, NAT ports, tunnel availability and errors. Capture packets only with authorization and controlled retention because payloads can contain sensitive data.

Choose under exam pressure

Traps

• A successful ping does not prove TCP/HTTPS is permitted.
• Flow logs do not replace complete packet capture when exact payload evidence is required.

Practise this topic