SD-WAN-ENGINEER Practice Questions

The recommended best practice for upgrading a large fleet of ION devices is to perform a phased or staged rollout. Using Site Tags allows an administrator to group sites logically (e.g., by region, function, or rollout phase). By assigning the new software version to a small "Pilot" tag first, the new version can be validated in a controlled production environment. If the pilot upgrade is successful, the administrator can then proceed to assign the new version to subsequent groups incrementally, which significantly minimizes the risk of a network-wide service disruption.

A. Manually log into each device and upload the new image file via USB. This method is not scalable for a large fleet of devices and is operationally inefficient and prone to human error.

B. Assign the new software version to the "Global" site configuration to upgrade all 1000+ sites simultaneously. This approach is extremely high-risk. A single issue with the new software could cause a catastrophic, network-wide outage.

D. The ION devices upgrade themselves automatically whenever a new version is released by Palo Alto Networks. ION device upgrades are not automatic upon release. An administrator must explicitly select and assign a target software version to sites via the controller to initiate the upgrade process.

1. Palo Alto Networks Prisma SD-WAN Administrator’s Guide 6.3: In the section "Upgrade ION Device Software," the guide explicitly states, "For a large-scale deployment, it is recommended to perform a phased rollout of the software upgrade. You can use site tags to group sites into various phases of the rollout." This directly supports the methodology described in option C. (Reference: Prisma SD-WAN Administrator’s Guide 6.3, Chapter: Device and Software Management, Section: Upgrade ION Device Software).

2. Palo Alto Networks Prisma SD-WAN Administrator’s Guide 6.3: The same guide details the process of assigning a software version to a site or group of sites. The process requires an administrator to navigate to the site list, select the sites, and choose "Software" > "Assign." This confirms that the upgrade is an administrator-initiated action, refuting the claim of automatic upgrades in option D. (Reference: Prisma SD-WAN Administrator’s Guide 6.3, Chapter: Device and Software Management, Section: Upgrade ION Device Software, Step 3).

Prisma SD-WAN automates the security of the Secure Fabric VPN tunnels established between ION devices. The controller is responsible for the lifecycle management of the IPsec shared secrets used for authentication and tunnel establishment. To enhance security and prevent key compromise, the controller automatically generates, distributes, and rotates these shared secrets for all VPN tunnels every 24 hours. This process ensures that the keys are regularly refreshed without requiring manual administrator intervention, maintaining a robust security posture across the SD-WAN fabric.

A. 1 hour is an incorrect duration; the documented rotation interval is significantly longer to balance security with operational overhead.

B. 8 hours is not the standard rotation period for Prisma SD-WAN VPN shared secrets as specified in the official documentation.

D. 72 hours is an incorrect value; the shared secrets are rotated more frequently to adhere to security best practices.

1. Palo Alto Networks. (2023). Prisma SD-WAN Administrator’s Guide 6.3. "Secure Fabric". In the section describing VPN security, it states: "The controller automatically generates, distributes, and rotates shared secrets for VPN tunnels between ION devices every 24 hours."

Palo Alto Networks Prisma SD-WAN continuously monitors the performance of all available paths using metrics like latency, jitter, and packet loss. For real-time media applications, which are highly sensitive to these conditions, an application policy defines the maximum tolerable thresholds. If the currently used link's performance degrades and breaches these thresholds (becoming "poor"), the default and primary corrective action is to seamlessly and non-disruptively move the application flow to an alternate link that is currently meeting the policy requirements. This ensures the application's performance and the user experience are maintained.

A. Drop the flow.

This is a failure condition that SD-WAN actively works to prevent. Dropping the flow is a last resort if no compliant paths are available, not a default corrective action.

C. Apply Forward Error Correction (FEC).

FEC is a configurable link optimization feature used to proactively mitigate packet loss on a path. It is not a default, reactive action triggered by general poor performance.

D. Raise an alarm.

Raising an alarm is a monitoring and notification function that occurs in response to poor performance, but it is not the action taken on the traffic flow itself to remediate the issue.

1. Palo Alto Networks Prisma SD-WAN Administrator's Guide 6.2: In the section "Path and Application Policies," the guide explains the core logic: "Prisma SD-WAN uses policies to select the best path for an application... If the path quality degrades and no longer meets the policy requirements, Prisma SD-WAN automatically and seamlessly moves the application to a path that does meet the policy requirements." This directly describes the action of moving flows.

2. Palo Alto Networks Prisma SD-WAN Administrator's Guide 6.2: The "Forward Error Correction" section details FEC as a feature that can be enabled on circuit categories to improve performance over links with high packet loss. This confirms it is a configured optimization rather than a default reactive measure. The text states, "You can enable Forward Error Correction (FEC) on circuits to mitigate packet loss for real-time, transactional, and critical application traffic." This shows it's an explicit configuration choice.

The Prisma Access for Remote Networks license is an aggregate bandwidth pool. This pool is allocated by the administrator to specific compute locations (regions). All remote network connections (branch sites) onboarded to a single compute location share the bandwidth allocated to that location. This model allows individual sites to burst and use more bandwidth when needed, as long as the total usage within that compute location's pool does not exceed the allocated capacity. The enforcement is applied at the regional pool level, not on a per-site basis.

A. The model is a shared pool per region, not a hard cap per individual IPSec tunnel, which allows for flexible bandwidth bursting.

C. Bandwidth is licensed as a pool for the service, not tied to the serial numbers of the CPE devices at the branch sites.

D. Bandwidth usage is continuously monitored and enforced against the allocated pool for each compute location, not just checked once at onboarding.

1. Palo Alto Networks. (2023). Prisma Access Administrator’s Guide. "Prisma Access Licensing". In the section "Remote Network Bandwidth," it states: "Prisma Access for Remote Networks uses a bandwidth-based license that you purchase as a pool of bandwidth. You allocate this bandwidth pool to remote network connections in any of the Prisma Access locations where you have onboarded remote networks."

2. Palo Alto Networks. (2023). Prisma Access Administrator’s Guide. "Allocate Bandwidth for Remote Network Connections". This section details the process and clarifies the model: "The bandwidth you allocate to a compute location is shared between all of the remote network connections in that compute location... For example, if you allocate 1Gbps to a compute location and have two remote network connections in that location, the two connections share the 1Gbps of bandwidth."

In Palo Alto Networks Prisma SD-WAN, the BGP peer configuration includes a "Scope" parameter that controls the advertisement of learned routes. To redistribute routes learned from a BGP peer at one site (e.g., a Data Center) to all other remote sites within the SD-WAN fabric, the scope must be set to "Global". This setting explicitly instructs the ION device to advertise these prefixes to all other ION devices in the tenant. A "Local" scope would restrict the use of these learned routes to the local ION device only, preventing their advertisement across the overlay.

A. Set the "Admin Distance" to 20.

Administrative Distance is used for local route selection preference on the ION device; it does not control the redistribution of routes to other sites.

B. Enable "Graceful Restart".

Graceful Restart is a high-availability feature that prevents routing flaps during a BGP control plane restart, not a mechanism for controlling route advertisement scope.

D. Configure a "Prefix List" to deny all.

A "deny all" prefix list is a filter that would block all routes from being learned from the BGP peer, which is the opposite of the desired outcome.

---

1. Palo Alto Networks Prisma SD-WAN Administrator’s Guide (Cloud-Managed), "Configure BGP" section.

Reference: In the table describing BGP Peer settings, the "Scope" parameter is defined. It states: "Select the scope for the BGP peer. Global—The routes learned from this BGP peer are available to all the sites in the tenant. Local—The routes learned from this BGP peer are available only to the local site." This directly supports the choice of "Global" scope for fabric-wide redistribution.

2. Palo Alto Networks Prisma SD-WAN Design and Operation (EDU-330) Courseware, Module on "Routing".

Reference: The official courseware explains that BGP is a key protocol for exchanging routing information between the SD-WAN fabric and the underlay network. It details that the "Scope" setting is the primary control for determining whether learned routes are kept local to the site or advertised globally to all other sites.

During the Zero Touch Provisioning (ZTP) process, a new ION device must connect to the internet to reach the Prisma SD-WAN controller. The device is factory-configured to use specific ports for this initial DHCP request. For ION hardware models that feature a dedicated out-of-band management port (labeled 'Controller' or 'CTRL'), this port is the default. For ION models that do not have a dedicated controller port, the device defaults to using the first numbered port, which is universally labeled as Port 1 or Internet 1. This dual-approach ensures a standardized and predictable ZTP experience across the entire ION device portfolio.

A. This is incorrect as it fails to account for ION models that do not have a dedicated Controller port, for which Port 1 is used instead.

B. This is incorrect because ZTP is not enabled by default on all ports; it uses specific, designated ports for initial connectivity to ensure predictability.

D. This is incorrect because while cellular connectivity via USB is a supported option, it is not the default method for wired DHCP-based ZTP.

1. Palo Alto Networks Prisma SD-WAN Administrator's Guide: In the section "Onboard an ION Device," the guide specifies the ZTP connection requirements. It states, "For Zero Touch Provisioning, you must connect the ION device to the internet. For ION devices that have a dedicated controller port, connect the controller port to the internet. For ION devices that do not have a dedicated controller port, connect port 1/internet 1 to the internet. The ION device uses DHCP to get an IP address and then contacts the controller to get claimed." (Found under the Device Onboarding and Configuration > Onboard an ION Device section).

2. Palo Alto Networks Prisma SD-WAN Hardware Installation Guide (ION 3200 model): In the "Install the ION 3200" chapter, under the "Connect the ION 3200 to the Network for Zero-Touch Provisioning" section, the instructions state: "For ZTP, connect the CTRL port on the ION 3200 to a network that has DHCP enabled and can access the internet." This confirms the use of the dedicated controller port on models that have one.

3. Palo Alto Networks Prisma SD-WAN Hardware Installation Guide (ION 1200-S model): In the "Install the ION 1200-S" chapter, under the "Connect the ION 1200-S to the Network for Zero-Touch Provisioning" section, the instructions state: "For ZTP, connect the Internet1 port on the ION 1200-S to a network that has DHCP enabled and can access the internet." This confirms the use of the Internet1 port on models without a dedicated controller port.

The Palo Alto Networks ION device's Zone-Based Firewall (ZBFW) has a set of implicit default rules to ensure essential device functionality. For traffic originating from the ION device itself (often referred to as the "local" or "self" zone), such as DNS queries, NTP updates, or connectivity to the Prisma SD-WAN controller, there is an implicit rule that allows this traffic to any destination zone. This ensures the device can maintain its management and operational connections without requiring an explicit security policy rule.

A. The default "Deny All" rule applies to traffic transiting between different zones (inter-zone traffic), not traffic originating from the device itself.

C. Controller connectivity and other essential services are designed to function over the configured WAN interfaces (circuits), not exclusively through a dedicated management interface.

D. This option uses non-standard terminology. The ZBFW operates with a unified local policy stack; there isn't a separate "Global" stack that bypasses local rules in this manner.

---

1. Palo Alto Networks Prisma SD-WAN Administrator's Guide: In the "Zone-Based Firewall" section, under the subsection "Default Security Rules," the documentation states: "Traffic that is sourced from the ION device (local) and destined for any other zone is allowed by default." This implicit rule is fundamental to the device's out-of-the-box operation. (Note: Specific page numbers vary by document version, but the information is consistently located in the ZBFW default rules description).

The key functional difference between a BGP Core Peer and an Edge Peer in Palo Alto Networks SD-WAN lies in the automatic route redistribution policy. Routes learned from a peer designated as "Core" are considered internal to the data center and are automatically advertised and redistributed throughout the SD-WAN fabric to all other sites. Conversely, routes learned from an "Edge" peer, typically a service provider, are used for local routing decisions at that site (e.g., for internet or private WAN egress) and are not automatically redistributed to other sites in the overlay network.

A. This describes a common use case but not the core functional difference. The reason they are used this way is because of the underlying route redistribution behavior described in option B.

C. Both Core and Edge peer types support eBGP and iBGP. The choice between eBGP and iBGP is determined by the Autonomous System (AS) number configuration, not the peer type.

D. This is an inaccurate generalization. An Edge Peer can connect to either the internet or an MPLS provider, and a Core Peer is for the LAN side, not directly for internet connectivity.

1. Palo Alto Networks Prisma SD-WAN Administrator's Guide 6.2: In the section "Configure BGP," under "BGP Peers," the guide specifies the behavior of different peer types. It states: "Routes learned from a Core peer are automatically advertised to all other sites in the SD-WAN fabric." For Edge peers, it implies that routes are used locally and not automatically advertised. (Reference: Prisma SD-WAN Administrator's Guide, section on BGP configuration).

2. Palo Alto Networks Prisma SD-WAN Design and Operation (EDU-330) Student Guide: This courseware details SD-WAN architecture. In the module covering routing and data center integration, it explains that Core BGP peers are used to learn prefixes from the DC core that need to be advertised to remote branch sites. It contrasts this with Edge peers, whose learned routes (like a default route from an ISP) are kept local to the site. (Reference: EDU-330 Student Guide, Module on Advanced Routing with BGP).

The ION device onboarding process requires two key steps in the portal: claiming the device and assigning it to a site. The "Claimed" status indicates the device has successfully registered with the Prisma SD-WAN controller, associating its serial number with the tenant account. However, for the device to download its configuration and establish the necessary control and data plane connections to become "Online," it must be assigned to a pre-configured site. This assignment provides the device with its identity, interface roles, circuit information, and policies. The scenario confirms that basic internet connectivity is functional, isolating the problem to a configuration or assignment step within the portal.

B. The ability of a connected laptop to browse the internet strongly implies that outbound TCP port 443 is not blocked, as this port is essential for HTTPS traffic.

C. The software image download is a process that occurs after the device has successfully connected to the controller and received its initial configuration from the site assignment.

D. A "Circuit Label" is part of the site-level configuration. The device cannot receive or apply this label until it has been assigned to the site in the first place.

1. Palo Alto Networks Prisma SD-WAN Administrator’s Guide: In the section "Onboard an ION Device," the workflow explicitly states the required steps. After a device is claimed, the next step is to "Assign the device to a site." This sequence confirms that site assignment is the critical step that follows claiming and precedes the device coming online. The guide notes, "After you claim a device, you must assign it to a site to complete the onboarding process." (Reference: Prisma SD-WAN Administrator's Guide, Chapter: Onboard an ION Device, Section: Workflow for Onboarding an ION Device).

2. Palo Alto Networks Prisma SD-WAN Administrator’s Guide: The "Device State" descriptions in the monitoring section clarify the different statuses. A "Claimed" device is "Associated with a tenant but not yet assigned to a site." An "Online" device is "Connected to the controller and is ready to pass traffic." This documentation directly shows that the missing step between "Claimed" and "Online" is the site assignment. (Reference: Prisma SD-WAN Administrator's Guide, Chapter: Monitor, Section: Devices Dashboard).

The "Replace Device" workflow within the Prisma SD-WAN portal is the officially sanctioned and most efficient method for handling a device replacement due to hardware failure (RMA). This procedure is designed to minimize downtime and preserve data integrity. It works by disassociating the failed device's serial number from the site and associating the new device's serial number. The existing site configuration, policies, and circuit information (the "Device Shell") are automatically applied to the new device once it connects to the controller. This retains all historical monitoring and analytics data, which is tied to the site, not the physical hardware.

A. Manual configuration is inefficient, error-prone, and circumvents the purpose of a centralized management platform. The "Replace Device" workflow handles configuration and license association automatically.

C. A critical hardware failure may prevent access to the old device for a backup. Furthermore, Prisma SD-WAN's architecture is based on centralized configuration, not local backup and restore for RMA.

D. Deleting the old device/site would permanently erase all associated historical data and require a complete, time-consuming manual rebuild, directly contradicting the goal of minimal downtime.

1. Palo Alto Networks Prisma SD-WAN Administrator’s Guide: In the "Devices" chapter, the section "Device Replacement (RMA)" details the procedure. It states, "The Replace Device workflow allows you to replace a device with a new device of the same model without having to reconfigure the device. When you replace a device, the new device inherits the configuration of the old device. The new device is associated with the same site as the old device and retains the same name." This confirms the automated transfer of configuration to the new hardware.

2. Palo Alto Networks Prisma SD-WAN Administrator’s Guide: The same "Device Replacement (RMA)" section outlines the steps: "Select the device you want to replace...From the More list, select Replace Device...Enter the serial number of the new device." This confirms that the process is initiated from the portal and requires only the new serial number to re-associate the existing site configuration.