Unified SASE practice questions

A pre-installed certificate on the endpoint host

Why it fails: The ION device authenticates to Prisma Access using its own device certificate and activation PIN, not a certificate installed on an endpoint host. It is tempting because certificates underpin tunnel authentication, and would be correct when securing endpoint-to-service connections via GlobalProtect rather than site-to-cloud tunnels.

An on-premise Active Directory server

Why it fails: Prisma Access authenticates branch ION devices through its own cloud identity and certificate infrastructure; an on-premises Active Directory server is not consulted for tunnel establishment. It is tempting because AD often provides identity for policy, and would be correct when user-based rules require directory group lookups rather than device onboarding.

A physical MPLS line at the branch

Why it fails: The ION reaches Prisma Access over any internet WAN link, so a dedicated MPLS circuit is not required; the actual prerequisite is valid licensing and activation of the Prisma Access service connection. MPLS would be chosen where guaranteed private transport to a legacy data centre is mandated.

Use a custom NAT rule on the ION

Why it fails: NAT rewrites addresses and ports; it cannot classify trusted SaaS applications for Cloud SWG bypass. That requires a Prisma Access steering rule or app-based bypass policy matching those SaaS apps. Custom NAT rules are tempting for address translation or overlapping-subnet scenarios, not application-aware steering decisions.

Disable the Service Connection at the branch

Why it fails: Disabling the Service Connection removes the branch's path into Prisma Access entirely, so traffic cannot be steered there while selectively bypassing Cloud SWG. Service Connections are tempting when troubleshooting tunnel or onboarding issues, but the requirement needs per-application bypass rules, not removal of connectivity.

Configure an exclusion list in the Cloud Identity Engine

Why it fails: Cloud Identity Engine handles identity mapping and directory integration for policy; it does not define which SaaS applications skip Cloud SWG inspection. An exclusion list is tempting because it sounds like a bypass mechanism, but application-level bypass belongs in Prisma Access steering or SWG policy.

The ION device performs DPI and injects user info

Why it fails: DPI on the ION device inspects packets but does not supply directory identity to Prisma Access policy. Identity is conveyed by the Cloud Identity Engine, which maps users to IP addresses from Microsoft Entra ID and pushes that context to Prisma Access; ION DPI would be relevant for application-based path selection instead.

Prisma Access performs IP-based reverse lookups

Why it fails: Reverse lookups resolve an IP to a hostname, not to an authenticated directory user, so they cannot supply group or user attributes for policy. The Cloud Identity Engine provides those user-to-IP mappings from Microsoft Entra ID; reverse lookups would suit asset identification or DNS troubleshooting rather than identity-based enforcement.

The SD-WAN controller acts as the identity proxy

Why it fails: The SD-WAN controller manages fabric, tunnels and policy distribution, but holds no directory identity data. User-to-IP mapping is delivered by the Cloud Identity Engine, which ingests Microsoft Entra ID attributes and shares them with Prisma Access; the controller would be the right component for device and path orchestration.

To monitor bandwidth usage

Why it fails: Bandwidth is monitored via performance stats.

To configure a firewall rule

Why it fails: A firewall rule filters traffic; it does not establish the encrypted tunnel linking an ION device to Prisma Access. The Service Connection is that IPsec/IKE tunnel carrying branch traffic to the security service, so it would be the correct answer where secure connectivity to Prisma Access is being described.

To manage branch-to-branch routing

Why it fails: Branch-to-branch routing is handled by the Prisma SD-WAN fabric's dynamic path selection and routing tables, not by the Service Connection, which binds the ION to Prisma Access for secure internet and SaaS breakout. It tempts because service connections do carry traffic between sites, but that is a side effect, not their defined role.

The user is forced to re-authenticate

Why it fails: Service Connection failover reroutes traffic to an alternate Prisma Access node or enforces a security policy; it does not invalidate the user's session and force re-authentication. It is tempting because authentication failures do prompt re-login, and would be correct if the identity provider or token validation were the unreachable component.

The ION device restarts

Why it fails: An unreachable Prisma Access node triggers tunnel failover or a policy-based action; the ION device keeps forwarding and does not restart. It is tempting because reboots resolve some tunnel faults, and would be correct where a configuration change or firmware fault, not node reachability, causes the device to reload.

The traffic is dropped

Why it fails: Service Connection failover relies on the Prisma Access node being reachable; if it is not, traffic is not silently dropped but follows the configured fallback behaviour, such as routing direct to the internet or to an alternate node. Dropping applies only when no fallback path exists and policy explicitly denies the flow.

In the ION device firmware settings

Why it fails: Traffic exclusions are configured as Prisma Access decryption or inspection exemptions in Strata Cloud Manager policy, not on the ION device. Firmware settings govern the device's own forwarding and tunnel behaviour. Device-level configuration is tempting because branch appliances do enforce local policy, but inspection bypass for SASE lives in the cloud security policy.

In the Cloud Identity Engine

Why it fails: The Cloud Identity Engine handles user and group identity mapping for policy, not traffic inspection exemptions. Excluding traffic from inspection is defined through decryption exclusions or no-decrypt policies in Prisma Access, so this location cannot satisfy the requirement.

Inside the Prisma Access Security Policy

Why it fails: Security policy decides what to do if traffic arrives; steering decides if it gets there.

Create a service connection on the ION device and bind it to the Finance VLAN interface.

Why it fails: A service connection is a tunnel to Prisma Access, but binding it to a VLAN interface is not a supported configuration. Service connections are logical tunnels, and traffic is directed to them via policies, not by binding to physical or VLAN interfaces. This approach would not selectively route Finance traffic.

Enable the 'Secure Internet Gateway' feature on the ION device and apply it to the Finance VLAN.

Why it fails: The ION device does not have a feature called 'Secure Internet Gateway'. Prisma Access provides secure internet gateway functionality, but it is not enabled per VLAN on the ION. The ION uses policies to redirect traffic to Prisma Access, not a SIG feature.

Configure a static route for the Finance VLAN subnet pointing to the Prisma Access Service Connection.

Why it fails: A static route directs traffic based on destination subnet, not source VLAN. Since both Finance and Guest VLANs likely access the same internet destinations, a static route would affect all traffic, not just Finance. This does not meet the requirement of selective inspection by source VLAN.

Prisma Access Explicit Proxy

Why it fails: Explicit proxy requires endpoint configuration and does not automatically apply to all traffic from an ION device. It is designed for user-initiated web traffic, not for transparently steering all branch traffic to Prisma Access for inspection. It also does not unify policy between the ION and Prisma Access, so it fails the requirement of a single policy for all traffic.

Prisma Access Service Connection

Why it fails: A Service Connection provides the tunnel between the ION and Prisma Access, but it does not itself unify security policy. The administrator would still need to configure policies separately on the ION and in Prisma Access. Service Connection is a connectivity component, not a policy unification feature, so it does not meet the requirement.

Prisma SD-WAN Policy Construct

Why it fails: A Policy Construct in Prisma SD-WAN defines how traffic is treated on the ION, such as path selection and QoS, but it does not extend security inspection to Prisma Access. It cannot enforce a consistent security policy across both the branch and the cloud security service. Therefore, it does not satisfy the need for unified policy enforcement.

Configure a GRE tunnel to the nearest Prisma Access location and enable OSPF over the tunnel.

Why it fails: While a GRE tunnel can forward traffic for inspection, it lacks the automated failover and path quality monitoring of a Service Connection with Dynamic Path Selection. OSPF over the tunnel does not automatically move the tunnel to the secondary ISP when the primary link fails.

Configure a static route to Prisma Access using the primary ISP and enable BGP graceful restart.

Why it fails: A static route pins traffic to one ISP and does not provide automatic failover to the secondary link. BGP graceful restart helps with route convergence but does not move the Service Connection tunnel between ISP links. This design would break inspection when the primary ISP fails.

Configure a Cloud SWG explicit proxy and set the ION device to forward all HTTP and HTTPS traffic to it.

Why it fails: A Cloud SWG explicit proxy inspects web traffic but does not natively provide the SD-WAN path selection or automatic failover between ISP links required here. It also does not cover non-web traffic, so it fails the requirement to inspect all internet-bound traffic with link resiliency.

Configure a static route on the ION device pointing the SaaS application's subnet to the Prisma Access tunnel interface.

Why it fails: While a static route could steer traffic, it lacks the policy-based granularity and application awareness required. Prisma SD-WAN uses policy rules, not static routes, for service connection steering. Static routes would also apply to all traffic matching the destination, potentially overriding other policies and not allowing exceptions easily.

Set the ION device's default gateway to the Prisma Access tunnel endpoint so all traffic is inspected.

Why it fails: Setting the default gateway to the tunnel would force all traffic through Prisma Access, contradicting the requirement that other internet-bound traffic goes directly out the local internet link. This would also likely break local internet connectivity and add unnecessary latency and cost.

Enable 'Local Breakout' for all internet-bound traffic and rely on Prisma Access to inspect traffic via a separate tunnel.

Why it fails: This fails because local breakout sends traffic directly to the internet without inspection. Prisma Access would not see that traffic unless a separate tunnel is established, which is not the case here. The requirement is to inspect only specific SaaS traffic, not all, and local breakout does not provide inspection.

Enable IPsec on the ION devices for all traffic.

Why it fails: While IPsec is used for encryption, enabling it globally on the ION does not specifically create the service connection to Prisma Access. The Service Connection itself uses IPsec, but the configuration is done through the service connection setup, not by manually enabling IPsec on all traffic. This option is too broad and not the correct specific configuration.

Configure a static route on the ION devices pointing all traffic to the Prisma Access tunnel.

Why it fails: A static route for all traffic would force all traffic through Prisma Access, but it does not address the requirement to preserve the original source IP. It also may not be desirable if some traffic should bypass Prisma Access. It is not a required configuration for encryption and source IP preservation.

Enable source NAT on the ION devices for traffic destined to Prisma Access.

Why it fails: Source NAT would translate the original source IP address of branch devices, which would prevent Prisma Access from applying policies based on the original source IP. The requirement is to preserve the original source IP, so source NAT must not be enabled for this traffic. Therefore, this option is incorrect.

Prisma Cloud Compute for container security at each store.

Why it fails: Prisma Cloud Compute is a cloud workload protection platform for containers and hosts, not a network security service for branch internet access. It does not provide URL filtering or threat prevention for user traffic. This component is irrelevant to the retail store SD-WAN security requirements and would not address the need for secure internet access.

Prisma Access Mobile Users with GlobalProtect on store endpoints.

Why it fails: GlobalProtect is designed for mobile users and remote endpoints, not for securing traffic from a branch ION device. Deploying GlobalProtect on each store's endpoints would be operationally intensive and does not leverage the SD-WAN infrastructure. This solution does not provide the centralized, network-based security inspection required for store internet traffic.

Prisma SD-WAN Advanced Security license on each ION device.

Why it fails: While Prisma SD-WAN Advanced Security provides next-generation firewall capabilities on the ION, it requires sufficient hardware resources at each store and increases management complexity. For 200 stores, this would mean managing security policies on each device or via templates, which may not minimize overhead. Cloud SWG offloads inspection to the cloud, reducing on-premises footprint.

The data center subnet is not included in the Prisma Access 'Remote Networks' configuration, so Prisma Access does not know to route traffic to the data center via the Service Connection.

Why it fails: Remote Networks in Prisma Access define the branch networks that Prisma Access should route traffic to. If the data center subnet is missing, Prisma Access might not route return traffic correctly, but the forward path from branch to data center would still be via the Service Connection. However, the issue is that users cannot access data center applications, which could be due to asymmetric routing if return traffic goes elsewhere.

The data center subnet is not included in the Service Connection's 'Local Networks' configuration.

Why it fails: Local Networks typically define which subnets are advertised from the branch to Prisma Access for reverse traffic. If missing, Prisma Access might not know how to route return traffic to the branch, but the symptom is usually that Prisma Access cannot initiate connections to the branch. Here, users cannot access data center applications, which suggests the forward path from branch to data center is failing, not the return path.

The ION device is not configured to route data center traffic through the Service Connection; it is sending it directly over the VPN, bypassing Prisma Access.

Why it fails: If the ION device sends data center traffic directly over the VPN, it bypasses Prisma Access, but that would not necessarily cause a failure unless the VPN is down. The administrator verified that the ION has a route to the data center via the VPN, so this is unlikely. The issue is more likely related to policy or routing within Prisma Access.

The ION device's CPU and memory utilization remaining below 80 percent.

Why it fails: CPU and memory utilization are health metrics for the device itself, not indicators of Service Connection status. A device can have low utilization while the Service Connection is down, or high utilization while it is up. This does not verify tunnel establishment.

The ION device's WAN interface link status showing green for both ISP links.

Why it fails: WAN interface link status only indicates physical or data-link connectivity to the ISP. It does not confirm that the Service Connection tunnel to Prisma Access is established or that traffic is being inspected. Both links can be up while the Service Connection is down.

The BGP neighbor state on the ION device showing Established with the Prisma Access peer.

Why it fails: BGP may be used over the Service Connection for route exchange, but BGP neighbor state alone does not confirm the Service Connection tunnel is up and passing traffic. The tunnel could be down while BGP shows established over a different path, so this is not the primary indicator.

Prisma Access and Prisma SD-WAN are correlating logs incorrectly due to mismatched session identifiers.

Why it fails: Log correlation issues would not cause one system to log allowed and the other denied for the same session; they would simply fail to link the logs. The discrepancy is about differing actions, not missing correlation. This explanation does not address why the actions differ.

The traffic matched a deny rule in Prisma SD-WAN for outbound but was allowed by Prisma Access on the return path.

Why it fails: Prisma Access inspects traffic in the direction it receives it. If the outbound traffic was denied by Prisma SD-WAN, it would not be sent to Prisma Access. A deny on the return path is unlikely because return traffic typically follows the same session. This explanation is not consistent with the session flow.

The ION device is applying a security policy that denies the traffic before it reaches Prisma Access.

Why it fails: If the ION denied the traffic, it would not reach Prisma Access, so Prisma Access would not log it as allowed. The discrepancy indicates that both systems processed the session, meaning the ION did not deny it. Therefore, this explanation contradicts the observed logs from both systems.

Configure a policy rule that sends traffic directly to the internet if the Service Connection is down, to maintain availability.

Why it fails: This fails because it bypasses inspection when the Service Connection is down, violating the requirement that traffic must always be inspected. While availability is maintained, security is compromised. The requirement explicitly states that inspection must occur even if the primary Service Connection fails.

Set up a GRE tunnel directly to Prisma Access as a backup, bypassing the Service Connection.

Why it fails: A GRE tunnel to Prisma Access would still be a Service Connection, but manually configured. However, the question asks for a feature that ensures inspection during failure. While a GRE tunnel could serve as a backup, it is not the recommended or automated method. The Service Connection Backup feature is designed for this purpose and integrates with the SD-WAN fabric.

Use 'Local Breakout' with a security policy applied to the ION device to inspect traffic locally.

Why it fails: Local breakout sends traffic directly to the internet, and while the ION device can apply some security policies, it does not provide the full inspection capabilities of Prisma Access. The requirement is for Prisma Access inspection, so local breakout does not meet the need. Additionally, local breakout does not provide redundancy for the Service Connection.

The Prisma Access Cloud Management console, which aggregates logs from all Prisma Access tenants.

Why it fails: Prisma Access Cloud Management focuses on managing Prisma Access security services and logs, but it does not natively correlate with Prisma SD-WAN network logs. While it provides security event visibility, the correlation of network and security data requires integration with the SD-WAN management platform or a SIEM, which is not the primary function of this console.

The ION device's local logging feature, which stores both network and security logs and forwards them to a central syslog server.

Why it fails: ION devices generate network logs and can forward them to a syslog server, but they do not process or store Prisma Access security logs. The security logs are generated in the Prisma Access cloud, not on the ION device. Therefore, the ION device cannot correlate the two log sources; this requires a centralized analytics platform that ingests both.

The Prisma SD-WAN Controller, which collects flow data from ION devices and correlates it with security events from Prisma Access.

Why it fails: The Prisma SD-WAN Controller manages the SD-WAN fabric and collects network telemetry, but it does not directly ingest or correlate Prisma Access security logs. Its role is to orchestrate the SD-WAN overlay and enforce policies, not to provide a unified security and network log correlation view. This correlation typically requires a separate analytics or SIEM platform.

The ION device's routing table to confirm that the SaaS application's IP addresses are not routed directly to the internet.

Why it fails: While routing is important, policy rules take precedence over routing in Prisma SD-WAN for traffic steering. If the policy rule is correctly configured and not overridden, the ION will send traffic to the Service Connection regardless of the routing table. Checking the routing table might be a secondary step but is less likely to be the root cause.

The Prisma Access security policy to ensure that the SaaS application is not blocked.

Why it fails: If the SaaS application were blocked, users would likely experience a denial of service, not just lack of inspection. The issue is that traffic is not being inspected, meaning it is bypassing Prisma Access. A security policy block would prevent access, not bypass inspection.

The Service Connection's encryption settings to verify that the SaaS application's traffic is not being decrypted before inspection.

Why it fails: Encryption settings affect whether traffic can be inspected, but if the traffic is not being sent to Prisma Access at all, encryption is irrelevant. The problem is that the traffic is not reaching Prisma Access for inspection, so the administrator should focus on why the policy is not steering it correctly.

Configure a single Service Connection with OSPF and enable graceful restart to handle failover.

Why it fails: OSPF is not typically used for Service Connections to Prisma Access; BGP is the standard routing protocol. Graceful restart helps with failover but does not provide a secondary path if the primary tunnel fails. A single Service Connection, even with OSPF, would not offer automatic failover to another tunnel. This option does not meet the requirement for efficient path selection and automatic failover.

Configure a single Service Connection with BGP and rely on the ION device's built-in redundancy to switch to a backup WAN link if the tunnel fails.

Why it fails: While the ION device can fail over to a backup WAN link, this does not automatically re-establish the Service Connection tunnel to Prisma Access. The tunnel is bound to a specific WAN interface; if that interface fails, the tunnel goes down. Without a secondary tunnel configured, traffic would either be dropped or sent directly to the internet, bypassing security. Therefore, this configuration does not provide seamless failover for the Service Connection itself.

Configure two Service Connections with static routes and equal cost, relying on ECMP for load balancing and failover.

Why it fails: While ECMP can provide load balancing and failover, static routes do not adapt to network changes as dynamically as BGP. ECMP may also require careful configuration to avoid asymmetric routing. In Prisma SD-WAN, BGP is preferred for Service Connections to Prisma Access because it allows the ION device to learn routes and select the best path. Static routes with ECMP can work but are less efficient and may not provide the same level of automatic failover.

Set the default route on the ION device to point to the Service Connection.

Why it fails: Setting the default route to the Service Connection would send all traffic, including data center traffic, to Prisma Access. This violates the requirement that data center traffic bypass inspection. While it would ensure internet traffic is inspected, it would also inspect data center traffic, which is not desired. Policy rules, not default routes, should be used for selective steering.

Enable 'Local Breakout' for all traffic to reduce latency.

Why it fails: Local breakout would send traffic directly to the internet, bypassing Prisma Access inspection. This contradicts the requirement that internet-bound traffic be inspected. While it reduces latency, it sacrifices security. The engineer must prioritize inspection for internet traffic, so local breakout is not appropriate here.

Configure the Service Connection to advertise a default route to Prisma Access.

Why it fails: Advertising a default route from the branch to Prisma Access would cause Prisma Access to send all return traffic to the branch, which is not the issue. The requirement is about outbound traffic from the branch. This action does not affect how branch traffic is steered and could cause routing loops or suboptimal paths.