Palo Alto NetSec Architect common mistakes
Palo Alto NetSec Architect · Understand the traps and how to avoid them.
Designing a single-pair, single-active deployment for every site and then defending it as 'high availability', without evaluating whether the design actually removes the single point of failure (shared switch, single ISP path, single power feed).
Candidates memorize the active/passive vs active/active comparison table and then apply active/passive by default, without reasoning about failure domains. They confuse 'two firewalls' with 'no single point of failure', so they miss that a shared upstream switch or a single transit link still breaks the design.
What to do instead
For any HA question, enumerate the failure domains explicitly: device, link, switch, ISP, power, and control plane. State which failure each design element covers, and pick the topology (active/passive, active/active, HA pair with separate switches, dual-ISP with path monitoring) that matches the stated RTO. Practice writing a one-paragraph failure-mode table before choosing the answer.
Sizing throughput from the datasheet 'App-ID throughput' figure alone and ignoring the effect of enabled features (threat prevention, SSL decryption, logging) on the actual performance envelope.
Datasheet numbers are the easiest thing to remember, and candidates treat them as a single capacity figure. They do not account for the fact that App-ID, content inspection, and decryption each reduce effective throughput and add latency, so the chosen platform is undersized for the required feature set.
What to do instead
Size against the throughput figure that matches the features you will actually enable (threat prevention, decryption), add headroom for growth, and state the assumption in your answer. When a scenario gives you both a raw and a feature-enabled number, always reason from the feature-enabled one and show the calculation.
Writing a policy that permits an application by port only (for example 'allow tcp/443 from any to any') and calling it application-aware, instead of using App-ID with the correct application and service, plus a follow-up rule for unknown traffic.
Candidates default to the port-based mental model from traditional firewalls and forget that the platform's core value is application identification. They also skip the implicit dependency: App-ID needs the session to be allowed to identify, so a deny-all default plus a port-only permit defeats the purpose.
What to do instead
Structure every policy answer as: source/destination zone and address, user or group, application (App-ID) rather than service, and an explicit action. Add a separate rule for unknown-tcp/unknown-udp with a tighter profile if the design requires it, and explain the order of evaluation. Practice translating a requirement sentence into a rule with all five matching dimensions.
Treating the security profile group as a single checkbox and attaching the same profile group to every rule, including internal east-west and trusted-to-untrusted traffic, without differentiating by risk.
Profile groups are easy to attach and candidates rarely think about which threat vectors apply to which traffic. They also forget that decryption is a prerequisite for many file and content signatures, so a profile that looks complete silently underperforms on encrypted traffic.
What to do instead
Map each rule to its threat surface: internet-facing traffic gets antivirus, anti-spyware, vulnerability protection, URL filtering, and file blocking; internal traffic gets a narrower set. State explicitly where decryption is required for the profiles to be effective, and call out the exceptions (pinned certificates, privacy-sensitive flows) with a documented compensating control.
Configuring NAT and security policy in isolation and getting the order wrong: writing the policy against pre-NAT or post-NAT addresses without stating which, or forgetting that the destination zone in the policy is evaluated after destination NAT.
NAT and policy evaluation order is one of the most commonly confused areas. Candidates memorize 'NAT before policy' but cannot apply it to a specific scenario, so they pick the wrong zone or address in the rule and the rule never matches in production.
What to do instead
Drill the evaluation order: destination NAT resolves the translated address and zone before the security policy lookup, while source NAT affects the source seen by the destination. For every scenario, write the five-tuple before and after translation, then derive the policy match. Verify with a traffic log or test flow in a lab.
Assuming a site-to-site tunnel is up means traffic flows, and never validating routing, proxy IDs, or the return path, so the design works in the lab and fails asymmetrically in production.
Candidates conflate IKE/IPsec phase success with end-to-end forwarding. They forget that selectors (proxy IDs), route-based vs policy-based tunnel interfaces, and asymmetric routing across multiple ISPs determine whether the packet actually traverses the tunnel in both directions.
What to do instead
For every VPN design, list the four checks: phase 1 and 2 parameters match, selectors or routes cover the intended subnets, return traffic uses the same path, and the policy permits the decrypted traffic. Where multiple ISPs exist, specify the tunnel monitoring and failover behaviour and the source NAT or loopback handling that keeps the return path symmetric.
Deploying decryption broadly without a forward-trust or exception strategy, then discovering broken applications, pinned certificates, and expired internal certificates causing an outage.
Decryption is presented as a security win, so candidates enable it everywhere and forget the operational consequences: certificate pinning, mutual TLS, break-and-inspect failures, and the need to distribute a forward-trust CA to endpoints. The exam tests whether you planned the rollout, not just the toggle.
What to do instead
Design decryption in phases: inventory traffic, classify by category, exclude privacy and pinned-certificate flows with documented reasons, deploy forward trust (or forward proxy) to managed endpoints, and monitor decryption failures. Always pair a decryption policy with a no-decrypt rule for the excluded categories and a plan for certificate lifecycle.
Reading a single dashboard or a single log entry and declaring root cause, instead of correlating traffic, threat, and system logs with the session and flow details across the path.
Troubleshooting questions reward a methodical evidence chain, but candidates jump to the most familiar log (usually the traffic log) and stop. They miss that the answer often lives in the session details, the drop reason, or the system log showing a commit or resource issue.
What to do instead
Adopt a fixed triage sequence: is the packet arriving (interface counters, packet capture), is it being dropped (session detail and drop reason), is it being permitted (policy match in traffic log), and is the application behaving (threat and URL logs). State which log answers which question, and practice reading session-end reasons to distinguish policy deny, threat block, and routing failure.
Changing configuration to fix a suspected problem without confirming the change is committed and active, and without a rollback path, then compounding the issue with a second change.
Candidates treat commit as an afterthought and forget that candidate configuration is not enforced until committed, and that some changes (content updates, HA sync) behave differently from policy commits. They also skip validating the change against a test flow before moving on.
What to do instead
Before and after every change, verify the running configuration and commit status, confirm HA peers are in sync, and test with a known flow. For operational scenarios, name the rollback mechanism (config version, revert, snapshot) and state the validation step that proves the fix. Never stack a second change on an unverified first one.
Treating logging and monitoring as a storage problem rather than a design input: setting retention and forwarding without deciding what must be retained for investigation, compliance, and correlation.
Candidates see log retention as an administrative setting and pick the largest number, or ignore it entirely. They do not connect retention to incident investigation windows, compliance requirements, or the need to forward to a SIEM before local storage rolls over.
What to do instead
Derive retention from the requirement: how far back must an investigation reach, what does compliance mandate, and what is the local disk budget. Then specify log forwarding to the SIEM with the fields needed for correlation, and account for decrypted traffic and threat logs increasing volume. Show the arithmetic when a scenario gives storage and daily volume.