Professional Cloud Network Engineer
VPC Flow Logs records network flow samples across Virtual Private Cloud (VPC) networks to help engineers monitor traffic, perform security forensics, and optimize network costs. Flow logs capture traffic associated with VM instances, Google Kubernetes Engine nodes, Cloud Run Direct VPC egress, and Cloud Interconnect or Cloud VPN VLAN attachments. The logging process begins with packet sampling, aggregates those packets over a configurable interval between 5 seconds and 15 minutes, and then applies an optional secondary sampling rate. For outbound traffic, packets are sampled before egress firewall rules evaluate them, which allows administrators to log denied egress attempts. In contrast, inbound traffic is sampled after ingress firewall rules evaluate them, meaning denied ingress traffic is never recorded in VPC Flow Logs.
Cloud NAT provides managed network address translation and exports operational logs to Cloud Logging to assist with capacity planning and connection troubleshooting. Administrators can configure Cloud NAT logging to record successful address translations, connection drop errors caused by port exhaustion, or both events simultaneously. Each VM instance operates under a rate limit for log generation that scales in proportion to its assigned vCPU count, which prevents excessive logging traffic. In a Shared VPC architecture, users must hold the roles/monitoring.viewer role in the service project to view VM-level metrics in Cloud Monitoring, whereas viewing NAT gateway-level metrics requires the same role in the host project.
Cloud DNS query logging records name resolution requests directly to Cloud Logging to help diagnose name resolution failures and audit domain policy enforcement. Network administrators configure query logging on DNS zones to capture client lookups, response codes, and resolution errors. To support long-term analysis, centralized auditing, or external SIEM ingestion, teams create Cloud Logging sinks to export telemetry to BigQuery, Pub/Sub, or Cloud Storage. Aggregated sinks configured at the organization level can automatically capture and route DNS and network logs across all underlying folders, projects, and billing accounts into a single destination.
Cloud Next Generation Firewall (Cloud NGFW) provides distributed stateful protection and Layer 7 packet inspection across organization, folder, and VPC network hierarchies. Firewall rules are enforced immediately at the virtual interface layer, securing VM instances even while they are still booting. Cloud NGFW Enterprise includes intrusion prevention capabilities that route traffic through Google-managed zonal firewall endpoints using packet intercept technology. These endpoints inspect data streams for active threat signatures, such as malware, spyware, and command-and-control activity, and generate security logs when threats are identified or blocked.
Firewall Rules Logging audits the evaluation of individual VPC firewall rules by recording every connection decision for both ingress and egress directions. When an allowed connection matches an enabled rule, the system emits a single log entry upon connection establishment. When a packet matches a deny rule, the system generates repeated log entries every 5 seconds for as long as that denied connection attempts to send packets. Each log entry records the rule action, the matching rule name, and the source and destination IP addresses and transport ports.
Firewall Insights analyzes historical firewall evaluation logs using machine learning to detect misconfigurations, optimize rule strictness, and surface packet-drop signals. The service automatically identifies shadowed rules, which are lower-priority rules whose attributes are entirely overlapped and superseded by higher-priority or equal-priority rules. Firewall Insights calculates shadowed rules within 24 hours after an administrator enables Firewall Rules Logging on the relevant rules. Deny rule insights examine dropped packet patterns over a default 24-hour observation window to help administrators distinguish intentional security blocks from network configuration mistakes.
VPC Service Controls establishes security perimeters around sensitive Google-managed services, such as Cloud Storage and BigQuery, to prevent data exfiltration. The service denies API requests to protected resources whenever those calls originate outside the authorized perimeter boundary or from unapproved environments. Cloud Logging records both dry-run evaluations and active perimeter violation audit logs. Security teams inspect these audit logs to identify unauthorized egress attempts, verify access patterns, and refine ingress and egress perimeter rules before enforcing them in production.
Cloud VPN exports Internet Key Exchange (IKE) control plane events to Cloud Logging under the vpn_gateway resource type to assist with tunnel negotiation diagnostics. During Phase 1 negotiations, administrators inspect log entries such as initiating IKE_SA or establishing IKE_SA failed, peer not responding to isolate connectivity issues with the remote peer. Successful Phase 1 negotiations generate logs showing pre-shared key authentication and IKE_SA established between endpoints. Phase 2 negotiations track CHILD_SA lifecycle events, where log warnings like Remote traffic selectors narrowed indicate mismatched encryption subnets, and DELETE for ESP CHILD_SA records unexpected tunnel teardowns.
Cloud Router manages dynamic routing across hybrid connections by establishing Border Gateway Protocol (BGP) peering sessions and logging route state transitions. Setting the VPC dynamic routing mode to global propagates learned hybrid routes to subnets across all regions, while setting it to regional restricts dynamic routes strictly to the local region. Administrators configure base advertised route priorities on BGP sessions to control traffic paths: identical priorities establish an active-active equal-cost multi-path (ECMP) architecture, while differing priorities establish an active-passive failover routing path. When route propagation issues occur, administrators verify custom route advertisements and inspect Cloud Router status using the routers.getRouterStatus API method.
Network Connectivity Center (NCC) manages wide-area enterprise connectivity by organizing external sites and VPC networks into a centralized hub and attached spokes. To enable data transit between non-Google Cloud sites over the Google network backbone, administrators must set the site-to-site data transfer setting to true on each hybrid spoke. When software-defined wide area network (SD-WAN) systems attach using Router appliance spokes, BGP peering must use internal RFC 1918 IP addresses instead of link-local 169.254.x.x addresses. Each Router appliance requires two separate BGP sessions targeting distinct Cloud Router interfaces, and VPC firewall rules must permit ingress TCP traffic on port 179.
Network Intelligence Center Connectivity Tests uses an abstract state machine to evaluate packet forwarding paths across VPC networks, Cloud VPN tunnels, and Cloud Interconnect attachments. The diagnostic engine traces configuration paths to determine whether traffic drops originate from missing routes or restrictive firewall rules. Connectivity Tests analyzes the Google Cloud side of the path and assumes external on-premises configurations are functioning correctly. Combining Connectivity Tests with VPC Flow Logs and Network Topology telemetry provides complete visibility into bandwidth consumption and packet drop locations across hybrid network topologies.
Cloud Load Balancing is a fully distributed, software-defined managed service that routes traffic to backend services based on health checks, request volume, and latency distributions. The external Application Load Balancer and internal Application Load Balancer both require manual enabling of logging, which records information about requests processed by the load balancer including backend health, latency, and error rates. When configuring load balancer logging, the sampling rate should be set to 1 during active tuning and implementation of Cloud Armor, then reduced after configuration is complete. Backend service health monitoring involves examining whether backend VMs or endpoints are responding to health checks, with unhealthy backends causing the load balancer to redirect traffic to healthy instances.
Google Cloud Armor is a DDoS protection and web application firewall (WAF) service that inspects incoming requests at Google's global edge before they reach backend services. Cloud Armor includes built-in WAF rules that scan for common web attacks such as cross-site scripting (XSS) and SQL injection (SQLi), along with an ML-based Adaptive Protection system that builds models of normal traffic to detect anomalies. Security policy logs are exposed in the Google Cloud console under the network_security_policy resource rather than under the load balancer resource. When analyzing Cloud Armor logs, administrators can determine whether dropped packets are expected security protections or unexpected issues caused by misconfigurations.
Cloud NAT is a fully managed network address translation service that enables Compute Engine VMs and GKE clusters without external IP addresses to initiate outbound connections to the internet or other VPC networks. Cloud NAT logging must be explicitly enabled for each gateway, with options to log only errors or to log all translation events including source IP, destination IP, ports, and bytes transferred. Port allocation metrics show how many NAT ports are in use versus available, while error metrics indicate translation failures caused by port exhaustion or configuration issues. When Cloud NAT encounters port allocation errors, it typically results in connection failures for affected VMs attempting to reach external destinations.
Network Intelligence Center provides a single console for managing network visibility, monitoring, and troubleshooting across Google Cloud networking resources. The Performance Dashboard displays network performance metrics for the entire Google Cloud network and project resources, enabling administrators to distinguish between application-level problems and underlying network issues. Connectivity Tests analyze network configurations and can perform live data plane analysis to validate connectivity and provide baseline diagnostics for latency and packet loss. Firewall Insights within Network Intelligence Center uses machine learning to analyze firewall rule usage, predict future rule utilization, and identify overly permissive rules that should be tightened. Network Analyzer continuously monitors VPC network configurations, detects misconfigurations, and correlates failures with recent configuration changes to identify root causes.
Troubleshooting network operations using log analytics involves using Google's logging and analysis tools to investigate connectivity issues, validate configurations, and trace packet flows across hybrid and cloud networks. A network engineer correlates data from multiple log sourcesālike VPC Flow Logs, firewall rule logs, and Cloud Router logsāto identify the root cause of problems such as misconfigured routes, blocked traffic, or unexpected packet drops.
VPC Flow Logs records a sampled summary of network flows sent from and received by VM instances, including traffic through VLAN attachments and Cloud VPN tunnels. It logs all egress traffic and ingress traffic that is permitted by an allow firewall rule, but it does not log ingress traffic blocked by a deny rule. Flow logs are aggregated by connection at 5-second intervals and exported to Cloud Logging. Because enabling VPC Flow Logs generates substantial data volume, you should enable it selectively on specific subnets, not on development subnets for sustained periods. You use VPC Flow Logs to verify if traffic is entering or leaving a VM through the expected port, which is foundational for network monitoring, forensics, and expense optimization.
Firewall Rules Logging is a feature you enable per firewall rule to audit, verify, and analyze the effects of that rule, regardless of its action (allow or deny) or direction (ingress or egress). This logging generates detailed connection data, which incurs a cost, so you must plan carefully which rules to monitor. The logs help you determine if a deny rule is functioning as intended or how many connections a rule affects. You can export firewall logs to a central sink for an organization-wide view and use filters within Cloud Logging to search for specific firewall events, correlating them with VPC Flow Logs to trace why packets were dropped.
Network Intelligence Center provides integrated tools that use logged data for deeper analysis. Its Flow Analyzer module lets you perform opinionated traffic analysis using VPC Flow Logs data stored in a log bucket without writing complex SQL queries; it analyzes traffic with 5-tuple granularity (source/destination IP/port and protocol) for monitoring, troubleshooting, and security compliance. The Firewall Insights module analyzes Firewall Rules Logging data to provide reports on firewall usage, detect rules shadowed by higher-priority rules, and offer packet-drop signals to distinguish between expected security blocks and unexpected misconfigurations. Connectivity Tests acts as a static configuration analyzer, simulating packet paths through your VPC, VPN tunnels, and VLAN attachments to identify root causes like blocked firewall rules, complementing live log data.
Alerting in Google Cloud provides timely notifications for out-of-policy events. You can use Cloud Asset Inventory real-time notifications to monitor deviations in resource configurationsālike firewall or forwarding rule changesāwhich send immediate alerts via Pub/Sub. Complement this by creating Cloud Logging sinks that filter calls to sensitive actions (like SetIamPolicy) and trigger Cloud Run functions via Pub/Sub for automated response. For permission-related access problems, use Policy Troubleshooter alongside Cloud Audit Logs to verify IAM roles and permissions, ensuring you have the required viewer roles to access logs and exported data for troubleshooting.
Monitoring hybrid connectivity performance and availability requires tracking telemetry across physical circuits, encrypted tunnels, dynamic routing sessions, and data plane paths. Google Cloud provides visibility into hybrid connections through Network Intelligence Center, Cloud Logging, and service-specific performance metrics.
Cloud VPN telemetry provides real-time data on tunnel state, data throughput, and cryptographic negotiation events. Administrators monitor bandwidth utilization by examining ingress bytes count and egress bytes count over time series charts in Network Topology to isolate bandwidth bottlenecks. Correlating tunnel issues requires querying specific string events in Logs Explorer under the resource.type="vpn_gateway" resource type. Administrators diagnose IKE failures by searching for Phase 1 events, such as "initiating IKE_SA", "establishing IKE_SA failed, peer not responding", or authentication outcomes. Data plane establishment and renegotiation are verified through Phase 2 Child Security Association messages. Active path verification requires structured ICMP testing between internal endpoints, and pings must originate from a Compute Engine VM instance rather than the Cloud VPN gateway itself to validate end-to-end connectivity.
Cloud Interconnect health monitoring assesses physical circuits, virtual connections, and data transfer capacity across Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect. On physical Dedicated Interconnect or Cross-Cloud Interconnect links, administrators inspect the Receiving Optical Power field in the Google Cloud console to ensure the value reports OK, confirming light signal integrity. Physical circuit capacity is monitored on single or bundled 10-Gbps and 100-Gbps links up to platform limits.
Logical connectivity depends on VLAN attachments, where administrators monitor the operational state (Up or Down) and bandwidth capacity utilization ranging from 50 Mbps to 50 Gbps. Each attachment requires a unique /29 subnet allocated from 169.254.0.0/16, where one address is assigned to Cloud Router and one to the peer router; configuring a /30 subnet instead of a /29 is a common configuration error that interrupts link availability. The Maximum Transmission Unit (MTU) size must match across the on-premises router, the VLAN attachment, and the VPC network to prevent packet fragmentation or drops. Performance and latency benchmarks across VLAN attachments must be conducted using a VM instance located in the VPC network running throughput measurement tools, not the Cloud Router link-local IP address.
Cloud Router diagnostics track dynamic routing states and prefix propagation to ensure uninterrupted traffic forwarding across hybrid attachments. A healthy BGP session shows an operational status of Up on both Google Cloud and the on-premises or remote cloud peer. BGP sessions require TCP port 179 to be allowed through all firewall layers, with matching autonomous system numbers (ASNs) configured between local and peer routers. Multi-hop BGP must be enabled with a minimum of two hops on on-premises routers connected over Partner Interconnect Layer 2 circuits. For deployments utilizing a Router appliance within Network Connectivity Center, Cloud Router peers using RFC 1918 internal addresses within the VPC subnet rather than link-local addresses. Cloud Router establishes two separate BGP sessionsāone from each interfaceāto a single Router appliance instance, and both sessions must advertise matching routes to avoid asymmetric routing issues. Route availability requires setting the VPC dynamic routing mode to global if routes must propagate across multiple Google Cloud regions.
Network Intelligence Center provides centralized monitoring, diagnostic simulations, and network-wide performance metrics across all hybrid connections. Network Topology correlates Google Cloud metrics with real-time operational data, allowing operators to visually track ingress and egress traffic volumes, verify cross-region throughput, and detect overloaded links. Connectivity Tests analyzes configurations using an abstract state machine to simulate the forwarding path of packets through VPC networks, Cloud VPN tunnels, and VLAN attachments without sending live traffic. For supported paths, Connectivity Tests also conducts live data plane analysis to generate baseline diagnostics for latency and packet loss. Because Connectivity Tests cannot access routers outside Google Cloud, traffic entering from on-premises environments is modeled as valid, focusing its analysis on internal VPC routing tables, Cloud NGFW firewall rules, and policy-based routes. Performance Dashboard provides historical and real-time visibility into packet loss and latency across the Google Cloud global network and project-level resources.
StudyCerts
StudyCerts169.254.0.0/16; using a /30 subnet is a common configuration error that interrupts link availability.VPC Flow Logs intercepts outbound packets before they reach egress firewall rules, allowing the system to log denied egress attempts. Inbound packets are evaluated by ingress firewall rules before reaching the sampling point, so blocked ingress packets are dropped prior to log collection.
An active-active configuration uses identical base advertised route priorities across multiple BGP sessions, distributing traffic using equal-cost multi-path (ECMP) routing. An active-passive configuration assigns different priorities across BGP sessions, directing all primary traffic to the path with the most preferred priority and using the alternate path strictly for failover.
Dry-run logs record perimeter violations in Cloud Logging without actually blocking the API request. This allows security administrators to test and verify perimeter rules against live workloads, identifying legitimate traffic patterns that need to be permitted before enabling active enforcement.
The Cloud Router link-local IP (169.254.x.x) is part of the control plane and its processing produces unpredictable results for ICMP ping times, latency, and MTU limits. Always test performance from a VM instance inside the VPC network using throughput measurement tools.
Pings must originate from a Compute Engine VM instance inside the VPC network, not from the Cloud VPN gateway itself. This validates the full path including internal firewall rules and route tables. External IP pings between gateway endpoints only test public reachability, not the encapsulated tunnel.
Prepare and test your skills
Prepare and test your skills