The Palo Alto Networks SD-WAN Engineer exam (exam code SD-WAN-Engineer) tests whether you can plan, build, run and fix a Prisma SD-WAN fabric, not just describe one. Prisma SD-WAN is the platform Palo Alto Networks gained when it bought CloudGenix, and a lot of its vocabulary (ION devices, AppFabric, policy stacks) is specific to it. Engineers coming from router-centric SD-WAN products tend to lose marks on those product-specific concepts. This guide works through the blueprint domain by domain, with the policy logic, monitoring views and API scripts you should be comfortable with before you book.
Palo Alto SD-WAN Engineer exam at a glance
| Item | Detail |
|---|---|
| Exam code | SD-WAN-Engineer |
| Certification | Palo Alto Networks Certified SD-WAN Engineer |
| Questions | 80 |
| Duration | 90 minutes |
| Passing score | 860 on a scale of 300 to 1000 |
| Price | USD 250 |
| Delivery | Pearson VUE |
| Recommended course | Prisma SD-WAN: Design and Operation (EDU-238) |
That is about 67 seconds per question. Confirm the current details on the official Palo Alto Networks SD-WAN Engineer certification page before scheduling, since Palo Alto refreshes its blueprints regularly.
Domain weights
| Domain | Weight |
|---|---|
| Planning and Design | 24% |
| Deployment and Configuration | 24% |
| Troubleshooting | 20% |
| Operations and Monitoring | 18% |
| Unified SASE | 14% |
Planning and deployment together make up almost half the exam. Troubleshooting at 20% is larger than many candidates expect, and it draws on everything else, so it is a poor place to save time.
The Prisma SD-WAN building blocks
Many questions are easy once the object model is clear. Keep this picture in your head:
- Sites are either branch or data center sites. Each holds one or more ION devices, which are the appliances, virtual or physical, that forward traffic.
- Circuits are WAN interfaces, sorted into public (internet) and private (MPLS and similar) networks. Circuit categories and labels are what policies refer to, so a policy can say "prefer the primary internet circuit" without naming a physical port.
- The AppFabric is the overlay of secure VPNs that the controller builds between sites automatically. Branch-to-data-center tunnels come up on their own, and branch-to-branch tunnels can be built dynamically when traffic needs them.
- Policies are grouped into sets and stacks, and a stack is bound to a site. This is the heart of the Planning and Deployment domains.
Domain 1: Planning and Design (24%)
The blueprint expects you to make design decisions, not just recall feature names:
- Device selection: pick an ION model by required throughput, interface count and type, and whether the site needs HA. Licensing is tied to bandwidth tiers, so the bandwidth plan drives both the model and the licence.
- Assessing the existing network: what routing exists (BGP or OSPF at the data center), where MPLS terminates, and which applications are business critical.
- Data center design: DC IONs usually sit beside the core and exchange routes with it. Know the data center interconnection (DCI) options when there are several data centers.
- Branch (gateway) design: single or dual ION, single or dual circuit, and what happens when a circuit or a device fails.
- Security requirements: which traffic is inspected locally, which goes to Prisma Access, and which goes direct to the internet.
Policy design: five policy types
| Policy | Answers the question | Typical exam angle |
|---|---|---|
| Path | Which circuits may this application use, in what order? | Active, backup and L3 failure paths per app |
| Performance | What link quality does this application need? | Thresholds for latency, jitter, packet loss and MOS |
| QoS | How is bandwidth shared when a link is congested? | Priority classes for voice and video versus bulk |
| Security | Is this flow allowed between these zones? | Zone-based firewall rules on the ION |
| NAT | How are addresses translated on egress? | Direct internet access from the branch |
The set-and-stack model is easy to get wrong. You write rules inside policy sets, combine several sets into a stack (with a default rule set at the bottom), and bind that stack to sites. One change to a shared set updates every site using that stack. That makes a scenario like "change the voice path for 300 branches at once" straightforward, and explains why a single site that needs an exception gets its own set placed above the shared ones.
Domain 2: Deployment and Configuration (24%)
- Onboarding: an ION is claimed to the tenant, assigned to a site and given its interface configuration. Know the order: site first, then claim, then assign and configure.
- Site-specific settings: address, circuit bandwidth values (which affect QoS and path decisions), DNS, SNMP and syslog.
- Configuration templates: use templates for branch and data center roles so new sites come up consistently. For automation, Palo Alto publishes a config-as-code utility (Prisma SD-WAN Config) that pulls a site's configuration to YAML and pushes it to new sites.
- Routing: BGP peering at the data center with the core, prefix filters and route maps to control what enters the fabric, and OSPF or static routing at branches. Expect questions on tuning timers and preventing the fabric from re-advertising routes it learned from the core.
- VRFs: segmentation of guest, corporate and IoT traffic, each with its own routing table across the fabric.
Automating site checks with the API
Engineers who manage dozens of sites script the controller instead of clicking through it. The Prisma SD-WAN API documentation on pan.dev describes two families: the unified SASE APIs (OAuth2 service accounts scoped to a Tenant Service Group) and the legacy APIs (token login, used by the original cloudgenix Python SDK). The idea is the same in both. Here is a short inventory script using the legacy Python SDK:
import os
import cloudgenix
sdk = cloudgenix.API()
sdk.interactive.use_token(os.environ["PRISMA_SDWAN_TOKEN"])
sites = sdk.get.sites().cn_json_response.get("items", [])
elements = sdk.get.elements().cn_json_response.get("items", [])
by_site = {}
for el in elements:
by_site.setdefault(el.get("site_id"), []).append(el)
for site in sites:
ions = by_site.get(site["id"], [])
states = ", ".join(f'{e.get("name")}={e.get("state")}' for e in ions) or "no ION assigned"
print(f'{site["name"]:<30} {site.get("element_cluster_role", "-"):<8} {states}')
For the unified APIs, you first get an OAuth2 access token with the service account's client ID and secret and your TSG ID, then send it as a Bearer token:
curl -s -d "grant_type=client_credentials&scope=tsg_id:${TSG_ID}" \
-u "${CLIENT_ID}:${CLIENT_SECRET}" \
https://auth.apps.paloaltonetworks.com/oauth2/access_token | jq -r .access_token
A service account with no role can authenticate but can do nothing. That detail is easy to miss and fits a troubleshooting question well. The exam doesn't ask you to write code, but having automated even a small inventory makes the object model (site, element, interface, policy binding) stick.
Domain 3: Operations and Monitoring (18%)
Know where to look for each kind of question:
| You need to know | Where to look |
|---|---|
| How each circuit performs over time | Link quality and activity charts for the site |
| Which app took which path, and why | Flow browser (per-flow path and policy decisions) |
| What the controller is warning about | Incidents and alerts, with notification rules for email or a webhook |
| Who changed what | Audit logs |
| Whether the problem is the network or the application | WAN Clarity reports |
| Device health (CPU, memory, interface counters) | Device-level statistics |
Alert and notification configuration is tested directly: know how to route specific incident types to specific teams, and how to cut noise by setting priorities. The blueprint also covers monitoring SASE-related events, meaning tunnel and service status toward Prisma Access.
Domain 4: Unified SASE (14%)
This is the smallest domain but the one most specific to Palo Alto:
- Prisma Access integration: branches send internet-bound or inspection-required traffic over IPsec to Prisma Access, and path policy decides which apps go there. Know how the tunnels are set up (automated through the Prisma Access integration rather than built by hand per site) and what happens to traffic if those tunnels go down.
- ADEM (Autonomous Digital Experience Management) measures application experience synthetically, so you can tell a branch circuit problem from a SaaS or Prisma Access problem.
- Device-ID: identifying IoT devices so network settings and policy can depend on device type.
- Cloud Identity Engine (CIE): brings user and group identity into Prisma SD-WAN, so path and security rules can be written per user or group (for example, finance users' ERP traffic always takes the MPLS path).
Domain 5: Troubleshooting (20%)
Work through problems in layers. Most exam scenarios fit one of these:
| Symptom | Usual cause |
|---|---|
| Branch-to-DC VPN never comes up on one circuit | Upstream device blocking or translating the fabric traffic, or the wrong circuit label |
| App uses the backup path although the primary is up | Primary fails the performance thresholds, or the path policy rule above it matches first |
| New site has no route to a DC subnet | Prefix filter or route map at the DC drops it, or the subnet sits in a different VRF |
| Voice quality drops only at busy hours | QoS class or circuit bandwidth values set wrong, so the shaper misjudges capacity |
| Change applied to one branch affected many | The rule was edited in a shared policy set rather than a site-specific one |
The blueprint also names data analysis using the co-pilot and analytics for optimisation. Know that the AI-assisted tools summarise incidents and trends from fabric telemetry. That makes them a starting point for root-cause analysis, not a replacement for the flow browser.
A five-week study plan
| Week | Focus | Practical goal |
|---|---|---|
| 1 | Building blocks and Planning and Design | Draw a two-DC, three-branch design with circuits, labels and HA choices |
| 2 | Deployment and Configuration | Map the onboarding order, build a policy stack on paper, review BGP at the DC |
| 3 | Operations and Monitoring | Know which view answers which question; set up alert routing |
| 4 | Unified SASE | Prisma Access traffic flow, ADEM, Device-ID and CIE use cases |
| 5 | Troubleshooting and review | Work the layered model above against timed practice questions |
For week 5, NWExam has free SD-WAN-Engineer sample questions that use the same scenario style, which helps you check your pacing against the 67-seconds-per-question budget.
Exam-day checklist
- Path decides where traffic may go, performance decides whether a path is good enough, QoS decides who gets bandwidth.
- Policy sets combine into stacks, and stacks bind to sites. Shared sets change many sites at once.
- Circuit labels and categories, not port names, are what policies match.
- Troubleshoot in order: circuit, fabric VPN, route, policy, then application performance.
- Unified SASE questions are about who handles what: Prisma Access inspects, ADEM measures, CIE supplies identity, Device-ID classifies IoT.
- Allow about 67 seconds per question and flag long scenarios for a second pass.
If you can explain why a given flow took a given path, using the policy stack, the link metrics and the routing table, you are ready for the Palo Alto SD-WAN Engineer exam.