PCNSA common mistakes
PCNSA · Understand the traps and how to avoid them.
Describes the firewall as running App-ID, then Content-ID, then User-ID as three separate sequential scanning passes over each packet, and says the management plane takes over traffic processing when the device is busy.
Vendor marketing summaries compress the architecture into a feature checklist, so candidates answer from the brochure rather than the single-pass data-plane design that the exam actually tests.
What to do instead
Redraw the architecture from memory: separate management and data planes, single-pass parallel processing with one parse per packet, and App-ID/Content-ID/User-ID all resolved in that same pass. Practise explaining it aloud in under 60 seconds without mentioning a 'pipeline of engines'.
Matches requirements to the wrong portfolio component, e.g. saying WildFire performs DNS sinkholing, that URL Filtering blocks unknown malware, or that Prisma Access is an on-premises virtual form factor.
The product and subscription names overlap heavily in function, so candidates answer from brand familiarity instead of from a capability map.
What to do instead
Build a one-page matrix with rows for Threat Prevention, WildFire, DNS Security, URL Filtering, GlobalProtect, Prisma Access, VM-Series and CN-Series, and columns for what it inspects, where it runs, and what licence it needs. Before answering, name the single component that uniquely delivers the stated capability.
Edits a Panorama-managed firewall and commits locally, expecting the change to survive, or assumes a Panorama commit alone is enough to activate configuration on the managed device.
The two-stage workflow (Panorama commit pushes to device groups and templates, then the firewall commits locally to activate) is invisible in a single-firewall lab setup where one commit does everything.
What to do instead
Memorise the sequence as a chain: Panorama commit → push to managed devices → local commit on the firewall. Note that locally defined objects can be overwritten on the next push, so verify the object is local-only before relying on it.
Assigns a broad predefined admin role (or superuser) to solve a scoping problem, and ignores the difference between device-level and vsys-level role scope when asked how to limit an administrator's view.
Granular RBAC rarely comes up in day-to-day operations, and predefined roles are the only names candidates have seen in a lab.
What to do instead
Learn the pattern: predefined role as a starting point, custom role profile when a permission set is narrower, and scope chosen at device or vsys level. For each scoping question, ask 'what is the smallest set of permissions and the narrowest scope that satisfies the requirement?'
Writes the security rule using the pre-NAT destination address (the public IP the client connects to) when the server sits behind destination NAT, then cannot explain why the rule never matches.
Intuition says the policy should reference the address the user typed, but PAN-OS resolves destination NAT before the policy lookup while source NAT is applied after it.
What to do instead
Memorise the order as destination NAT → security policy → source NAT. Use the post-NAT (translated) destination in the security rule, and remember the source NAT address is chosen from post-policy information such as the egress interface or zone.
Assumes every zone-to-zone path is denied by default, adds an explicit intra-zone rule 'to be safe', or expects denied interzone traffic to appear in the traffic log without extra configuration.
The two default rules behave differently and only one of them logs, which is easy to miss because both sit at the bottom of the rulebase and look identical at a glance.
What to do instead
Memorise the pair explicitly: intrazone-default allows with no logging, interzone-default denies with logging disabled. Add that rules are evaluated top-down, first match wins, so specific rules must sit above broad ones or they are shadowed.
Sets the security rule service to application-default, then cannot explain why an application running on a non-standard port is dropped, or sets service to any and assumes strict enforcement still applies from the first packet.
Candidates treat the service column as a formality and do not connect it to how App-ID resolves the session and when policy can be enforced.
What to do instead
State the trade-off in one sentence: application-default limits the rule to the application's defined ports, while service any lets the first packet through before App-ID resolves, deferring enforcement. When an application is reported on an unusual port, check the service column before anything else.
Uses 'application filter' and 'application group' interchangeably, or claims a dynamic filter must be manually edited whenever a new application is released.
Both appear in the Applications list and both can be attached to a rule, so the difference between a static member list and a membership rule is easy to blur under exam pressure.
What to do instead
Anchor the distinction: a group is a static list of members you choose, a filter is a dynamic query on category, subcategory, technology, risk or characteristics whose membership changes as content updates arrive. Choose a filter when the requirement is 'all apps of type X, including future ones'.
Expects URL Filtering to match the full HTTPS URL including the path, or creates a custom URL category containing a path and expects it to match traffic that is not decrypted.
Candidates carry over the HTTP model where the full request line is visible, and do not connect visibility depth to whether decryption is in place.
What to do instead
State the visibility rule: without decryption only the domain (from SNI or the certificate) is available, so host-level categories and custom URL lists on the domain work but path-based matching does not. If a requirement mentions the path or a specific page, decryption is the prerequisite.
Uses block and continue as if they were the same action, or builds a URL Filtering profile and never references it in the security rule, then reports that filtering is not working.
The profile lives in a separate object list from the policy, and the action names look like stylistic variants rather than distinct behaviours.
What to do instead
Learn the action set as behaviours, not names: block silently drops, continue serves a response page, override lets the user proceed with a password, alert and allow permit with logging. Then check attachment: no profile in the rule's URL Filtering field means no filtering, regardless of how the profile is configured.