Overview
This section moves from building networks to keeping them healthy. Logging and monitoring cover enabling and reading logs for Cloud VPN, Cloud Router, Cloud NGFW and Cloud NAT, and watching metrics for VPN tunnels, Interconnect and VLAN attachments, Cloud Router, load balancers, Cloud Armor and Cloud NAT in Cloud Monitoring.
Troubleshooting tasks include draining and redirecting traffic on Application Load Balancers, managing VPN tunnels, fixing Interconnect and BGP peering faults, and analyzing VPC Flow Logs, firewall logs and Packet Mirroring captures. Network Intelligence Center supplies the diagnostic tools: Network Topology for traffic flows, Connectivity Tests for route and firewall analysis, Performance Dashboard for packet loss and latency, Firewall Insights for rule usage, Network Analyzer for configuration problems and Flow Analyzer for querying flow logs.
How it's tested
Troubleshooting questions give a symptom, such as dropped connections, a tunnel down, a BGP session flapping or traffic taking an unexpected path, and ask for the tool or data source that identifies the cause. Some ask for the operational action that avoids impact during maintenance.
-
Pick the diagnostic tool
You match the symptom to Connectivity Tests, VPC Flow Logs, firewall logs, Packet Mirroring or a Network Intelligence Center module.
-
Read the metric
You decide which Cloud Monitoring metric or log entry shows tunnel status, BGP state, NAT port exhaustion or backend latency.
-
Change safely
You drain backends, shift traffic or adjust weights so maintenance or migration does not drop live sessions.
Users report that a VM cannot reach a database in a peered VPC. Before capturing packets, you run a Connectivity Test between the two internal IPs. It reports that an ingress firewall rule with priority 900 denies the port. The test analyzes configuration without sending traffic, so it finds the cause quickly and points to the exact rule to change.
Objectives 3
Official objectives from the Google Cloud outline, in outline order.
5.1 Logging and monitoring with Google Cloud ObservabilityNetwork component logs and monitoring metrics in Cloud Logging and Cloud Monitoring.
- What it means
- This objective covers turning on and reading logs from networking components, including Cloud VPN, Cloud Router, Cloud NGFW and Cloud NAT, and monitoring metrics for VPN tunnels, Interconnect and VLAN attachments, Cloud Router, load balancers, Cloud Armor and Cloud NAT.
- What to understand
- Some logs exist by default, such as Cloud VPN and Cloud Router events, while others must be enabled: firewall rule logging per rule or policy, Cloud NAT logging for translations or errors, load balancer request logging with a sample rate and Cloud DNS query logging through a server policy. Useful metrics include tunnel established status and dropped packets, VLAN attachment capacity and link state, BGP session status, load balancer latency and backend errors, Cloud Armor allowed and denied request counts and Cloud NAT port allocation and dropped sent packets. Alerting policies turn these metrics into notifications.
- How it shows up
- Expect questions on which log must be enabled first or which metric reveals a problem early.
- Common confusion
- Firewall rule logging is off by default and is enabled per rule, not per VPC.
5.2 Maintaining and troubleshooting connectivity issuesDraining traffic, VPN and Interconnect issues, BGP peering problems, and logs and packet capture.
- What it means
- This objective covers keeping connectivity working during change and failure: draining and redirecting traffic on Application Load Balancers, managing and fixing VPN tunnels, troubleshooting Interconnect and VLAN attachments, diagnosing Cloud Router BGP peering, and using VPC Flow Logs, firewall logs and Packet Mirroring.
- What to understand
- Connection draining on a backend service lets existing requests finish before a backend is removed. VPN tunnel failures often come from mismatched IKE versions, shared secrets, cipher settings or traffic selectors on policy-based peers. BGP sessions stay down when ASNs, link-local addresses or MD5 keys do not match, or when on-premises firewalls block TCP port 179. Interconnect problems show as link or optical alerts, or attachments waiting for the partner. VPC Flow Logs sample flows per subnet; Packet Mirroring copies full packets to a collector for deep analysis.
- How it shows up
- Scenarios include a down tunnel, a session that will not establish or an intermittent drop to diagnose.
- Common confusion
- Flow logs show sampled connection records, not packet payloads; Packet Mirroring captures payloads.
5.3 Using Network Intelligence Center to monitor and troubleshoot common networking issuesNetwork Topology, Connectivity Tests, Performance Dashboard, Firewall Insights, Network Analyzer and Flow Analyzer.
- What it means
- This objective covers the Network Intelligence Center modules: Network Topology to see throughput and flows, Connectivity Tests to diagnose route and firewall misconfiguration, Performance Dashboard for packet loss and latency, Firewall Insights to improve rules, Network Analyzer to spot failures and poor configurations, and Flow Analyzer to study VPC Flow Logs.
- What to understand
- Connectivity Tests run a configuration analysis between endpoints and report each hop and the rule or route that allows or drops traffic; for some paths they also send live probes. Performance Dashboard shows loss and latency between zones and to the internet, separating Google-side problems from your own. Firewall Insights reports shadowed rules, overly permissive rules and hit counts. Network Analyzer proactively flags issues such as IP exhaustion or misconfigured routes. Flow Analyzer queries flow logs with Log Analytics to show top talkers and traffic by dimension.
- How it shows up
- You will often choose one module from a short symptom description.
- Common confusion
- Connectivity Tests analyze configuration; Flow Analyzer examines traffic that actually occurred.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Connectivity Tests
Configuration analysis of a path between two endpoints.
- Remember
- Shows the exact route or firewall rule that blocks traffic.
- Tested as
- Reachability faults.
- Trap
- Capturing packets first.
-
Performance Dashboard
Packet loss and latency views for Google Cloud.
- Remember
- Separates Google-side issues from your configuration.
- Tested as
- Is it Google or us questions.
- Trap
- Opening a support case without data.
-
Firewall Insights
Analysis of firewall rule usage.
- Remember
- Finds shadowed and unused rules.
- Tested as
- Rule cleanup.
- Trap
- Deleting rules without usage data.
-
Network Analyzer
Automatic checks for misconfigurations.
- Remember
- Flags IP exhaustion and invalid routes.
- Tested as
- Proactive monitoring.
- Trap
- Waiting for user complaints.
-
Flow Analyzer
Queries VPC Flow Logs with Log Analytics.
- Remember
- Top talkers and traffic breakdowns.
- Tested as
- Traffic analysis.
- Trap
- Exporting logs to build custom reports.
-
Network Topology
Visual map of resources and traffic between them.
- Remember
- Shows throughput across regions and to the internet.
- Tested as
- Unexpected traffic patterns.
- Trap
- Using it to test reachability.
-
VPC Flow Logs
Sampled records of flows to and from VM interfaces.
- Remember
- Configurable sampling rate and aggregation interval.
- Tested as
- Traffic forensics.
- Trap
- Expecting packet payloads.
-
Firewall rule logging
Records connections matched by a rule.
- Remember
- Enabled per rule or policy rule.
- Tested as
- Proving a rule matched.
- Trap
- Assuming it logs implied rules.
-
Packet Mirroring
Copies packets to a collector behind an internal load balancer.
- Remember
- Full payload visibility.
- Tested as
- IDS and deep analysis.
- Trap
- Using it for routine traffic counts.
-
Connection draining
Timeout that lets in-flight requests finish.
- Remember
- Set on the backend service.
- Tested as
- Safe maintenance.
- Trap
- Deleting backends abruptly.
-
BGP session troubleshooting
Checks for down Cloud Router peers.
- Remember
- Match ASN, link-local IPs and MD5 key.
- Tested as
- Hybrid outages.
- Trap
- Blaming the VPN when IPsec is up.
-
Cloud NAT port exhaustion
VMs run out of NAT source ports.
- Remember
- Shows as dropped packets with OUT_OF_RESOURCES.
- Tested as
- Intermittent egress failures.
- Trap
- Adding firewall rules instead of ports or IPs.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Choosing a diagnostic data source
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Connectivity Tests | Simulates a path from configuration. | No live traffic needed. | Does not prove application health. |
| VPC Flow Logs | Sampled records of real flows. | Shows what actually happened. | Sampling can miss rare flows. |
| Firewall rule logs | Records rule matches. | Confirms which rule acted. | Must be enabled per rule. |
| Packet Mirroring | Full packet copies to a collector. | Payload inspection. | Costly for broad, continuous use. |
Network Intelligence Center modules
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Performance Dashboard | Loss and latency metrics. | Shows Google-wide and project views. | Not a reachability test. |
| Firewall Insights | Rule usage analysis. | Optimizes the rule set. | Does not block traffic itself. |
| Network Analyzer | Automatic misconfiguration findings. | Proactive, no setup per test. | Not a traffic analyzer. |
| Flow Analyzer | Flow log queries and charts. | Answers who talked to whom. | Requires flow logs enabled. |
Hybrid failure symptoms
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| VPN tunnel down | IKE or IPsec negotiation fails. | Check secrets, IKE version, ciphers and peer IP. | Changing BGP settings first. |
| BGP session down with tunnel up | Routing protocol cannot establish. | Check ASN, link-local IPs, MD5 and TCP 179. | Rebuilding the tunnel. |
| Attachment pending | VLAN attachment waits for partner activation. | Partner must complete provisioning. | Recreating the attachment. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Capture everything
- What candidates pick
- Enable Packet Mirroring on all subnets to find a blocked port.
- Why it looks right
- Packet captures feel definitive.
- Why it's wrong
- Connectivity Tests or firewall logs identify blocked ports faster and cheaper than full captures.
Clue to watch for A simple reachability failure between two known endpoints.
-
Flow logs for payload
- What candidates pick
- Use VPC Flow Logs to inspect HTTP headers.
- Why it looks right
- Flow logs record network traffic.
- Why it's wrong
- Flow logs contain connection metadata only; payload analysis needs Packet Mirroring.
Clue to watch for A requirement to inspect packet contents.
-
Blame Google first
- What candidates pick
- Open a support case at the first sign of latency.
- Why it looks right
- Cloud networks seem out of your control.
- Why it's wrong
- Performance Dashboard shows whether Google-side loss or latency exists before escalating.
Clue to watch for Latency affecting traffic between zones.
-
Rebuild the tunnel
- What candidates pick
- Delete and recreate a VPN tunnel whose BGP session is down.
- Why it looks right
- Rebuilding resets everything.
- Why it's wrong
- If IPsec is established, the fault is in BGP settings such as ASN, peer IP or MD5 key.
Clue to watch for Tunnel status shows established but no routes are learned.
-
More firewall rules for NAT drops
- What candidates pick
- Add egress allow rules when some VMs cannot reach the internet.
- Why it looks right
- Blocked egress sounds like a firewall issue.
- Why it's wrong
- Intermittent Cloud NAT drops usually mean port exhaustion; raise minimum ports, enable dynamic allocation or add NAT IPs.
Clue to watch for Failures only under high connection counts.
-
Delete unused rules blindly
- What candidates pick
- Remove firewall rules that look old.
- Why it looks right
- Cleanup reduces risk.
- Why it's wrong
- Firewall Insights hit counts and shadowed rule analysis show which rules are actually safe to remove.
Clue to watch for A request to tidy the rule set without breaking traffic.
Answer framework
Follow this order when an operations question describes a network symptom.
- Classify the symptom first: total loss of reachability, intermittent drops, high latency, or a hybrid link or BGP session that is down.
- For reachability faults, run Connectivity Tests first, then confirm the finding with firewall rule logs and VPC Flow Logs if more evidence is needed.
- For hybrid issues, separate tunnel or link state from BGP session state, then check that parameters match on both the Google and on-premises ends.
- For performance complaints, consult Performance Dashboard and load balancer latency metrics before proposing any change to the architecture.
- Reserve Packet Mirroring for payload-level analysis, and drain or shift traffic before any corrective change.
Practice question
Want more like this? The GCP PCNE practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this section as a tool-matching exercise. Make a two-column list with common symptoms on the left and the first tool or log to check on the right. Include blocked port, wrong path, tunnel down, BGP down, NAT drops, high latency and unknown traffic source.
Next, break things on purpose in a lab. Create a deny firewall rule and find it with a Connectivity Test. Enable firewall rule logging and flow logs, generate traffic, and query the results with Flow Analyzer. Change the BGP key on one side of an HA VPN lab and watch Cloud Router logs and metrics. Set a very low Cloud NAT minimum ports value, generate many connections and look for dropped packets.
Review the Performance Dashboard, Network Topology and Firewall Insights pages in a project with traffic. Close with scenario questions and time yourself, since this section rewards quick recognition of the right tool for each symptom.
FAQ
How much of the GCP PCNE exam is Managing, monitoring, and troubleshooting network operations?
Section 5 on managing, monitoring and troubleshooting carries about 14% of the exam. That is roughly 7 to 8 questions, as an editorial estimate.
What is the most useful troubleshooting tool to learn?
Connectivity Tests, because they quickly reveal which route or firewall rule allows or blocks a path. Pair them with VPC Flow Logs for evidence of real traffic.
Are VPC Flow Logs enabled by default?
No. You enable them, typically per subnet, and choose sampling rate, aggregation interval and metadata. Higher sampling gives more detail at higher cost.
What is Flow Analyzer?
It is a Network Intelligence Center module that queries VPC Flow Logs through Log Analytics to show traffic patterns such as top talkers without building custom queries.
How do I tell whether a problem is on Google's side?
Check Performance Dashboard for packet loss and latency across zones and regions. If it shows normal values, the problem is more likely in your configuration or application.
Does this section include Cloud Armor monitoring?
Yes. The guide lists Cloud Armor among the components whose metrics you should monitor, while configuring Cloud Armor policies belongs to Section 6.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
Test whether you can pick the right diagnostic tool and fix hybrid and reachability faults quickly in scenario questions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PCNE AI tutor Get any concept explained your way