Palo Alto SD-WAN Engineer common mistakes
Palo Alto SD-WAN Engineer · Understand the traps and how to avoid them.
Designing SD-WAN topologies by assigning every branch the same hub as its only BGP peer and skipping the hub-to-hub or partial-mesh path, then being unable to explain how traffic from one branch reaches another when the primary hub fails.
Candidates memorize the idea that branches connect to hubs and treat the topology as a star diagram instead of reasoning about the actual forwarding path, next-hop resolution, and failover behavior the design requires.
What to do instead
For every topology question, draw the full path (branch to hub to destination) and mark which peer advertises which prefix, then verify what the branch's FIB contains for every remote prefix under normal and failed conditions. If the design needs branch-to-branch traffic, confirm the hub re-advertises or the branches peer directly; if not, say so explicitly.
Configuring SD-WAN interfaces and then assuming traffic will use them without verifying the physical interface, tunnel, and virtual router membership are all consistent, so policy and routing silently fall back to a single link.
The SD-WAN configuration is spread across multiple objects (Ethernet interface, SD-WAN interface, tunnel, zone, virtual router), and candidates configure only the visible SD-WAN object while missing the binding that makes it usable.
What to do instead
After configuring an SD-WAN interface, verify in order: the physical interface is up and in the correct zone, the SD-WAN interface references the correct physical interface and tunnel, the tunnel is in the same virtual router as the policy, and the virtual router has the SD-WAN interface in its member list. Test with a traffic log that shows both links carrying sessions.
Writing path-quality or application-based SD-WAN policy without a matching fallback rule, then expecting traffic to fail over when the preferred path degrades instead of being dropped or black-holed.
Candidates focus on the interesting branch of the policy (send SaaS traffic over the broadband link) and forget that policy evaluation ends in a default action that may not match the intended traffic.
What to do instead
For each SD-WAN policy rule, state the explicit fallback: what happens if the preferred path's SLA is not met, what happens if the rule does not match, and what the default path is. Verify with a traffic log entry showing the session's chosen path and the policy rule name that matched.
Treating SD-WAN path selection as ordinary static routing and not distinguishing between the control plane (which prefixes are advertised over which link) and the data plane (which link a given session uses).
Candidates conflate route advertisement with traffic steering, so they answer questions about which link carries traffic by looking only at the routing table, or answer questions about reachability by looking only at the policy.
What to do instead
Separate the two questions every time: first, which peers learn the prefix and over which tunnels (control plane); second, for a given session, which path the SD-WAN policy selects and whether that path is currently within SLA (data plane). Confirm with both the routing table and the session's traffic log entry.
Assuming an SD-WAN tunnel is encrypted because it is a tunnel, and configuring security policy that inspects traffic as if it were decrypted, when the tunnel is actually a plain IPsec or GRE construct with different decryption behavior.
Candidates carry over assumptions from VPN terminology and do not check whether the tunnel terminates in a zone that requires decryption before security policy applies.
What to do instead
Identify the tunnel type and its termination zone, then confirm whether traffic arriving on that tunnel is decrypted before policy evaluation. If inspection is required, ensure the tunnel is in a zone with the correct decryption profile and that the security policy references that zone, not the underlying physical zone.
Configuring Prisma SASE integration and expecting branch traffic to be steered to the cloud security service automatically, without confirming the service connection, the forwarding rule, and the return path are all in place.
Candidates learn the concept of cloud-delivered security but not the concrete chain of configuration objects that makes traffic actually leave the branch toward the service and come back.
What to do instead
Trace the full chain: the service connection is up, the branch has a route or policy that sends the intended traffic to the service, the service knows how to return traffic to the branch, and the return traffic is not asymmetric. Verify with a traffic log showing the session leaving toward the service and returning on the expected interface.
Reading a single monitoring dashboard and concluding a link is healthy, when the dashboard aggregates or averages path quality and hides a link that is failing SLA for a specific application or a specific tunnel.
Candidates trust the top-level status indicator instead of correlating per-link, per-tunnel, and per-application metrics, so they miss the exact failure the question describes.
What to do instead
Check the specific link, tunnel, and application in question rather than the aggregate. Compare latency, jitter, and loss against the SLA thresholds defined in the policy, and confirm whether the policy actually evaluated that path as out of compliance.
Troubleshooting an SD-WAN path problem by starting with the security policy, when the actual fault is in path quality measurement or tunnel establishment and the security policy is never reached.
Candidates default to the policy layer because it is the most familiar, without first establishing whether the tunnel is up and whether the path meets SLA.
What to do instead
Troubleshoot in order: physical link up, tunnel established, path quality within SLA, SD-WAN policy selects the path, security policy permits the session. Identify the first failing step and stop there; do not debug later layers until earlier ones are confirmed.
Assuming that changing an SD-WAN policy takes effect for existing sessions, and then reporting that the change did not work because a long-lived session stayed on the old path.
Candidates do not account for session-level path binding and expect policy changes to re-steer traffic that is already established.
What to do instead
After a policy change, verify the new rule matches new sessions, and for existing sessions either wait for them to age out or clear them if the platform supports it. Confirm the result with a fresh traffic log entry that shows the new rule name and path.
Answering operational questions about SD-WAN failover without distinguishing link failure from SLA degradation, and therefore choosing the wrong trigger or the wrong expected behavior.
Candidates treat all failover as link-down failover and do not separate physical failure, tunnel failure, and path quality below threshold, which have different detection mechanisms and different timings.
What to do instead
For each failover scenario, name the trigger explicitly (link down, tunnel down, or SLA violation), the detection mechanism, and the resulting path. If the question is about degradation, the link is still up and traffic must be re-steered by policy, not by routing convergence.