Palo Alto PSE Strata common mistakes
Palo Alto PSE Strata · Understand the traps and how to avoid them.
Treating the PAN-OS security policy as first-match-any-rule instead of first-match-by-specificity, so candidates predict traffic is allowed by a broad 'allow all' rule that actually sits below a more specific deny rule.
Candidates carry over intuition from other vendors' ACL evaluation or assume the top-most rule always wins, when PAN-OS evaluates rules top-down and the first matching rule applies regardless of how general it is.
What to do instead
Before answering any policy-evaluation question, walk the rulebase from the top and stop at the first rule whose source, destination, application, user, and service all match the flow. Practice with rulebases that mix specific denies above broad permits and confirm the shadowing behavior.
Assuming a session is allowed because the application is recognized, ignoring that the default interzone rule is deny and that an explicit allow rule (or App-ID-based rule) must exist for the traffic to pass.
Candidates focus on App-ID detection and forget that identification is separate from enforcement; the firewall identifies applications even for traffic it ultimately blocks.
What to do instead
Separate the two questions in your head: 'will App-ID identify this?' and 'is there a rule permitting it?'. For every scenario, state the permitting rule and its action explicitly before concluding the session is allowed.
Confusing zone-based security policy with interface-level settings, claiming traffic is blocked by a security rule when the real cause is a missing or misconfigured virtual router, interface zone assignment, or missing security zone on the interface.
Troubleshooting questions present several plausible causes and candidates jump to policy because it is the most familiar layer, skipping the L1-L3 prerequisites that must work before policy is evaluated.
What to do instead
Use a layered checklist: interface up and zoned, virtual router route present, NAT resolved, then security policy, then profile/decryption. When a scenario says 'traffic never reaches policy', look at routing and zones first.
Mixing up source NAT and destination NAT direction and which address the security policy matches after NAT, so candidates pick the wrong post-NAT tuple when predicting rule matches.
NAT changes addresses before policy lookup for destination NAT, and candidates do not consistently track the order of operations (destination NAT, then policy, then source NAT).
What to do instead
Memorize the processing order: destination NAT translation, then security policy evaluation against translated destination, then source NAT. Re-derive the post-NAT five-tuple for each scenario before selecting a rule.
Assuming every Cloud-Delivered Security Service subscription is active by default or that a single license covers all services, then selecting a service (e.g., DNS Security, WildFire, URL Filtering) as available when it is not licensed or not attached to a profile.
Candidates conflate the platform with the subscription bundle and forget that services require both entitlement and a security profile attached to an allowing rule to take effect.
What to do instead
For any CDSS question, verify two conditions separately: the subscription/license is present, and the relevant security profile is attached to the permitting rule. If either is absent, the service does not act on the traffic.
Treating WildFire verdicts as instant, expecting inline blocking on first submission rather than understanding the unknown-then-verdict lifecycle and the role of local analysis and cloud verdict caching.
Candidates oversimplify WildFire to 'it blocks malware' and miss the sequence where a new file is initially unknown, analyzed, and only later blocked on subsequent attempts via verdict updates.
What to do instead
Learn the lifecycle: file submitted, local/cloud analysis, verdict (malicious/benign/phishing/unknown), verdict cached and applied to future sessions. Answer questions about first-seen versus subsequent traffic accordingly.
Confusing DNS Security's role with URL Filtering, attributing domain-based C2 blocking to URL categories or expecting DNS Security to inspect HTTP payloads.
Both services act on names/URLs, and candidates blur the layer at which each operates, leading to wrong service selection in scenario questions.
What to do instead
Anchor each service to its layer: DNS Security inspects DNS queries/responses for malicious domains and DNS tunneling; URL Filtering categorizes HTTP/HTTPS destinations. Match the observable symptom (DNS lookup vs HTTP request) to the service.
Assuming Strata Cloud Manager configuration changes apply immediately to all managed firewalls without a push, or that SCM is purely monitoring and cannot push policy.
Candidates are unsure whether SCM is a management plane or a reporting overlay and guess, leading to wrong answers about change propagation and commit behavior.
What to do instead
Treat SCM as the management plane for managed firewalls: configuration is authored centrally, then pushed to devices. Distinguish staged configuration from pushed/enforced state and answer propagation questions with that two-step model.
Confusing the roles of device groups, templates, and template stacks in SCM, assigning policy to a template or interface/network settings to a device group.
The hierarchy mirrors Panorama concepts but with different names and stacking behavior, and candidates map old mental models onto SCM incorrectly.
What to do instead
Learn the split: device groups carry policy objects and rules; templates carry network/device configuration; template stacks order and combine templates for device onboarding. Assign each configuration item to the correct container before answering.
Assuming a hardware firewall's dedicated management port and data ports share the same routing and zone behavior, or that a PA-Series appliance can be managed in-band on a data interface by default without configuration.
Candidates treat all ports as equivalent and forget that the management interface is a separate plane with its own routing and that in-band management requires explicit configuration and a permitted rule.
What to do instead
Distinguish the management plane (MGT port, separate default route, management access rules) from the data plane (security zones, virtual router). For access questions, confirm which plane the traffic uses and whether a management-access rule permits it.