Exam objective 7.2 asks you to prove you can see what’s happening inside a Google Cloud network — not just that data flows, but how well it flows, where it breaks, and why. Without monitoring and logging, you’re driving a lorry with a blacked-out windscreen; you know you’re moving, but you have no idea if you’re about to hit a pothole or run out of fuel. For the PCNE exam, this means you need to explain how to collect, visualise, and alert on network metrics (like packet loss or latency) and how to analyse logs (like firewall denies) to diagnose problems.
Jump to a section
A simple way to picture Network Monitoring with Cloud Monitoring and Logging
A restaurant kitchen’s exhaust hood is the central nervous system for air quality and fire safety. It doesn’t just suck air — it monitors smoke levels, grease buildup, and airflow speed, sending real-time data to a control panel in the manager’s office. If a pan catches fire, the hood’s sensors detect the temperature spike and automatically activate the suppression system, while logging the exact time, temperature, and which burner was involved. The head chef can later review that log to identify which cook frequently leaves pans unattended, or notice that the grease filter needs changing every Tuesday because smoke levels peak during lunch rush.
The sous-chef doesn’t stand under the hood all day — she watches the dashboard on a tablet. The hood is Cloud Monitoring, tracking metrics like smoke density (packet loss), airflow speed (bandwidth utilisation), and filter pressure (CPU load). The log of every alarm and fan speed change is Cloud Logging. If the kitchen runs two hoods (one for each stove), each with independent controllers, the sous-chef can compare their performance or see why the left stove’s hood triggered more alerts — diagnosing a clogged duct (a misconfigured firewall rule) without ever climbing a ladder.
This analogy maps directly to network observability: the hood’s sensors are VPC flow logs, the dashboard is Cloud Monitoring’s Metrics Explorer, the log is Cloud Logging’s log viewer, and the manager’s review identifies recurring patterns (a slow database that spikes traffic every 3 hours), just as a network engineer uses these tools to catch a burst of dropped packets from a satellite link.
Network monitoring and logging are the two halves of observability — the ability to understand a system’s internal state by examining its outputs. In Google Cloud, these are provided by two services: Cloud Monitoring (formerly Stackdriver Monitoring) and Cloud Logging (formerly Stackdriver Logging).
Cloud Monitoring collects numeric data points called metrics. A metric is a measurement over time, like the number of packets sent through a VPN tunnel, error count for a load balancer, or latency between two VM instances. Metrics are gathered from Google Cloud services automatically (CPU utilisation, network bytes sent) or from your own applications via the Monitoring API or the Ops Agent. These metrics are stored in a time-series database, meaning every data point has a timestamp and a value. You can view them on dashboards, set alerting policies (e.g., fire an email when latency exceeds 200ms), and use Metrics Explorer for ad-hoc charting.
Cloud Logging, on the other hand, collects textual log entries. A log entry is a record of an event: a timestamp, a severity level (INFO, WARNING, ERROR), and a payload (the details). Examples include a VPC flow log showing a TCP connection from IP A to IP B, a firewall rule denying a packet, or a router sending a BGP status update. Logs are stored in buckets, and you can filter them by resource type (e.g., GCE VM instance), log name, or labels. You can also export logs to BigQuery for SQL analysis, to Cloud Storage for long-term archiving, or to Pub/Sub for real-time streaming.
For network observability specifically, two log sources are crucial: VPC flow logs and firewall rules logs. VPC flow logs capture metadata about all IP traffic passing through a VPC network — source and destination IPs, ports, protocol, direction, and whether the packet was allowed or denied by firewall rules. Firewall rules logs record every time a firewall rule is evaluated and the action taken (allow or deny). Together, these let you trace exactly who is talking to whom, through which ports, and whether the traffic was permitted.
Why does this exist? Before cloud, network engineers used specialised hardware probes (like Cisco NetFlow) and syslog servers to gather similar data. In Google Cloud, these capabilities are built-in and managed, meaning you don’t provision or maintain collection servers — you just enable the feature (with a few clicks or an API call). This replaces hours of configuration with a single toggle, but it also introduces new concepts like latency budgets, metric thresholds, and log sinks.
The three core concepts to understand are:
Metric: a quantifiable measurement (e.g., bytes sent per second).
Log entry: a record of an event (e.g., “firewall rule ‘allow-ssh’ matched and allowed TCP/22 from 192.0.2.1”).
Alerting policy: a rule that says “if metric X exceeds threshold Y for Z minutes, notify P via email/SMS/PagerDuty.”
When studying for PCNE, you must know how to enable VPC flow logs (they must be enabled on a subnet level, not globally), how to set up log-based metrics (a way to count specific log entries as numeric metrics), and how to use the Metrics Explorer to chart latency between Google Cloud and on-premises locations using latency-location capability within Service Monitoring.
Enable VPC Flow Logs on a Subnet
Navigate to VPC networks in the Google Cloud Console, select a subnet, and edit it to enable VPC flow logs. This captures metadata about every IP packet flowing through that subnet — source/dest IP, ports, protocol, and whether it was allowed or denied by firewall rules. Without this step, you cannot analyse traffic patterns or debug connectivity issues within that subnet.
Create a Log Sink to Export Firewall Rules Logs
Go to Cloud Logging → Logs Router, create a sink that selects firewall rules logs (with a filter like `resource.type=”gce_firewall_rule”`) and routes them to a destination (e.g., BigQuery). This allows you to run SQL queries on firewall activity over time, essential for auditing and compliance.
Build a Cloud Monitoring Dashboard with Network Metrics
Open Cloud Monitoring → Dashboards → Create Dashboard, add charts for ‘VPC Flow Logs — Packets Sent’ and ‘Load Balancer — Request Latency’. This gives a real-time view of network health. You can choose line charts or bar charts and filter by VM group or subnet.
Set a Metric Threshold Alert for High Latency
Define an alerting policy in Cloud Monitoring that triggers if load balancer latency exceeds 200ms for five consecutive minutes. Specify notification channels (email, SMS, webhook). This replaces manually watching dashboards — you get alerted before users notice slowness.
Create a Log-Based Metric to Track Denied Packets
In Cloud Logging, create a log-based metric that counts VPC flow log entries with `action=DENY`. Then create an alert on that metric (e.g., more than 50 denies per minute). This lets you detect scanning attacks or misconfigurations without exporting logs to BigQuery.
Debug an Application Using VPC Flow Logs and Cloud Monitoring Gauge Metrics
When users report a connection failure, filter VPC flow logs by the source IP and time range. Check if the action is DENY. Then check Cloud Monitoring’s gauge metric for ‘CPU utilisation’ on target VMs to rule out resource exhaustion. This combined approach pinpoints firewall blocks vs. application overload.
Imagine you are the sole network engineer for a mid-sized e-commerce company, QuickCart, that runs its website on Google Compute Engine VMs. One morning, customers complain that the checkout page is slow. You need to find the bottleneck without logging into every VM manually.
First, you open Cloud Monitoring and look at the Load Balancer dashboard. You see a chart titled ‘Request Latency’ — the time between a customer sending a request and the load balancer forwarding it to a backend VM. The chart shows a sudden spike starting at 09:05 AM, climbing from 50ms to 500ms. You also see a ‘Backend Error Count’ metric spiking at the same time. This tells you the load balancer is healthy but the backends are having issues.
Next, you open Cloud Logging and filter by resource type ‘GCE VM Instance’ and severity ‘ERROR’. You see thousands of log entries from one specific VM named ‘checkout-backend-03’: they all say ‘Connection refused on TCP port 8080’. The firewall rules logs show that a new rule deployed at 09:00 AM accidentally removed the allow rule for TCP/8080 from the designated subnets.
To verify, you create a chart in Metrics Explorer with ‘VPC flow logs’ metric ‘packets_sent’ for the subnet hosting checkout-backend-03, grouped by destination port. You see traffic to port 8080 dropped to zero after 09:00 AM, while traffic to other ports remained stable. You now have definitive proof: a firewall rule change killed the port.
Finally, you revert the firewall rule, then create an alerting policy that triggers if ‘VPC flow log denied packets’ increase by 50% in 5 minutes. This way, if a similar mistake happens again, you’ll get a notification before customers complain. You also export firewall rules logs to BigQuery so you can run weekly compliance reports: for example, which rules are being hit the most, and whether any rules are unused (allowing traffic that shouldn’t exist).
This workflow — monitor, log, alert, analyse — is exactly what PCNE expects you to build. The exam will present scenarios like this and ask which tools you use (Cloud Logging vs. Cloud Monitoring), what metric type (gauge vs. delta vs. cumulative), or how to enable a particular log source.
The PCNE exam tests objective 7.2 in several predictable ways. You will face questions that require you to distinguish between Cloud Monitoring (metrics and alerts) and Cloud Logging (logs and sinks). A common trap question presents a problem that sounds like it needs logs, but the answer actually requires a metric-based alert (e.g., “how do you get notified when latency exceeds 100ms?” — answer: create a metric threshold alert, not a log-based alert).
Specific topics you must memorise:
VPC flow log fields: source IP, destination IP, source port, destination port, protocol, direction, action (ACCEPT/DENY), and the hierarchy of enabling them (at subnet level only; you cannot enable per-VM).
Log sinks: you can export logs to BigQuery, Cloud Storage, Pub/Sub, or another logging project. The exam loves asking about sender vs. receiver projects for aggregating logs from multiple projects into a central logging project.
Metric type: gauge (point-in-time value like current CPU utilisation), delta (change over a time window like bytes sent per second), and cumulative (running total like total bytes sent since boot). They will ask which type to use for a given scenario.
Log-based metrics: a powerful feature that counts log entries matching a filter. For example, you can create a metric that counts every log line containing ‘ERROR’ from a specific VM group. You can then alert on that numeric metric.
Latency budgets: part of Service Monitoring, where you define a baseline latency (e.g., 95th percentile under 200ms) and get alerts when actual latency exceeds the budget.
Agent-based vs. agentless monitoring: the Ops Agent (formerly Cloud Monitoring agent) collects metrics from inside VMs (e.g., disk I/O, process memory). Agentless monitoring comes from the hypervisor (e.g., CPU utilisation). The exam asks which methods collect which data.
Trap patterns include:
Confusing a ‘log sink’ with a ‘log viewer’ — they are different features.
Thinking VPC flow logs are enabled by default — they are not; you must enable them on each subnet.
Assuming you can monitor on-premises servers without the Ops Agent — you need the agent installed on those servers to forward metrics/logs.
Omitting the fact that log-based metrics are always numeric counters — you cannot create a metric that captures a text value like the source IP from a log entry (you must use log filters for that query).
The correct answer pattern for alerting questions is almost always: ‘Create a metric threshold alert based on the MQL query’ or ‘Create a log-based metric and then an alert on that metric’. For log analysis, the answer is ‘Use Cloud Logging query with the correct filter’ or ‘Create a log sink to BigQuery for SQL analysis’.
You should also know the Cloud Logging query language basics: severity>=ERROR, resource.type=‘gce_instance’, jsonPayload.message like ‘%timeout%’, and how to use the has operator for optional fields.
Cloud Monitoring handles numeric metrics (like latency or packet loss) and alerting; Cloud Logging handles textual log entries (like firewall denies or app errors).
VPC flow logs must be enabled per subnet — they do not work on a per-VM or global basis, and they are turned off by default.
Log-based metrics convert a log entry pattern into a numeric count that can be used in a Cloud Monitoring alerting policy.
Log sinks can export logs to BigQuery, Cloud Storage, Pub/Sub, or another logging project — never to Cloud SQL or Cloud Spanner directly.
For PCNE, you must know the four metric types: gauge (point-in-time), delta (change over interval), cumulative (running total), and util (percentage utilisation).
Firewall rules logs record evaluation events (rule name, action, connection metadata), not every individual packet — use VPC flow logs for per-packet details.
These come up on the exam all the time. Here's how to tell them apart.
VPC Flow Logs
Records per-packet metadata (source IP, dest IP, ports, protocol).
Enabled per subnet, not per VM or firewall rule.
Captures both allowed and denied traffic actions.
Firewall Rules Logs
Records only when a firewall rule is evaluated (connection-level event).
Enabled per firewall rule in the rule’s logging configuration.
Logs the rule name and action, not individual packet counts.
Cloud Monitoring
Handles numeric time-series metrics (e.g., CPU, latency, packet counts).
Uses dashboards for visualisation and alerting policies for notifications.
Data is ingested via the Monitoring API or Ops Agent.
Cloud Logging
Handles textual log entries (e.g., error messages, firewall events).
Uses the Logs Explorer for filtering and analysis, not dashboards.
Data is ingested from services automatically or via agent-configurable logging.
Gauge Metric
Represents a value at a single point in time (e.g., current CPU utilisation 72%).
Does not change unless the metric is re-sampled.
Useful for alerting on thresholds like high memory usage.
Delta Metric
Represents a change over a specified time interval (e.g., bytes sent per second).
Always resets after each measurement window.
Useful for understanding rate of traffic or errors.
Mistake
Cloud Monitoring and Cloud Logging are the same service — they just show data in different formats.
Correct
They are separate services with distinct purposes: Cloud Monitoring handles numeric metrics and alerts, while Cloud Logging handles textual log entries and exports. You can create log-based metrics that bridge them, but they are not interchangeable.
Google’s Stackdriver legacy bundled them under one console, making beginners think one service does everything. The exam explicitly asks you to pick the correct service for a task.
Mistake
VPC flow logs are enabled on every network by default.
Correct
VPC flow logs are disabled by default on every subnet. You must manually enable them per subnet. There is no global toggle to turn them on for all subnets at once.
Beginners assume Google Cloud would enable logging automatically to help users, but flow logging generates additional costs, so it’s opt-in.
Mistake
Log-based metrics can be used to alert on the exact text of a log entry (like the source IP from a denied packet).
Correct
Log-based metrics only count occurrences of log entries matching a filter — they produce a numeric counter, not the captured text values. To extract a specific field (like source IP), you must export logs to BigQuery and query there.
The term ‘log-based metric’ sounds like it extracts content from logs, but it’s just a counter. Beginners often confuse this with log filtering and analysis.
Mistake
Firewall rules logs record every packet that matches a rule, showing all traffic allowed or denied.
Correct
Firewall rules logs only record the evaluation event when a rule is matched — they log the rule name, action, and the connection’s source/destination, but not every single packet. For all packet metadata, you need VPC flow logs.
The word ‘log’ suggests detailed per-packet recording, but firewall rules logs are connection-level events, not packet-level. Beginners conflate the two log sources.
Mistake
You can create a log sink to export logs to a Cloud SQL instance for analysis.
Correct
Log sinks export logs only to BigQuery, Cloud Storage, Pub/Sub, or another logging project (for aggregation). Cloud SQL is not a valid destination for log sinks.
Beginners think any database is a valid target because they want to store logs for custom analysis, but Cloud SQL is not designed for log ingestion and isn’t an option.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
VPC flow logs capture metadata for every IP packet (source, dest, protocol, action) passing through a subnet. Firewall rules logs record when a firewall rule is evaluated and what action it took (allow/deny). You need both for full visibility.
Use Cloud Monitoring to create a metric threshold alert on the metric ‘vpn/tunnel/status’ — it will be 1 when up and 0 when down. You cannot use logs for this because tunnel status is a numeric metric, not a log entry.
Yes, by creating a log sink with destination Pub/Sub. Your Pub/Sub subscription can push messages to a Splunk HTTP Event Collector or any webhook receiver. This is common for enterprise security operations.
Confirm you enabled flow logs on the subnet level — not the network level. Also, logs only appear if there is actual traffic. For test environments, generate traffic by pinging between VMs in that subnet. Check the log name: compute.googleapis.com/vpc_flows.
Yes, they become numeric counters available in Cloud Monitoring. You can chart them on dashboards and use them as the basis for alerting policies. They are listed under the metric type ‘logging/user/your_metric_name’.
Create a log sink to Cloud Storage with the storage class Archive. This costs very little for long-term storage, but you cannot query them directly — you’d need to load them into BigQuery for analysis. For frequent queries, use BigQuery directly.
You've finished Network Monitoring with Cloud Monitoring and Logging. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?