Policy evaluation: the single most important concept for understanding how a firewall decides which traffic to allow and which to block. If you get this wrong in the real world, you could accidentally let hackers into your network or block your CEO’s email. For the PCNSA exam, mastering rule order and the flow of policy evaluation is the difference between a pass and a fail, because nearly every question about security policies relies on this foundation.
Jump to a section
A simple way to picture Policy Evaluation: Rule Order, Matching, and Decryption Policy Flow
Have you ever been stuck in a long security line at the airport when, after finally reaching the front, you realise you forgot to take your laptop out of your bag? You get pulled aside, your bag gets searched again, and everyone behind you waits. Why does that happen? It’s because the security rules are evaluated in a strict order, and they don’t go back to re-check you after you fail the first rule.
In this analogy, the airline is like your company’s network, and the security checkpoint is the Palo Alto Networks firewall. Each rule in the firewall’s policy is like a different airport security agent. The first agent checks your ID. If your ID is valid, you move on. But if the first agent stops you because your ID is expired, you don’t get to meet the second agent (who would have asked about liquids). You are turned away immediately. That is the “first-match” principle: once a packet matches a rule, it is handled and never checked against the rest of the rules.
Now, think about the “decryption policy”. Imagine a special lane for passengers with diplomatic passports. Before any normal security screening, a separate officer checks if you are a diplomat. If you are, you skip the entire normal queue and go to a different, faster process. That is exactly what the decryption policy does on a firewall: it runs before the regular security rules and can decide to decrypt or skip decryption for certain traffic, changing how the subsequent rules will see that traffic. If you mix up the order of the diplomat lane and the normal lane, diplomatic passports would get treated like regular ones—and that would be a security nightmare.
In a Palo Alto Networks firewall, every piece of network traffic is made up of “packets” – tiny chunks of data sent from one computer to another. When a packet arrives at the firewall, the firewall doesn’t just guess what to do with it. It has a list of rules, called a “security policy”, that tells it exactly how to handle that packet. But the order of those rules matters enormously, and the firewall uses a concept called “first-match” to decide which rule to apply.
Imagine you have a list of rules on a piece of paper, numbered 1 to 100. The firewall starts looking at rule number 1. It checks: does this packet match rule 1? To match, the packet’s details – like its source IP address (where it came from), destination IP address (where it’s going), and the port number (which service it wants, like web traffic or email) – must all fit the conditions in that rule. If the packet matches rule 1, the “action” in rule 1 is applied immediately. The action could be “allow” (let the packet through), “deny” (block it), or “drop” (silently discard it). The firewall then stops checking any further rules. It does not look at rule 2, 3, or 100. This is “first-match”. If the packet does not match rule 1, the firewall moves to rule 2, then rule 3, and so on, until it finds a matching rule. If no rule matches at all, the firewall applies a default action, which is usually “deny” – meaning the packet is blocked.
Why does this matter? Because the order of your rules is the only thing that guarantees which rule gets applied. Beginners often think the firewall compares a packet against all rules and picks the “best” one, like a shopping comparison site. That is not how it works. It is strictly “first-match”. So if you accidentally put a very broad rule (like “allow all traffic from the internet”) before your specific “deny traffic from bad IP addresses” rule, the internet traffic will be allowed before the bad IPs even get a chance to be blocked. That is a huge security hole.
Now, there is an important twist: the “decryption policy”. Decryption is the process of decrypting encrypted traffic (like HTTPS websites) so the firewall can inspect what is inside the traffic. But decryption is not done by the regular security rules. It has its own separate policy that runs before the security rules. The decryption policy decides which traffic should be decrypted, and which should be left encrypted. Only after the decryption policy has run does the firewall apply the security rules to the decrypted (or still encrypted) traffic. This separation is critical because if you want to block a specific malicious website that uses HTTPS, you must first decrypt that traffic; otherwise, the firewall cannot see what website the packet is going to – it only sees an encrypted blob. So the decryption policy acts as a gatekeeper: it says “this traffic I will decrypt” or “this traffic I will not decrypt”, and then the security rules inspect the actual content.
The key takeaway is that policy evaluation on a Palo Alto Networks firewall is a linear, top-to-bottom process with two distinct stages: decryption policy first, then security policy. Getting the order wrong within either list is a common and dangerous mistake. The PCNSA exam loves to test if you understand that a packet stops as soon as it hits a match in the security policy, and that the decryption policy runs entirely before the security policy ever sees the packet.
Packet arrival
A data packet arrives at the firewall from a source IP address heading to a destination IP address. The firewall records the interface it arrived on and which security zone that interface belongs to.
Session lookup
The firewall checks if this packet is part of an existing session (a previous connection already being tracked). If yes, it applies the cached action from that session without re-evaluating the policy.
Decryption policy evaluation (if new session)
If this is the first packet of a new session, the firewall evaluates the decryption policy, which is a separate list of rules. It checks conditions like source IP, destination IP, and port. The first matching rule in the decryption policy decides whether to decrypt the traffic or leave it encrypted.
Security policy evaluation
After the decryption stage, the firewall evaluates the security policy. It starts at rule number 1 and checks each rule in order. The first rule whose conditions (source, destination, application, user, etc.) match the packet determines the action: allow, deny, drop, or other actions like logging.
Action execution and logging
Once a matching rule is found, the firewall executes the action specified in that rule. If the action is allow, the packet is forwarded. If deny, the packet is blocked and a notification may be sent. The firewall logs this match for auditing. If no rule matches, the default deny action is applied.
Imagine you are the new IT administrator at a medium-sized company called “GreenTech”. Your boss has just bought a Palo Alto Networks firewall. Your job is to configure it so that employees can access the internet and check their email, but also so that malicious websites are blocked and the CEO’s laptop has special access to a financial system.
Here is how you would actually apply policy evaluation in practice:
First, you log into the firewall’s management interface. You open the “Policies” section and create a “Decryption Policy”. You know that all traffic to Google Drive uses HTTPS and must be decrypted so the firewall can scan for viruses in downloaded files. So you create a decryption rule that says: “Decrypt any traffic going to google.com and drive.google.com”. You place this rule at the top of the decryption policy list, because you want it to match first. Underneath, you add a catch-all rule: “Do not decrypt all other traffic” – because decrypting everything slows down the network.
Now you move to the “Security Policy” tab. You need to create several rules. Remember: the order matters. You should not put a broad “allow everything” rule first, or all your other rules become useless. So you start with the most specific and important rules at the top. - Rule 1: “Block known malicious IPs”. You import a list of known bad IP addresses from a threat intelligence feed. This rule says: if the source IP is in that list, deny the traffic. You put this first because you want to block threats immediately, before anything else can accidentally allow them. - Rule 2: “Allow CEO to financial system”. The CEO’s laptop has a fixed IP address. The financial server is at 10.10.10.50. This rule matches only that specific source and destination, and allows it. Because it is above broader rules, it works perfectly. - Rule 3: “Allow employees to internet”. This uses a source of “trusted” internal IP range, and destination “any” (the entire internet), with action “allow”. This is your working rule for most people. - Rule 4: “Block streaming video”. Your company policy says no YouTube during work hours. So you add a rule after the internet rule that denies traffic to YouTube. But wait – because rule 3 allows all internet traffic, rule 4 will never be reached. The YouTube traffic will match rule 3 first and be allowed. This is a classic rookie mistake. You must place the deny rule for YouTube above the general allow rule for internet. So you reorder: rule 1 (block bad IPs), rule 2 (CEO access), rule 3 (block YouTube), rule 4 (allow internet).
After you commit the changes, the firewall starts evaluating packets. When an employee tries to browse YouTube, the firewall checks: does it match rule 1? No. Rule 2? No. Rule 3? Yes – and it is denied. Perfect. In the real world, you would constantly monitor the firewall’s logs to see which rules are being hit, and if you see a rule that is never matched (like the YouTube block under the allow rule), you know you have an ordering problem. The PCNSA exam will test this exact scenario: you must understand that the first matching rule wins, and that decryption rules are evaluated before security rules.
The PCNSA exam puts heavy emphasis on the order of operations in policy evaluation. You can expect multiple-choice questions that describe a scenario with a list of rules and ask: “What will happen to this packet?” or “Which rule will be applied?”. The trap is always that beginners think the firewall uses some kind of “best match” logic, when in reality it is “first match”.
Here are the specific concepts the exam tests:
First-match rule evaluation: You must memorise that once a packet matches a rule, the firewall stops and does not look at any further rules. Exam questions will list four rules, and you must trace the packet through the list from top to bottom, ignoring rules that come after the first match. The correct answer is always the rule that is encountered first and matches all the packet’s attributes.
Decryption policy runs before security policy: The exam often gives a scenario where a packet is encrypted (HTTPS) and asks whether it will be decrypted. You need to know that the decryption policy is a separate policy that runs first. If the decryption policy says “decrypt”, then the security policy later inspects the decrypted content. If the decryption policy says “no decrypt”, the security policy only sees the encrypted data, so it cannot inspect the URL or content.
Rule order importance: The exam loves to show you a list of rules where a broad “allow” rule is placed before a specific “deny” rule. The question will ask: “Will traffic from the specific source be blocked?” The answer is no, because the broad allow matches first. You must be able to identify why the order makes the specific deny ineffective.
The default deny rule: Every policy list ends with an implicit “deny all” rule that kicks in if no rule matches. The exam will test that this is the final fallback and that you cannot see it in the GUI – it is always there.
Intrazone vs interzone rules: The exam may ask about rules that control traffic within the same zone (intrazone) or between different zones (interzone). The order of evaluation is still first-match, but you must understand that zone membership is a key matching criterion.
Trap: “Any” as a match condition: Be careful when a rule uses “any” for source or destination. A rule with “any” will match almost every packet, so if it is placed too high in the list, it will steal matches from more specific rules underneath. The exam will test whether you spot that an “any” rule is catching traffic you intended for a lower rule.
Trap: Misordering decryption and security: The exam might present a scenario where a decryption rule decrypts traffic, but a security rule blocks that traffic before the decryption can happen – this is impossible because decryption runs first. So the correct answer is that the decryption rule will still execute before the security rule can block.
To prepare, practise building rule sets in your head. For each question, mentally list the rules from top to bottom, check which rule the packet matches first, and ignore the rest. That is the winning strategy for the PCNSA.
Palo Alto Networks firewalls use a first-match rule evaluation: the first rule whose conditions match the packet's attributes is applied, and no further rules are checked.
Decryption policy is evaluated before security policy, meaning the decision to decrypt or not is made before any security rule inspects the traffic.
Implicit deny is always active: if no security rule matches a packet, the firewall blocks that packet by default, even if no rule explicitly says so.
The order of rules in a policy list is the single most important factor in determining which rule applies to a given packet.
A broad rule placed above a specific rule will make the specific rule ineffective because the broad rule will match first.
Encrypted traffic that is not decrypted by the decryption policy will be inspected only at the encrypted level, making it impossible to block specific URLs or file types within that session.
These come up on the exam all the time. Here's how to tell them apart.
First-match evaluation
Stops at the first rule that matches the packet
Order of rules is critical; earlier rules have priority
Used by Palo Alto Networks firewalls
Best-match evaluation
Evaluates all rules and picks the one with the most specific conditions
Order of rules does not matter; the most specific rule wins
Used by some older firewall models, not by Palo Alto Networks
Decryption policy
Evaluated before security policy
Controls whether traffic is decrypted or not
Has its own separate rule list
Security policy
Evaluated after decryption policy
Controls whether traffic is allowed, denied, or dropped
Has its own separate rule list
Implicit deny rule
Not visible in the rule list
Applied when no other rule matches
Action is always deny
Explicit deny rule
Visible in the rule list
Applied when the rule matches specifically
Action can be deny, drop, or other actions
Session state (stateful firewall)
Remembers previous packets and uses cached actions
Evaluates only the first packet of a session against policy
Standard for Palo Alto Networks firewalls
Stateless firewall
Evaluates every packet independently against the policy
Does not track sessions
Outdated for modern security, not used by Palo Alto Networks
Mistake
The firewall checks all rules and applies the most restrictive one, like a safety inspector who finds every problem.
Correct
The firewall applies the first rule that matches, not the most restrictive. A permissive rule placed early will win over a restrictive rule placed later.
This misconception comes from everyday experiences like quality control, where a product is checked against many criteria and fails if it fails any one. In security, we want the first match to be decisive for performance and predictability.
Mistake
Decryption policy is just a part of the security policy, like a checkbox in the same rule.
Correct
Decryption policy is a completely separate policy that runs before the security policy. It has its own rule base and its own evaluation flow.
Because beginners see both listed under “Policies” in the firewall GUI, they assume they are combined. But separating them allows the firewall to decide whether to decrypt before inspecting content, which is essential for performance and legal compliance.
Mistake
If a packet does not match any rule, it is allowed by default because the firewall is meant to let traffic through.
Correct
The default action when no rule matches is to deny the packet. This is called “implicit deny” and is a fundamental security principle.
People new to IT often think networks are forgiving. But in security, the standard is to block everything that is not explicitly allowed. This misconception leads to leaving security holes accidentally.
Mistake
Firewalls remember packets from earlier connections and apply the same rule each time, so order does not matter after the first time.
Correct
Firewalls use session tables to keep state, but the first packet of a session always goes through the full policy evaluation. Changing rule order can affect new sessions immediately.
This misunderstanding arises because users observe that once a connection is established (like a web page loading), it works fine. They forget the initial evaluation and think the order is only relevant at setup. The exam tests that the first packet in a new session goes through the matching process from the top.
Mistake
A rule with source = “any” and destination = “any” at the bottom of the list is harmless because it only catches leftover traffic.
Correct
If placed at the very bottom, such a rule acts as a catch-all, but if placed anywhere above a more specific rule, it will steal matches from that rule. Position relative to other rules is critical.
Beginners think “bottom” means “least important”. But if you accidentally put a catch-all in the middle, all rules below it become useless. The exam loves to test this by scrambling the order.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The top rule (allow all) will match first for all traffic, so the malware rule at the bottom will never be evaluated. Malware traffic will be allowed through because it matched the top rule first.
The decryption policy runs before the security policy. The firewall decides whether to decrypt traffic based on the decryption policy first, and only then applies the security policy to the decrypted or still-encrypted traffic.
No. Once a packet matches a rule, the firewall stops checking and applies the action from that rule. It does not evaluate any subsequent rules.
The default action is an implicit deny. The packet is blocked and not forwarded. This is a built-in safety feature of Palo Alto Networks firewalls.
HTTPS traffic is encrypted. Without decryption, the firewall can only see the IP address and port, not the specific website URL or content. To block a specific website, the decryption policy must first decrypt the traffic so the security policy can inspect the full request.
No, existing sessions continue using the rules they matched at session creation. The new rule only applies to the first packet of new sessions that come after the rule is committed.
You've finished Policy Evaluation: Rule Order, Matching, and Decryption Policy Flow. Continue through the PCNSA study guide to build a complete picture of the exam.
Done with this chapter?