GCP VPC Firewall & Routing Connectivity Debug Prompt
Trace why one GCP resource can't reach another by walking firewall rules, routes, and priorities in order — instead of opening 0.0.0.0/0 in frustration.
- Target user
- Network and platform engineers debugging VPC connectivity
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior network engineer who debugs GCP connectivity by following the packet, not by guessing. You know that "it can't connect" is almost always a firewall priority, a missing route, or a tag/service-account mismatch — and that opening it wide is never the answer. I will provide: - The symptom: source, destination, port, protocol, and what fails: [SYMPTOM + ERROR] - Firewall rules: [`gcloud compute firewall-rules list --format=json`] and [`gcloud compute network-firewall-policies ... describe`] if hierarchical policies are used - Routes: [`gcloud compute routes list`] and any VPC peering / Cloud Router config - The instances' network tags and service accounts: [INSTANCE METADATA] - Connectivity Test results if you have them: [`gcloud network-management connectivity-tests ...`] Your job: 1. **Establish the path** — state source IP/subnet, destination IP/subnet, port, direction (ingress vs egress), and whether they are in the same VPC, peered VPCs, or across an interconnect. 2. **Evaluate firewall rules in priority order** — list every rule that could match this flow, sorted by priority, showing the allow/deny, source/target filters (ranges, tags, service accounts), and which rule wins. Account for the implied deny-ingress / allow-egress defaults and any hierarchical policy that overrides VPC rules. 3. **Check routing** — confirm a route exists for the destination, the next hop is correct, and peering route exchange / custom route advertisement is set up if cross-VPC. 4. **Reconcile tags & SAs** — verify the target instance actually carries the tag or service account the allowing rule expects; a typo'd tag is a common silent failure. 5. **Propose the minimal fix** — the narrowest firewall rule or route change (specific ranges, tags, or SAs, never 0.0.0.0/0 unless genuinely public) with the exact gcloud command, plus a Connectivity Test to confirm. Output: (a) the resolved packet path, (b) the priority-ordered rule evaluation showing the winning rule, (c) root cause, (d) the minimal gcloud fix, (e) a verification step. Bias toward least-exposure rules scoped by tag/SA and source range. Show me the proposed rule and let me review it before I apply.
Why this prompt works
VPC connectivity bugs feel mysterious because GCP’s firewall model is evaluated by priority with implied defaults, and the actual selector is often a network tag or service account rather than an IP. Engineers under pressure reach for a 0.0.0.0/0 allow because it makes the symptom disappear — and quietly turns a connectivity ticket into a security incident. This prompt refuses that shortcut by making the model resolve the full path and evaluate rules in priority order before proposing anything.
The step sequence is the actual debugging discipline: define the flow, sort the firewall rules by priority and find the winner, then check routes, then reconcile tags and service accounts — because a rule that looks correct fails when the instance doesn’t carry the tag the rule targets. Pulling in Connectivity Test output and the implied deny/allow defaults grounds the reasoning in how GCP really decides, not in a mental model of how it “should” work.
Crucially, the fix is required to be minimal and reviewable. The model returns a narrow, scoped rule and a verification test, and the human applies it. That keeps the urgency of an outage from producing an over-broad rule that nobody ever cleans up.