Firewalls and Hierarchical Policies

Introduction to GCP Firewalling

Google Cloud gives you three distinct firewall surfaces — legacy VPC firewall rules, modern Network Firewall Policies (regional or global), and Hierarchical Firewall Policies at the organization or folder level — plus the higher-tier Cloud NGFW Enterprise which attaches Layer 7 intrusion prevention and URL/FQDN inspection via security profile groups. All four products inspect packets at the same place (the host kernel of the VM, before the virtual NIC), share the same stateful connection-tracking engine, and use the same priority integer space (0–65535 for rules, 0–2,147,483,647 for hierarchical policies), but they differ in scope, expressiveness, and price.

The PCNE exam frequently hands you scenarios like "centralise rules across 200 projects," "block access to *.cryptominer.example.com from compute workloads," or "allow traffic only from Japan and Singapore." Picking the wrong product wastes points. This note maps each scenario to the correct firewall surface with concrete gcloud syntax, evaluation-order traps, and the exact pricing/SKU implications that distinguish Cloud NGFW Standard from Enterprise.

Plain-Language Explanation: (Plain English Explanation)

Before drowning in priority integers, picture the GCP firewalling stack as three nested barriers around your VMs. Every packet must pass all three, and each barrier has its own owner, its own rule list, and its own "pass-through" verb.

Think of It as a Three-Door Apartment Complex

Imagine your VMs live in a luxury apartment complex. Hierarchical Firewall Policies are the front gate of the gated community, run by building management (org admins). They decide whether your delivery driver even gets onto the property — and they have a special verb, goto_next, that means "I personally have no opinion, ask the inner doors." Network Firewall Policies are the lobby door of your specific tower, managed by the floor supervisor (VPC admins). And legacy VPC firewall rules are the apartment-unit door, where you personally decide who comes in. The packet must be allowed by all three doors. The clever part: if the gate or the lobby says goto_next, the decision keeps rolling inward. If any door says deny, the packet dies immediately and the inner doors never see it.

Think of Priorities as a Numbered Ticket Line

Inside a single policy, rules are sorted by priority — and lower numbers go first, like a deli ticket machine where ticket #1 is served before ticket #65535. The first rule whose match conditions fit the packet wins; everything after it is ignored. This is first-match-wins, not best-match. Two consequences trip up exam candidates: (1) a deny rule at priority 1000 always beats an allow rule at priority 2000, and (2) the implied default rules sit at the very bottom (65535 for legacy, plus an organisation-wide implicit deny ingress and implicit allow egress), so your custom rules naturally override them.

Think of goto_next as the Receptionist Saying "Not My Decision"

In a corporate office, the receptionist might wave you through without checking your badge because the floor she works on is purely public — but each floor still has its own badge reader. goto_next is exactly that: a hierarchical or network policy rule can say "this matched, but I'm deferring the verdict to the next layer." It is not the same as allow — an allow short-circuits and lets traffic through, while goto_next only ends evaluation for the current policy and continues at the next one down the chain. This is the single most-tested trap in PCNE firewall questions.

Legacy VPC Firewall Rules

Legacy VPC firewall rules are the original GCP firewall product. They live inside a single VPC network, are stateful, and attach to VM NICs based on --source-ranges, --target-tags, or --target-service-accounts.

Priority Integer Space 0–65535

Each rule has a 32-bit-ish priority but the value range is 0..65535. Lower wins. Two implied rules always exist at priority 65535: an implied allow egress to 0.0.0.0/0 and an implied deny ingress from 0.0.0.0/0. You cannot delete them; you can only override them. A common production pattern is to add an explicit deny-all-egress at priority 65534 and then carve out allow-list exceptions at lower numbers like 1000 or 100.

Targets: Tags vs Service Accounts

A legacy rule can target VMs three ways:

• All instances in the network — no target specifier; broad and risky.
• Network tags — --target-tags=web,prod. Any user with compute.instances.setTags can attach themselves to a sensitive rule, which is why tags are an audit pain.
• Service accounts — [email protected]. Attaching a service account to a VM requires iam.serviceAccountUser, so this is the IAM-controlled hardened option.

A single rule may target either tags or service accounts, never both. Cross-project service-account targets work as long as the SA is in the same Org and is granted on the target project.

Stateful Connection Tracking

VPC firewalls are stateful: once an allow ingress is matched, the reverse-direction packets of the same flow are automatically permitted regardless of egress rules. Conntrack timeouts are 600 s for established TCP, 30 s for UDP, and they survive most short blips.

Network Firewall Policies (Regional and Global)

Network Firewall Policies are the next-generation product. Instead of writing rules on the VPC directly, you create a policy object and associate it to a VPC network (global policy) or to a region within a VPC (regional policy). Multiple VPCs can share the same policy.

Why They Replaced Legacy Rules

Network Firewall Policies add capabilities that legacy rules cannot express:

• FQDN match — dst-fqdn=storage.googleapis.com rather than IP ranges.
• Geolocation match — src-region-codes=JP,SG to allow only certain countries.
• Address groups — reusable named CIDR lists shared across rules.
• Threat-intel match — src-threat-intelligence=iplist-tor-exit-nodes to drop known-bad sources.
• Security profile groups — attach L7 IPS at Cloud NGFW Enterprise tier.
• Mirroring action — copy traffic to a Packet Mirroring sink in addition to allow/deny.

Legacy rules and network firewall policies can coexist on the same VPC; the merged evaluation order is described below.

Global vs Regional Scope

• Global Network Firewall Policy — gcloud compute network-firewall-policies create my-pol --global. Associates to a VPC network; rules apply to instances anywhere in any region within that VPC. One global policy per VPC at most.
• Regional Network Firewall Policy — gcloud compute network-firewall-policies create my-pol --region=us-central1. Associates to a (VPC, region) tuple; only affects instances in that region. One regional policy per (VPC, region).

A VPC can have both one global and one regional policy active simultaneously. Regional is evaluated before global within the network-firewall-policy layer.

Creating and Associating

gcloud compute network-firewall-policies create prod-global-pol --global \
  --description="prod global rules"
gcloud compute network-firewall-policies associations create \
  --firewall-policy=prod-global-pol --network=prod-vpc --global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=allow --layer4-configs=tcp:443 \
  --src-ip-ranges=10.0.0.0/8 --target-secure-tags=tagValues/123456789

Hierarchical Firewall Policies

Hierarchical Firewall Policies live at the organization or folder node of the GCP resource hierarchy. They are evaluated before any project-level rules and let security teams enforce non-bypassable guardrails across hundreds of projects.

Org-Level vs Folder-Level Attachments

A hierarchical policy is a global resource (gcloud compute org-firewall-policies create) that you then associate to one or more nodes: the organization itself, a folder, or even a single project. Inheritance is top-down: a policy attached to the org applies to every project under it; a policy attached to a folder applies to every project under that folder. Multiple hierarchical policies can stack — the org-level one evaluates first, then folder-level, then project-level network firewall policies, then legacy VPC rules.

Why Use Them Instead of Project-Level Rules

The classic answer is non-bypassable controls. A project owner can edit their own VPC firewall rules, but they cannot remove a hierarchical rule attached at the folder level — only a user with compute.orgFirewallPolicyAdmin at that folder or org node can. This is how regulated environments forbid SSH from the internet across an entire division: one deny ingress tcp:22 src=0.0.0.0/0 rule at the org node, with priority 100.

Limits to Remember

• Up to 2 hierarchical policies per node (one v1 plus one v2 during migration windows).
• Up to 200 rules per policy by default; raisable via quota.
• Targets are specified by secure tags or by target-resources (specific projects), since hierarchical policies don't have access to project-local network tags.

The goto_next Action and Evaluation Semantics

Both hierarchical and network firewall policies support three terminal actions: allow, deny, and goto_next. The third is the key to layered design.

What goto_next Actually Does

When a rule matches and its action is goto_next, evaluation stops in the current policy and jumps to the next firewall layer in the hierarchy. It does NOT continue to lower-priority rules in the same policy. So if your org-level policy has priority=100, match=10.0.0.0/8, action=goto_next and priority=200, match=10.0.0.0/8, action=deny, the packet matches priority 100 first and goes to the folder layer; the deny at priority 200 never fires.

Common goto_next Patterns

• Carve-out for trusted CIDRs at the org level: "if source is in our corporate office IP, goto_next so per-project rules can decide; otherwise apply org-wide deny rules."
• Compliance landing zone: org has deny ingress 0.0.0.0/0 tcp:22 priority=100. Folder for the security team has goto_next for SSH from the bastion subnet at priority 50 — but a folder rule alone can't override an org deny. The correct design is to put the bastion allow at the org level with a lower priority number than the deny.

Default Behaviour When No Rule Matches

If a policy is evaluated and no rule matches, evaluation implicitly falls through to the next layer — equivalent to goto_next with no match. This is why empty hierarchical policies are safe to attach during rollout.

FQDN Rules in Network Firewall Policies

Cloud NGFW supports matching on fully qualified domain names instead of static IPs, which is essential when whitelisting third-party SaaS endpoints that rotate their IPs daily (think *.googleapis.com, slack.com, package mirrors).

How FQDN Resolution Works

GCP performs DNS resolution on the data plane every few minutes (typically 30 s) using the VPC's configured resolver and the public DNS-over-HTTPS resolver at Google. The resolved IPs are cached in the rule's match set and refreshed on TTL expiry. You write dest-fqdns=*.googleapis.com,storage.googleapis.com and Cloud NGFW handles the rest.

Wildcards and Limits

A single FQDN match supports leading wildcards (*.example.com matches a.example.com and b.example.com but not example.com itself — add both if needed). Each rule may list up to 2,000 FQDNs, and the practical resolved-IP set per rule is capped at ~150,000 unique IPs. FQDN match works for IPv4 only at the moment of writing (IPv6 support is rolling out).

gcloud Example

gcloud compute network-firewall-policies rules create 2000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=EGRESS --action=allow --layer4-configs=tcp:443 \
  --dest-fqdns="*.googleapis.com,storage.googleapis.com" \
  --target-secure-tags=tagValues/data-pipeline

When FQDN Rules Don't Apply

FQDN rules require Cloud NGFW (the policy framework). Legacy VPC firewall rules cannot match FQDNs. If a question describes "block egress to a list of malicious domains using legacy gcloud compute firewall-rules create," the correct answer is "you can't — migrate to Network Firewall Policies first."

Geolocation Match and Threat Intelligence

Country-level match is a built-in capability of Network Firewall Policies that drops or allows traffic based on Google's geo-IP database.

src-region-codes and Use Cases

The match field src-region-codes=US,CA or dest-region-codes=CN,RU,IR uses ISO-3166-1 alpha-2 codes. Google updates the geo-IP mapping daily from MaxMind plus its own peering observations, so it lags real-time but is accurate to within 24 hours.

Typical scenarios:

• Block egress to embargoed countries — dest-region-codes=CU,IR,KP,SY,RU action=deny direction=EGRESS.
• Allow ingress only from home countries — src-region-codes=JP,TW action=allow plus an explicit deny of 0.0.0.0/0 at a higher priority number.

Threat Intelligence Lists

The src-threat-intelligence match references built-in lists Google curates:

• iplist-known-malicious-ips
• iplist-tor-exit-nodes
• iplist-public-clouds (AWS, Azure, etc.)
• iplist-vpn-providers

These are useful for blocking known-bad sources, but mixing them with public CDN ranges can break legitimate traffic — many CDNs share IPs with VPN providers.

Address Groups (Named and Global)

Address groups are reusable named CIDR or IP-list objects scoped to an org, folder, or project, referenced by firewall policy rules instead of typing CIDRs inline.

Project-Scoped vs Org-Scoped Address Groups

• Project-scoped — gcloud network-security address-groups create my-group --type=IPV4 --capacity=100 --project=.... Only usable from policies in that project.
• Org-scoped (a.k.a. global) — --parent=organizations/123456 and --location=global. Usable from hierarchical policies and from network policies in any project under the org.

Capacity and Mutability

Each address group declares a --capacity at creation time (max 50,000 IPs for org-scoped, 100 for project-scoped by default). You can add and remove members at runtime with gcloud network-security address-groups add-items without re-deploying rules, which is why incident-response runbooks use address groups for "blacklist this attacker" pages.

Referencing in a Rule

gcloud compute network-firewall-policies rules create 500 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=deny \
  --src-address-groups=organizations/123456/locations/global/addressGroups/blocklist

Security Profile Groups and Cloud NGFW Enterprise

The premium tier of Cloud NGFW (called Cloud NGFW Enterprise) adds Layer 7 inspection. The plumbing is two new objects: security profiles and security profile groups.

What Security Profiles Do

A security profile is an org-level resource of type=THREAT_PREVENTION that wraps a Palo Alto-licensed intrusion prevention engine. It can act on signatures with severity Critical/High/Medium/Low/Informational and either ALERT, DROP, RESET, or DEFAULT per severity.

Wrapping into Security Profile Groups

A security profile group bundles one or more profiles (today only one threat-prevention profile per group is supported, but the API anticipates more) and is the actual object referenced by a firewall rule:

gcloud compute network-firewall-policies rules create 3000 \
  --firewall-policy=prod-global-pol --global-firewall-policy \
  --direction=INGRESS --action=apply_security_profile_group \
  --security-profile-group=organizations/123456/locations/global/securityProfileGroups/spg-prod \
  --layer4-configs=tcp:443 --src-ip-ranges=0.0.0.0/0

The rule's action apply_security_profile_group triggers L7 inspection: TLS-intercepted HTTP, SMB, FTP, DNS, etc. are scanned for the profile's signatures. Matching packets are dropped or alerted per the profile rules.

Enterprise SKU Pricing Impact

Cloud NGFW Enterprise is billed per-VM-NIC per-hour plus per-GB inspected. As of 2026 it is roughly $0.025 per vCPU-hour plus $0.075 per GB. This is substantial — the exam expects you to recommend Enterprise only for high-value workloads (regulated data, internet-facing edges) rather than slapping it on every internal VM.

Service Accounts vs Network Tags vs Secure Tags

Three target mechanisms exist for selecting which VMs a rule applies to. The exam tests understanding of when each is allowed and what IAM controls each.

Network Tags (Legacy)

Free-form strings attached to a VM via --tags=web,prod. Anyone with compute.instances.setTags can attach any tag, so they are an audit nightmare in shared projects. Network tags only work in legacy VPC firewall rules, never in Network Firewall Policies or Hierarchical Policies.

Service Accounts as Targets

Attaching a service account to a VM requires iam.serviceAccountUser, so SA-based targeting inherits IAM. Use [email protected]. Works in legacy firewall rules and in some network firewall policy contexts.

Secure Tags (Modern)

Secure tags are IAM-controlled tag resources created at the org or project level (gcloud resource-manager tags keys create, gcloud resource-manager tags values create). Attaching a tag value to a VM requires resourcemanager.tagUser on that tag value, so binding access can be delegated per tag. Secure tags work in all three firewall layers — hierarchical, network policy, and even some legacy contexts — and they are the recommended modern targeting mechanism.

A single VM can carry up to 50 secure tags, and tags inherit down the resource hierarchy (an org-level tag is visible in projects below).

Decision Matrix

For new builds always reach for secure tags; only fall back to service accounts when a workload has no tag schema yet.

Evaluation Order End-to-End

Putting all the layers together, a packet to your VM is evaluated in this strict order:

1. Hierarchical Firewall Policy at Organization — rules sorted by priority, first match wins (within this layer).
2. Hierarchical Firewall Policy at Folder — same, may inherit from sub-folders.
3. Global Network Firewall Policy associated with the VPC.
4. Regional Network Firewall Policy associated with (VPC, region) — yes, regional is evaluated after global in current docs.
5. Legacy VPC Firewall Rules on that VPC network.
6. Implied rules — implied deny ingress and implied allow egress.

At each layer, goto_next defers to the next layer. allow and deny are terminal. If no rule in a layer matches, evaluation implicitly proceeds to the next layer.

A Worked Example

A packet from 203.0.113.5 to a web-tier VM on tcp:443:

1. Org hierarchical: rule priority 100 deny tcp:22 src 0.0.0.0/0 — no match (wrong port). Rule priority 200 goto_next allow tcp:443 src 203.0.113.5 — matches, goto_next.
2. Folder hierarchical: empty, falls through.
3. Global network firewall policy: rule priority 500 apply_security_profile_group tcp:443 src 0.0.0.0/0 — terminal action, L7 inspection runs. Profile passes, packet allowed.
4. Legacy VPC and regional layers are not consulted — the global policy already terminated.

Logging, Insights, and Operational Tooling

Every firewall layer can emit logs to Cloud Logging, but they are gated by per-rule --enable-logging flags and a sampling rate.

Firewall Rules Logging

Set --enable-logging --logging-metadata=INCLUDE_ALL_METADATA on a rule to log every connection that matches it. Logs include 5-tuple, action, rule reference, instance, and optionally the VPC and SA. Sampling is by-flow, not by-packet — a long-lived connection generates one log entry.

Firewall Insights

Firewall Insights is a Recommender-powered analysis that surfaces:

• Shadowed rules — rule A is fully shadowed by higher-priority rule B; you can delete A.
• Overly permissive rules — 0.0.0.0/0 matches with low hit rate.
• Deny rule false positives — rules denying traffic that recommender thinks should be allowed.

It runs continuously and exposes findings under gcloud recommender insights list --insight-type=google.compute.firewall.Insight.

Network Connectivity Tests Integration

The Network Connectivity Tests product evaluates source → destination paths against your current firewall state, including hierarchical policies. Use this to validate rule changes before deploying.

FAQs

Q1: Can a Hierarchical Firewall Policy reference a project's network tag like web?

No. Hierarchical policies cannot see project-local network tags. Use secure tags instead, which are first-class resource-manager objects with org-wide visibility, or use IP ranges or service accounts.

Q2: If I have both a legacy VPC firewall rule and a Network Firewall Policy rule that match the same packet, which wins?

It is layer-based, not priority-based. Network Firewall Policies are evaluated before legacy VPC firewall rules. So if the policy rule says allow, the legacy rule is never consulted. If the policy rule says goto_next, legacy rules are then evaluated by their own priority order.

Q3: How quickly does an FQDN firewall rule pick up a DNS change?

GCP refreshes the resolved IP set on TTL expiry, typically every 30 seconds for short-TTL records. If the upstream DNS TTL is 5 minutes you may see a 5-minute lag after a DNS change. For tight RPO scenarios, prefer pinning to specific IP ranges plus an FQDN rule as backup.

Q4: Can I use Cloud NGFW Enterprise L7 inspection without TLS interception?

L7 inspection works on plaintext flows directly. For TLS-encrypted flows you must enable TLS Inspection in the security profile, which requires you to provision a trust store with internal CA certificates the client VMs trust. Otherwise the profile can only see TLS metadata (SNI, JA3) and not the encrypted payload.

Q5: What is the difference between an address group and a CIDR list in a rule's --src-ip-ranges?

A direct CIDR list is inline to the rule and capped at 256 entries per rule. An address group is a separate named object that can hold up to 50,000 entries (org-scoped), can be mutated at runtime without rule changes, and can be referenced by many rules at once. Use CIDR lists for short, stable lists; use address groups for large or rapidly changing ones.

Q6: How many priorities are there in a Hierarchical Firewall Policy?

Hierarchical policy rules use a 32-bit priority space (0..2147483647) — far larger than legacy VPC rules' 0..65535. The wider range lets you interleave org, folder, and project rules without collisions during migration.

Q7: Is there a charge for Network Firewall Policies?

Standard Network Firewall Policy usage is free — you only pay for the VM compute as usual. Cloud NGFW Enterprise features (security profile groups, L7 IPS, FQDN matching at scale) are billed separately per vCPU-hour and per inspected GB.