Scenario practice questions

An engineer is troubleshooting a scenario where users at a branch office cannot access SaaS applications via Prisma Access. The SD-WAN path is active, but the traffic is not reaching the Cloud SWG. What is the most likely cause related to the Unified SASE policy?

Trap 1: The ION device is missing the latest firmware

Firmware version does not govern whether traffic matches a Unified SASE policy; an outdated ION image would affect forwarding generally, not selectively block Cloud SWG reachability. Firmware upgrades address device defects, whereas policy misconfiguration or missing traffic steering rules cause this symptom.

Trap 2: The Cloud Identity Engine is not reachable

The Cloud Identity Engine supplies user and group identity for policy evaluation; it is not the forwarding path, so its unreachability would not stop traffic reaching Cloud SWG. It is tempting because identity outages do break policy, and would be correct when traffic is dropped due to failed user-to-group resolution rather than path selection.

Trap 3: The WAN port is set to DHCP

DHCP on the WAN port only affects how the ION obtains its own public address; it cannot prevent Unified SASE policy from steering traffic into the Cloud SWG tunnel. DHCP is the normal choice where the ISP provides addressing dynamically, so it is valid in most branch deployments and unrelated to policy-based forwarding failures.

A
The ION device is missing the latest firmware
Why it fails: Firmware version does not govern whether traffic matches a Unified SASE policy; an outdated ION image would affect forwarding generally, not selectively block Cloud SWG reachability. Firmware upgrades address device defects, whereas policy misconfiguration or missing traffic steering rules cause this symptom.
B
The Cloud Identity Engine is not reachable
Why it fails: The Cloud Identity Engine supplies user and group identity for policy evaluation; it is not the forwarding path, so its unreachability would not stop traffic reaching Cloud SWG. It is tempting because identity outages do break policy, and would be correct when traffic is dropped due to failed user-to-group resolution rather than path selection.
C
The Security Policy rule for the branch traffic is set to 'Direct to Internet' instead of 'Service Connection'
The Unified SASE policy action determines whether branch traffic traverses the Prisma Access service infrastructure or exits locally. 'Direct to Internet' bypasses Cloud SWG entirely, so SaaS traffic never reaches it despite the active SD-WAN path.
D
The WAN port is set to DHCP
Why it fails: DHCP on the WAN port only affects how the ION obtains its own public address; it cannot prevent Unified SASE policy from steering traffic into the Cloud SWG tunnel. DHCP is the normal choice where the ISP provides addressing dynamically, so it is valid in most branch deployments and unrelated to policy-based forwarding failures.

Question 2mediummultiple choice

A network architect is designing a Prisma SD-WAN deployment for a retail chain with 400 small branches. Each branch has a single broadband circuit and a 4G/LTE backup. The design must minimize hardware cost at the branch while still supporting the SD-WAN fabric. Which ION device deployment approach best fits this requirement?

Trap 1: Deploy a pair of ION 9000 devices at each branch for full…

A pair of ION 9000 devices is a high-capacity data center design, not a 400-site retail branch. Duplicating such hardware at every small branch drives up capital and licensing cost dramatically and provides far more throughput than a single broadband plus LTE circuit could ever use, contradicting the stated goal of minimizing branch hardware cost.

Trap 2: Use only virtual ION instances hosted on third-party hypervisors at…

Virtual ION instances are valid in some designs, but a 400-site retail chain with no stated virtualization platform at the branch would need compute, hypervisor licensing, and operational skills at each site. That adds complexity and cost rather than reducing it, and the scenario gives no evidence that hypervisor infrastructure exists at these branches.

Trap 3: Rely on the LTE circuit alone and skip any SD-WAN device at the…

Without an ION device the branch cannot join the Prisma SD-WAN fabric, so centralized policy, application-based path selection, and overlay tunnels are unavailable. LTE alone also offers no broadband preference or failover behavior, which defeats the purpose of the dual-transport design and leaves the branch unmanaged from the controller.

A
Deploy a pair of ION 9000 devices at each branch for full redundancy.
Why it fails: A pair of ION 9000 devices is a high-capacity data center design, not a 400-site retail branch. Duplicating such hardware at every small branch drives up capital and licensing cost dramatically and provides far more throughput than a single broadband plus LTE circuit could ever use, contradicting the stated goal of minimizing branch hardware cost.
B
Use only virtual ION instances hosted on third-party hypervisors at each branch.
Why it fails: Virtual ION instances are valid in some designs, but a 400-site retail chain with no stated virtualization platform at the branch would need compute, hypervisor licensing, and operational skills at each site. That adds complexity and cost rather than reducing it, and the scenario gives no evidence that hypervisor infrastructure exists at these branches.
C
Rely on the LTE circuit alone and skip any SD-WAN device at the branch.
Why it fails: Without an ION device the branch cannot join the Prisma SD-WAN fabric, so centralized policy, application-based path selection, and overlay tunnels are unavailable. LTE alone also offers no broadband preference or failover behavior, which defeats the purpose of the dual-transport design and leaves the branch unmanaged from the controller.
D
Deploy a single ION device sized for the branch's aggregate WAN throughput at each branch.
A single appropriately sized ION device at each branch terminates both the broadband and LTE transports, runs the SD-WAN overlay, and applies policy, which satisfies the fabric requirement while keeping hardware count and cost at the branch minimal. Sizing to the branch's aggregate WAN throughput avoids over-provisioning, directly meeting the stated cost constraint.

Review the full routing breakdown →

Question 3mediummultiple choice

When configuring Data Center Interconnect (DCI) between two sites, you notice that routing loops are occurring. What is the most effective way to prevent this in a dual-homed DCI scenario?

Trap 1: Disable OMP on the DCI interface.

Disabling OMP would break the overlay connectivity.

Trap 2: Increase the OMP cost on all routes.

Increasing cost is a path selection mechanism, not a loop prevention mechanism.

Trap 3: Configure a static route to the peer site.

Static routes do not prevent dynamic routing loops effectively in complex topologies.

A
Disable OMP on the DCI interface.
Why it fails: Disabling OMP would break the overlay connectivity.
B
Increase the OMP cost on all routes.
Why it fails: Increasing cost is a path selection mechanism, not a loop prevention mechanism.
C
Implement Site-of-Origin (SoO) extended communities on the DCI links.
SoO tags are specifically designed to prevent loops in multi-homed BGP/OMP environments.
D
Configure a static route to the peer site.
Why it fails: Static routes do not prevent dynamic routing loops effectively in complex topologies.

Read the full Scenario explanation →

Question 4hardmultiple choice

In a scenario where a branch office loses its internet connection, what happens to the Unified SASE connection?

Trap 1: The SD-WAN controller disables the branch

The SD-WAN controller does not disable a branch when its internet link drops; it recalculates paths and fails traffic over to remaining links or Prisma Access. It tempts because the controller manages branch connectivity, but the actual behaviour is failover, not deactivation.

Trap 2: The traffic is automatically dropped

Unified SASE ION devices maintain tunnel redundancy, so losing one internet circuit fails traffic over to the secondary path rather than dropping it. Dropping occurs only when every available link is exhausted. The option tempts because a single-homed branch with no backup genuinely would lose connectivity, but that is a topology limitation, not SASE behaviour.

Trap 3: Traffic is sent to the default gateway without security

Unified SASE never bypasses inspection; when the primary tunnel fails, traffic either fails over to a secondary tunnel or is blocked by the default action, so it is not forwarded unsecured to the gateway. The option tempts because a non-SASE branch router with no policy would indeed route straight out, which is the scenario this design exists to prevent.

A
The SD-WAN system automatically fails over to an available secondary path
SD-WAN continuously monitors path health and, on primary link failure, reroutes traffic over a secondary WAN link, preserving the tunnel to Prisma Access. This satisfies the resilience constraint by maintaining the Unified SASE connection without manual intervention.
B
The SD-WAN controller disables the branch
Why it fails: The SD-WAN controller does not disable a branch when its internet link drops; it recalculates paths and fails traffic over to remaining links or Prisma Access. It tempts because the controller manages branch connectivity, but the actual behaviour is failover, not deactivation.
C
The traffic is automatically dropped
Why it fails: Unified SASE ION devices maintain tunnel redundancy, so losing one internet circuit fails traffic over to the secondary path rather than dropping it. Dropping occurs only when every available link is exhausted. The option tempts because a single-homed branch with no backup genuinely would lose connectivity, but that is a topology limitation, not SASE behaviour.
D
Traffic is sent to the default gateway without security
Why it fails: Unified SASE never bypasses inspection; when the primary tunnel fails, traffic either fails over to a secondary tunnel or is blocked by the default action, so it is not forwarded unsecured to the gateway. The option tempts because a non-SASE branch router with no policy would indeed route straight out, which is the scenario this design exists to prevent.

Question 5easymultiple choice

A manufacturing company is designing its Prisma SD-WAN topology. The design team wants a simple hub-and-spoke model where all branch-to-branch traffic flows through the data center hub for inspection. Which topology design should be specified in the fabric?

Trap 1: A full mesh topology where every branch connects directly to every…

A full mesh would let branch-to-branch traffic take direct paths, bypassing the data center hub and the inspection point the company requires. While full mesh can reduce latency, it conflicts with the explicit design goal of forcing all branch-to-branch traffic through the hub for inspection, so it is not the correct choice here.

Trap 2: A point-to-point topology where each branch connects only to one…

Point-to-point between pairs of branches does not scale and does not route traffic through a central inspection point. It also fails to provide the hub connectivity needed for branch-to-data-center traffic, so it does not satisfy the stated topology or inspection requirements.

Trap 3: A partial mesh topology where branches connect directly to each…

Partial mesh allows some branch-to-branch traffic to bypass the hub, which would let traffic escape inspection. Even though it includes the hub, the direct branch-to-branch paths violate the requirement that all inter-branch traffic flow through the data center, making it unsuitable for this design.

A
A full mesh topology where every branch connects directly to every other branch
Why it fails: A full mesh would let branch-to-branch traffic take direct paths, bypassing the data center hub and the inspection point the company requires. While full mesh can reduce latency, it conflicts with the explicit design goal of forcing all branch-to-branch traffic through the hub for inspection, so it is not the correct choice here.
B
A point-to-point topology where each branch connects only to one other branch
Why it fails: Point-to-point between pairs of branches does not scale and does not route traffic through a central inspection point. It also fails to provide the hub connectivity needed for branch-to-data-center traffic, so it does not satisfy the stated topology or inspection requirements.
C
A hub-and-spoke topology where branches connect through the data center hub
A hub-and-spoke topology directs branch-to-branch traffic through the central hub, which in this design is the data center where inspection occurs. This matches the company's requirement that all branch-to-branch traffic be inspected and provides predictable, centralized control over inter-branch flows.
D
A partial mesh topology where branches connect directly to each other and to the hub
Why it fails: Partial mesh allows some branch-to-branch traffic to bypass the hub, which would let traffic escape inspection. Even though it includes the hub, the direct branch-to-branch paths violate the requirement that all inter-branch traffic flow through the data center, making it unsuitable for this design.

Question 6mediummultiple choice

A network engineer is configuring a Prisma SD-WAN ION device at a branch that has a single WAN link with a public IP address. The branch also has a local subnet of 192.168.10.0/24. The engineer wants to ensure that all traffic from the local subnet to the internet is translated to the WAN IP address. Which type of NAT should be configured?

Trap 1: Static NAT with a one-to-one mapping between each local host and…

Static NAT creates a permanent one-to-one mapping, which would require multiple public IP addresses for multiple hosts. With a single WAN IP, this is not feasible for an entire subnet, and it is unnecessary for outbound internet access.

Trap 2: Port Address Translation (PAT) using a pool of public IP addresses

PAT is a form of Source NAT that uses port numbers to multiplex multiple private addresses over a single public IP, but the scenario specifies a single WAN IP, not a pool. While PAT could work with a single IP, the question asks for the type of NAT, and SNAT is the correct category.

Trap 3: Destination NAT (DNAT) with a translation to the WAN interface IP

Destination NAT is used to translate the destination IP of incoming traffic, typically for port forwarding. It does not translate the source addresses of outbound traffic, so it would not allow the local subnet to access the internet using the WAN IP.

A
Source NAT (SNAT) with a translation to the WAN interface IP
Source NAT translates the private source IP addresses of the local subnet to the public WAN IP, allowing outbound internet access. This is the standard configuration for hiding internal addresses behind a single public IP, and it matches the requirement to translate all traffic from the local subnet.
B
Static NAT with a one-to-one mapping between each local host and the WAN IP
Why it fails: Static NAT creates a permanent one-to-one mapping, which would require multiple public IP addresses for multiple hosts. With a single WAN IP, this is not feasible for an entire subnet, and it is unnecessary for outbound internet access.
C
Port Address Translation (PAT) using a pool of public IP addresses
Why it fails: PAT is a form of Source NAT that uses port numbers to multiplex multiple private addresses over a single public IP, but the scenario specifies a single WAN IP, not a pool. While PAT could work with a single IP, the question asks for the type of NAT, and SNAT is the correct category.
D
Destination NAT (DNAT) with a translation to the WAN interface IP
Why it fails: Destination NAT is used to translate the destination IP of incoming traffic, typically for port forwarding. It does not translate the source addresses of outbound traffic, so it would not allow the local subnet to access the internet using the WAN IP.

Question 7mediummultiple choice

An engineer is deploying a Prisma SD-WAN branch site where the ION device will use a single LTE WAN link with a dynamic public IP address assigned by the carrier. The device must establish a control connection to the Prisma SD-WAN controller and be managed centrally. Which deployment method should the engineer use?

Trap 1: Deploy the ION in transparent bridge mode and manually assign a…

Transparent bridge mode is used for inline traffic inspection without routing, not for initial controller connectivity. A management IP from the local LAN would not provide the required outbound path to the Prisma SD-WAN controller over the LTE WAN link. This method does not satisfy the deployment requirement.

Trap 2: Configure the ION with a static public IP address provided by the…

LTE carriers typically do not provide a static public IP without a special APN and business plan. Forcing a static IP on the ION would not match the carrier-assigned address and would prevent the control connection from forming. The scenario explicitly states a dynamic public IP, so this approach is invalid.

Trap 3: Configure a static route on the ION pointing to the carrier's DNS…

Manually entering a controller IP is not supported because the controller endpoint is discovered dynamically via the Prisma SD-WAN service. A static route to a DNS server does not address the dynamic public IP or the need for automated provisioning. This approach would fail to establish management connectivity.

A
Deploy the ION in transparent bridge mode and manually assign a management IP from the local LAN.
Why it fails: Transparent bridge mode is used for inline traffic inspection without routing, not for initial controller connectivity. A management IP from the local LAN would not provide the required outbound path to the Prisma SD-WAN controller over the LTE WAN link. This method does not satisfy the deployment requirement.
B
Configure the ION with a static public IP address provided by the carrier before shipping.
Why it fails: LTE carriers typically do not provide a static public IP without a special APN and business plan. Forcing a static IP on the ION would not match the carrier-assigned address and would prevent the control connection from forming. The scenario explicitly states a dynamic public IP, so this approach is invalid.
C
Configure a static route on the ION pointing to the carrier's DNS server and manually enter the controller IP.
Why it fails: Manually entering a controller IP is not supported because the controller endpoint is discovered dynamically via the Prisma SD-WAN service. A static route to a DNS server does not address the dynamic public IP or the need for automated provisioning. This approach would fail to establish management connectivity.
D
Use Zero-Touch Provisioning (ZTP) with the ION's serial number registered in the Prisma SD-WAN portal.
ZTP allows the ION to automatically discover the controller using its serial number and the LTE interface's dynamic IP. The ION initiates an outbound connection, so no inbound reachability is needed. This is the intended deployment method for dynamic WAN links and is fully supported for LTE.