Firewall rules and hierarchical firewall policies. These are the fundamental building blocks that control which network traffic is allowed or blocked inside a Google Cloud environment. For anyone studying for the PCNE exam, understanding how to configure and manage these rules is critical because nearly every exam scenario involves deciding which traffic path is permitted, and the exam loves to test the subtle differences between standard firewall rules and hierarchical policies.
Jump to a section
A simple way to picture Firewall Rules and Hierarchical Firewall Policies
3 university dorm buildings, each with 5 floors, and 20 rooms per floor. The head of housing has a master key that can open any room in any building, but also gives each building manager a key that can open rooms only in their building, and each floor's RA a key that only opens rooms on their floor. When a new student named Alice wants to invite her friend Bob to visit her room on floor 2 of building A, she needs a permission slip. There are three types of permission slips: a 'no visitors ever' rule from the Head of Housing that applies to every room in every building, a 'visitors allowed after 10pm only' rule from Building A's manager that applies only to building A, and a 'visitors allowed anytime' rule from Alice's RA that applies only to floor 2 of building A. The Head of Housing's rule overrides all others, and the RA's rule can only allow, not deny. If the Head of Housing says 'no visitors' and the RA says 'visitors allowed', the RA's rule is ignored. If the Head of Housing says 'visitors allowed' and the Building Manager says 'visitors after 10pm', then Alice's RA can say 'visitors allowed anytime' and it applies because it is more specific. This is exactly how Hierarchical Firewall Policies work in Google Cloud, where organisation-level policies (the Head of Housing) always take priority, but project-level policies (the RA) can be used to give exceptions.
The permission slip types map directly: the Head of Housing’s policy is an ‘organisation-wide’ firewall policy, the Building Manager’s policy is a ‘folder-level’ policy, and the RA’s policy is a ‘project-level’ policy. A ‘rule’ is the specific instruction on the slip, like ‘allow TCP port 80 from 10.0.0.0/8’. The key difference is that hierarchical policies always overwrite, not add, when they conflict. In the dorm, if the Head of Housing says ‘no visitors’ but the RA says ‘visitors allowed’, the RA is overridden — the Head of Housing wins. This is the same logic as Google Cloud’s Hierarchical Firewall Policies being evaluated with a strict priority order, where organisation-level rules always take precedence over folder-level, and folder-level always overrides project-level. This prevents a user in one project from accidentally allowing traffic that the organisation’s security team has explicitly blocked.
A firewall rule is a simple set of conditions that decides what happens to network traffic inside a Virtual Private Cloud (VPC) network. Imagine a Virtual Private Cloud (VPC) as your own private, isolated segment of the cloud where you run virtual machines, databases, and other services. A firewall rule is like a guard at the door of that VPC who checks a pass before letting traffic through. Every firewall rule has five main parts: a direction (ingress or egress), a source or destination, a protocol (like TCP, UDP, or ICMP), a port number (like 22 for SSH or 80 for HTTP), and an action (allow or deny). The default behaviour in a VPC is to block all incoming traffic from outside the VPC (ingress) and allow all outgoing traffic to anywhere (egress). However, you can create your own rules to open specific ports.
Hierarchical firewall policies are a more powerful and centralised way to manage firewall rules across many projects in an organisation. Instead of writing a rule inside each individual VPC, you write one policy at a higher level in the resource hierarchy. The Google Cloud resource hierarchy looks like a pyramid: at the top is your Organisation node (the root of your company’s cloud account), then folders (like departments such as 'Engineering' or 'Finance'), then projects (like 'Production' or 'Staging'), and finally the VPCs and resources inside each project. A hierarchical firewall policy can be attached to the Organisation, to a Folder, or to a Project. When you attach a policy at a higher level, it applies to everything below it in that hierarchy branch.
How do hierarchical policies differ from standard VPC firewall rules? Standard firewall rules are defined inside a VPC and only apply to resources within that VPC. They are written as a list of rules that are evaluated in order from least specific to most specific, with a default deny at the end. Hierarchical policies, on the other hand, are applied at the Organisation, Folder, or Project level and affect all VPCs under that node. They also have a strict priority mechanism where a policy at a higher level (e.g., Organisation) always wins if it conflicts with a policy at a lower level (e.g., Folder). This is fundamentally different from standard rules, where a more specific rule can override a less specific one.
The purpose of hierarchical policies is to enforce organisation-wide security standards without requiring every project owner to write their own rules. For example, a security team can create one policy at the Organisation level that blocks all traffic to port 22 (SSH) from the internet, and this rule automatically applies to every project in the company. A project owner cannot override this rule with a standard VPC firewall rule because hierarchical policies are evaluated separately and with higher priority. This solves a common problem in large organisations where different teams might accidentally open insecure ports.
There are two types of rules you can use in firewall policies:
Ingress rules: these control traffic coming into a VM (instance). You specify where the traffic comes from (source ranges like IP addresses), what protocol and port it uses, and whether to allow or deny it.
Egress rules: these control traffic leaving a VM (instance). You specify where the traffic is going (destination ranges), what protocol and port it uses, and whether to allow or deny it.
Hierarchical firewall policies also support something called ‘enforced’ rules. An enforced rule is a rule that cannot be changed or overridden by lower-level policies. If a rule is marked as ‘enforced’, it acts like a permanent lock — even if someone writes a contradictory rule at a lower level, the enforced rule wins. This is useful for mandatory security controls like blocking all traffic to known bad IP addresses.
To use hierarchical policies, you first create a policy resource in the Google Cloud Console or using the gcloud command-line tool. Then you attach the policy to an Organisation, Folder, or Project. Once attached, you add rules to the policy. Each rule has a priority number; lower numbers mean higher priority. Among rules within the same policy, the lowest priority number is evaluated first. If one rule denies and another allows, the deny rule wins because deny always takes precedence over allow, regardless of priority. This is a key concept: deny rules are always evaluated before allow rules inside the same policy.
When a packet arrives at a VM, Google Cloud evaluates three sets of rules in order: first, hierarchical policies attached to the Organisation, then hierarchical policies attached to Folders, then hierarchical policies attached to Projects. After that, standard VPC firewall rules are evaluated. If any rule in the hierarchical policies denies the traffic, the traffic is dropped immediately. Only if all hierarchical policies allow the traffic and no deny rule matches, the standard VPC firewall rules are checked. This ensures that organisation-level security controls are never bypassed.
Identify the target hierarchy level
Determine whether the firewall policy needs to be applied at the Organisation, Folder, or Project level. If the rule must apply to every project in the company (e.g., block RDP from internet), attach at the Organisation. If it is department-specific (e.g., allow SSH only for Engineering), attach at the Folder level. This decision determines the scope of the policy.
Create the hierarchical firewall policy resource
In the Google Cloud Console, navigate to 'Firewall Policies' under VPC network. Click 'Create Policy'. Give it a descriptive name (e.g., 'company-wide-block-rdp') and optionally a description. This creates an empty policy container that will hold the rules. Alternatively, use the gcloud command: gcloud compute firewall-policies create POLICY_NAME --organization ORG_ID.
Add firewall rules to the policy
Inside the policy, add rules with specific conditions: direction (ingress or egress), source/destination IP ranges, protocols and ports, action (allow or deny), and priority. For example, to block RDP from everywhere, add an ingress deny rule with source 0.0.0.0/0, protocol tcp, port 3389, and priority 100. Remember that deny rules win over allow rules inside the same policy.
Attach the policy to the chosen resource
Attach the policy to the Organisation, Folder, or Project you identified in step 1. For Organisation-level attachment, use: gcloud compute firewall-policies associations create --firewall-policy POLICY_NAME --organization ORG_ID. For Folder-level: --folder FOLDER_ID. After attachment, the policy's rules immediately apply to all VPCs under that resource.
Test and verify the policy is working
Launch a test VM in a project under the affected hierarchy. Try to initiate the traffic that the policy is supposed to block (e.g., attempt an RDP connection from an external IP). If the policy is working, the connection will time out or be refused. Use Cloud Logging to check for firewall rule logs if logging is enabled. Also test a scenario where traffic should be allowed to ensure no unintended blocks.
Troubleshoot any unexpected blocks
If a user cannot connect to a VM, check the hierarchical policies attached at every level above the project (Organisation, Folder, Project). A policy at a higher level might be denying the traffic. Also check standard VPC firewall rules, because even if a hierarchical policy allows traffic, a standard rule can still deny it. Use the gcloud compute firewall-policies list command to view all policies in scope.
An IT professional managing a Google Cloud environment for a large enterprise might be tasked with securing hundreds of projects across multiple departments. For example, imagine a company called 'GlobalCorp' that has three departments: Engineering, Finance, and HR. Each department has multiple projects (e.g., Engineering has 'dev', 'staging', 'prod'). GlobalCorp’s security team wants to enforce a company-wide policy that blocks all remote desktop protocols (RDP) from the internet because they are a common attack vector. They also want to allow SSH from a specific internal IP range only, but only for Engineering.
Using hierarchical firewall policies, the security team can achieve this efficiently. Here is what an IT professional would actually do, step by step:
Create a hierarchical firewall policy at the Organisation level. They would go to the Google Cloud Console, navigate to 'Firewall Policies', and create a new policy named 'global-corp-security-policy'. They set the priority of this policy to 1000 (higher number means lower priority, but lower number is higher priority — they would use 1000 to allow room for lower-priority folder policies).
Add a deny rule to block RDP from the internet. They add an ingress deny rule with the following details:
Source IP ranges: 0.0.0.0/0 (everywhere)
Protocol and port: tcp:3389 (the default RDP port)
Action: deny
Priority: 100 (low number, so it is evaluated early)
Add an allow rule for internal SSH for Engineering only. They create a second rule in the same policy that allows SSH (tcp:22) from the internal IP range 10.0.0.0/8. However, they realise that this rule would apply to the whole organisation if attached at the Organisation level. Instead, they decide to attach the policy to a specific folder. They create a folder called 'Engineering' under the Organisation and move the Engineering projects into it.
Attach the organisation policy to the Organisation node. They attach the 'global-corp-security-policy' to the Organisation node. This makes the RDP block apply to every project in the company.
Create a separate hierarchical policy for the Engineering folder. They create a new policy named 'engineering-ssh-access' and attach it to the Engineering folder. Inside this policy, they add an ingress allow rule for tcp:22 from 10.0.0.0/8. Because this policy is at the folder level (lower in the hierarchy than the Organisation), and the Organisation policy only contains a deny rule for RDP (not SSH), there is no conflict. The SSH allow rule from the folder policy applies to all Engineering projects.
Test the rules. An IT professional would then test by launching a test VM in an Engineering project and trying to SSH from an IP outside 10.0.0.0/8. They expect the connection to be denied because the folder policy only allows from that range. They would also test RDP from any external IP and confirm it is blocked across all departments.
Audit and monitor. The IT professional would use Cloud Logging to see logs of denied traffic, and set up alerts if any RDP traffic is attempted. They would also create a new policy at the Folder level for Finance and HR to allow SSH from their own internal ranges, ensuring departmental isolation.
In a real job, an IT professional might also need to troubleshoot when a project owner complains that their VMs are unreachable. The professional would check the hierarchical policies first because they override everything. If a project owner created a standard VPC firewall rule to allow SSH from 0.0.0.0/0, but a hierarchical policy blocks SSH from everywhere, the SSH traffic would still be denied. The professional would need to modify the hierarchical policy or create an exception rule with a lower priority (higher number) that allows the specific IP, but only if it does not conflict with an enforced rule.
The PCNE exam (Google Professional Cloud Network Engineer) tests your knowledge of firewall rules and hierarchical firewall policies extensively. Expect around 5–8 questions directly on this topic, spread across the exam. The exam focuses on the differences between standard VPC firewall rules and hierarchical firewall policies, the priority order of evaluation, and how to troubleshoot connectivity issues caused by conflicting rules.
Key concepts the exam loves to test:
Priority order of evaluation: The absolute rule is that hierarchical policies are evaluated from the highest level (Organisation) down to the lowest level (Project), but within a single policy, deny rules are always evaluated before allow rules. The exam will give you a scenario with multiple rules at different hierarchy levels and ask you which rule wins.
Deny always wins: Inside any single hierarchical firewall policy, if there is a deny rule that matches the traffic and an allow rule that also matches, the deny rule takes effect, regardless of priority numbers. This is a fundamental rule that beginners often get wrong.
Enforced rules: An enforced rule is a rule that cannot be overridden by lower-level policies. The exam likes to ask what happens when a lower-level policy has a contradictory rule to an enforced higher-level rule. The answer is always that the higher-level enforced rule wins.
Inheritance and attachment: Hierarchical policies are not inherited automatically — they must be explicitly attached to an Organisation, Folder, or Project. If a policy is attached to a Folder, it only applies to that Folder and its descendants. The exam will test whether you know that a policy attached to a Folder does not apply to projects in a different Folder.
Standard VPC firewall rules vs hierarchical: Standard VPC firewall rules are evaluated after all hierarchical policies. If a hierarchical policy denies traffic, the traffic is dropped before standard rules are even checked. The exam may present a scenario where a standard rule allows traffic but a hierarchical policy denies it, and you must determine the result is denial.
Logging and monitoring: The exam expects you to know how to enable firewall rule logging for hierarchical policies (using Cloud Logging) and how to use that data to debug connectivity issues.
Common traps the exam sets:
Giving a scenario where a standard VPC firewall rule has a higher priority (lower number) than a hierarchical policy rule. The trap is that priority numbers only matter within the same context — hierarchical policies always take precedence over standard rules, regardless of priority values.
Presenting a confuse rule: e.g., a hierarchical policy with a rule that allows traffic from a specific source, and then a project-level standard rule that denies that same traffic. The correct answer is that the hierarchical allow allows the traffic, but only if the hierarchical policy does not have a deny rule that matches. The default action is to allow if no deny rule matches in the hierarchical policy, then standard rules are checked. But if the standard rule denies, it will deny after the hierarchical allow. This is a subtle point: hierarchical allow does not guarantee traffic is allowed; the final decision depends on standard rules unless the hierarchical policy has a deny.
Asking about the maximum number of rules in a hierarchical policy. The limit is 200 rules per policy.
What to memorise:
The evaluation order: Organisation policy -> Folder policy -> Project policy -> Standard VPC firewall rules.
Within a policy: deny rules evaluated before allow rules.
Enforced rules cannot be overridden.
The default VPC firewall rules: implicit allow egress, implicit deny ingress.
How to use the 'gcloud compute firewall-policies' command to create and attach policies.
The difference between a firewall rule and a firewall policy: a policy is a collection of rules, and a policy is attached to a resource in the hierarchy.
Exam question type patterns:
‘Which firewall rule will take effect for traffic from IP X to VM Y?’
‘A junior admin created a rule that allows SSH from the internet, but users cannot connect. What is the most likely cause?’
‘You need to enforce a company-wide block on FTP. Where should you apply the rule?’
‘What is the result when a hierarchical policy has a deny rule for port 80 and a standard VPC rule allows port 80 with priority 1000?’
Hierarchical firewall policies are evaluated from the highest level (Organisation) down to the lowest level (Project), and deny rules within the same policy always take precedence over allow rules regardless of priority order.
A hierarchical firewall policy must be explicitly attached to an Organisation, Folder, or Project; it is not automatically inherited like IAM permissions.
Standard VPC firewall rules are only evaluated after all hierarchical firewall policies have been checked, meaning a hierarchical deny rule will block traffic before standard rules are even considered.
An enforced rule in a hierarchical firewall policy cannot be overridden by any lower-level policy or by standard VPC firewall rules, providing absolute security controls.
The default behaviour of a VPC is to allow all outbound traffic and deny all inbound traffic from outside the VPC, but standard firewall rules can modify this, while hierarchical policies can override them.
When troubleshooting connectivity issues, always check hierarchical firewall policies first because they are evaluated before standard VPC firewall rules and can silently block traffic.
A single hierarchical firewall policy can contain up to 200 rules, and a policy attached to a Folder applies to all projects and VPCs within that Folder.
Deny rules take precedence over allow rules inside the same hierarchical firewall policy, even if the allow rule has a lower priority number.
These come up on the exam all the time. Here's how to tell them apart.
Standard VPC Firewall Rules
Defined and applied inside a single VPC network only.
Evaluated after hierarchical policies have been fully checked.
Can be overridden by a hierarchical policy if it is a deny rule.
Use priority numbers (lower is higher priority) within the VPC’s rule list.
Hierarchical Firewall Policies
Defined as a policy resource and attached to Organisation, Folder, or Project nodes.
Evaluated before any standard VPC firewall rules.
Cannot be overridden by standard VPC rules; they are the first gate.
Use a separate priority system with deny-over-allow logic inside the same policy.
Allow Rule
Allows traffic if it matches the rule’s conditions.
If matched, traffic proceeds to the next evaluation step (next policy or standard rules).
Does not win over a deny rule in the same policy; allow is weaker.
Deny Rule
Blocks traffic if it matches the rule’s conditions.
If matched, traffic is immediately dropped and no further rules are evaluated.
Always wins over an allow rule within the same policy, regardless of priority.
Organisation-level Policy
Attached to the Organisation node, applies to all folders and projects in the organisation.
Has the highest priority among all hierarchical policies.
Cannot be overridden by any folder or project level policy.
Folder-level Policy
Attached to a Folder node, applies only to projects within that folder.
Has lower priority than organisation-level policy.
Can be overridden by a higher-level policy (Organisation) but not by a project-level policy.
Enforced Rule
Cannot be overridden by any lower-level policy or standard rule.
Ensures absolute enforcement of security controls.
Must be used sparingly for critical security requirements.
Non-enforced Rule
Can be overridden by a lower-level policy if the lower-level rule is also a deny or is allowed by the hierarchy logic.
Allows flexibility for project-level exceptions.
Is the default type of rule in a hierarchical policy.
Mistake
Hierarchical firewall policies are inherited automatically from the organisation to all projects without explicit attachment.
Correct
Hierarchical firewall policies must be explicitly attached to an organisation, folder, or project. They are not inherited automatically just because they are created at a higher level.
Beginners confuse the concept of 'inheritance' from IAM (Identity and Access Management) with firewall policies. In IAM, permissions are inherited by default. In firewall policies, you must attach the policy to the resource.
Mistake
If a standard VPC firewall rule has a lower priority number (higher priority) than a hierarchical policy rule, the standard rule will take effect.
Correct
Standard VPC firewall rules are always evaluated after all hierarchical policies. Hierarchical policies take precedence regardless of priority numbers. The priority numbers only matter within the same type of rule (hierarchical or standard).
People bring their understanding of standard firewall rules (where lower priority number means the rule is checked first) to hierarchical policies, but the evaluation order is defined by the hierarchy level, not the priority number.
Mistake
A hierarchical firewall policy at the folder level can override a rule at the organisation level.
Correct
A policy at a higher level (organisation) always takes precedence over a policy at a lower level (folder). If the organisation-level policy denies traffic, a folder-level policy cannot allow it.
This stems from a misunderstanding of the resource hierarchy. Some assume a 'child' can override a 'parent' if the child's rule is more specific, like in standard firewall rules. But in hierarchical policies, the child never overrides the parent.
Mistake
Hierarchical firewall policies are only necessary for large enterprises with hundreds of projects.
Correct
Hierarchical policies are useful in any organisation that wants to enforce consistent security across multiple projects, even if there are only 2 or 3 projects. They provide centralised control and prevent accidental oversights.
Beginners often think this feature is only for 'big companies', but Google Cloud recommends using hierarchical policies even for small setups to enforce base security, like blocking SSH from the internet.
Mistake
When you attach a hierarchical firewall policy to a folder, it applies to all projects in that folder, overriding any standard VPC rules in those projects.
Correct
Attaching a hierarchical policy to a folder does apply to all projects under it, but it does not automatically override all standard VPC rules. Hierarchical policies are evaluated first, but if they allow traffic, standard rules can still deny it. If they deny traffic, standard rules are ignored.
People think hierarchical policies completely replace standard rules, but they are evaluated in sequence. The hierarchical policy is the 'first gate', and standard rules are the 'second gate'. Traffic must pass both gates to be allowed.
Mistake
You can create a hierarchical firewall policy rule with an action of 'allow' and it will always allow traffic regardless of other rules.
Correct
An allow rule in a hierarchical policy only means the traffic is allowed at the hierarchical level. The traffic can still be denied by a later standard VPC firewall rule. Also, if there is a deny rule in the same hierarchical policy, the deny rule wins over an allow rule.
People assume that a 'allow' rule at a higher level is absolute, but the evaluation is sequential. The deny-over-allow rule inside the same policy also catches many off guard.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. Hierarchical firewall policies are evaluated before standard VPC firewall rules. If a hierarchical policy denies the traffic, it is dropped before standard rules are ever checked, so the allow rule in the standard VPC is irrelevant.
A firewall rule is a single condition (e.g., allow TCP 80 from 10.0.0.0/8). A firewall policy is a container that holds multiple rules and is attached to an Organisation, Folder, or Project. You create rules inside a policy, and then attach the policy to the hierarchy level.
First, create the policy with 'gcloud compute firewall-policies create POLICY_NAME --organization=ORG_ID'. Then add rules with 'gcloud compute firewall-policies rules create PRIORITY --action=ACTION --direction=DIRECTION --firewall-policy=POLICY_NAME --organization=ORG_ID'. Finally, attach the policy to an organisation, folder, or project.
Yes, a single policy can be attached to multiple resources (Organisation, Folders, Projects) simultaneously. However, each attachment applies independently. If you attach the policy to the Organisation and also to a Folder, the Organisation attachment applies to everything, and the Folder attachment applies only to that Folder.
Within the same policy, deny rules are always evaluated before allow rules. If both a deny and an allow rule match the traffic, the deny rule wins, regardless of priority numbers. If both rules are allow or both are deny, the rule with the lower priority number (higher priority) wins.
Yes, you can enable logging for each rule in a hierarchical firewall policy. When logging is enabled, details about traffic matching the rule are sent to Cloud Logging. This is useful for troubleshooting and auditing.
You can have up to 200 rules in a single hierarchical firewall policy. This is a hard limit set by Google Cloud.
You've finished Firewall Rules and Hierarchical Firewall Policies. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?