PSE SASE common mistakes
PSE SASE · Understand the traps and how to avoid them.
Treating ZTNA as a VPN replacement and describing user-to-app access as 'connecting to the network', then answering policy questions by mapping users to subnets or IP ranges instead of to applications and identities.
Candidates carry over VPN mental models from traditional remote access and from firewall practice, where source IP and zone define the rule. Prisma Access ZTNA is application- and identity-centric, so that mental model produces wrong answers about what a policy can match on and where enforcement happens.
What to do instead
Re-learn the model explicitly: access is granted per application (FQDN or internal app), per user or group from the identity provider, with continuous trust evaluation. Practice writing a rule set as 'who (IdP group) -> what (app) -> under what conditions (device posture, region)' and check each answer against that chain rather than against an IP topology.
Assuming ZTNA policy is enforced only in the cloud and forgetting that the on-premises side needs a Connector or equivalent app-side component, so questions about private-app reachability and connector redundancy are answered as if the cloud alone can reach internal servers.
The marketing emphasis on cloud-delivered security leads candidates to picture a single plane. In reality private applications require a component that terminates the tunnel inside the data centre or VPC, and high availability of that component is a common design question.
What to do instead
Draw the full path once (user device -> closest Prisma Access location -> connector -> private app) and annotate where inspection, identity check, and encryption termination happen. Memorise that connector redundancy and placement, not cloud region count, drive private-app availability.
Confusing SD-WAN policy constructs: answering questions about traffic steering as if a single 'SD-WAN policy' object handles path selection, application SLA, and breakout, and mixing up which element is evaluated first when a flow matches multiple rules.
The product exposes several related constructs (traffic distribution, path quality/SLA profiles, application and SaaS definitions, breakout rules). Candidates learn the names but not the evaluation order, so they pick a plausible-sounding object that exists but is not the one that decides the outcome.
What to do instead
Build a one-page decision map: which object classifies the flow, which one measures SLA and chooses the path, and which one decides whether traffic egresses locally or backhauls. For each practice question, name the object class before evaluating the options, and reject options that name a real feature used at the wrong stage.
Treating SD-WAN path selection as static or as simple failover, and answering that traffic always prefers the primary link unless it is down, instead of applying per-application SLA thresholds with continuous probing and measured metrics such as latency, jitter, and packet loss.
Classic WAN designs use primary/backup with dead-peer detection, so candidates default to binary up/down logic. Prisma SD-WAN steers per application based on measured path quality against a defined SLA, which changes the answer whenever the stem mentions degradation rather than outage.
What to do instead
When a stem mentions slow, jittery, or lossy links, treat it as an SLA question, not a failover question. Identify the application's SLA profile, the measured metric that breached it, and the alternate path that meets the profile; discard answers that hinge on link state alone.
Assuming Prisma Browser protects only traffic that flows through it, and therefore answering that users who bypass the browser or use a non-managed browser are equally covered, or that browser protection replaces the need for a forwarding/agent path for non-web protocols.
Candidates conflate 'secure browser' with 'secure web gateway for everything'. Browser-based protection covers the browsing session and its data flows; other traffic classes and unmanaged devices follow different paths, and exam stems often hinge on that distinction.
What to do instead
Classify each scenario by traffic type and device management state before answering: managed browser session, unmanaged device, thick-client or non-HTTP protocol. State which enforcement point covers each class, and treat browser isolation/control as one layer in a layered architecture, not a universal substitute.
Answering Prisma Browser questions as if isolation and DLP are the same control, e.g. claiming isolated sessions prevent data copy-paste exfiltration without any DLP policy, or claiming DLP inspection works identically inside an isolated, pixel-streamed session.
Isolation and DLP are often described together in product narratives, so candidates merge them. Technically, isolation changes what the endpoint receives (rendered content rather than raw content), which alters what can be inspected and what user actions are possible.
What to do instead
Separate the two: isolation limits local execution and can restrict clipboard, download, upload, and printing; DLP classifies and acts on content. For each question ask whether the control needed is about where code runs or about what data is, and choose accordingly.
Treating SaaS Security as identical to CASB inline proxy control, and answering that unsanctioned SaaS use is blocked by the firewall or proxy alone, ignoring API-based visibility into sanctioned apps and the tenant-side configuration posture checks.
Candidates study inline web policy and assume all SaaS control is inline. In practice, sanctioned-tenant protection depends on API integration for visibility and on posture/misconfiguration findings, which inline inspection cannot see (for example sharing settings or MFA enforcement inside the tenant).
What to do instead
Split the domain into three lanes: discovery of unsanctioned apps from traffic, API-based control and posture assessment for sanctioned tenants, and inline control where traffic passes a security stack. Match each stem to the lane by asking whether the evidence lives in network traffic or inside the tenant.
Confusing SaaS Security posture findings with DLP incidents, so a question about an overshared file or a publicly exposed bucket is answered with a data-pattern rule, and a question about a credit card number leaving via email is answered with a sharing-permission check.
Both domains surface 'data exposure' language. Posture findings are about configuration and permissions; DLP is about content matching and response actions on a data flow. Candidates pick whichever term they studied last.
What to do instead
Use a two-question test: is the problem that access is misconfigured (posture), or that specific content is moving to a place it should not (DLP)? Answer with the mechanism that detects the actual condition named in the stem, and note that remediation differs: config change versus block/quarantine/alert on the flow.
Designing DLP as a single pattern match and ignoring the data profile/classification step, the policy's traffic direction and target, and the response action, so answers omit that the same content in a different direction or to a different destination can be allowed.
Candidates reduce DLP to regex. Enterprise DLP evaluates what data it is (classification and profiles), where it is going (destination, app, direction), who is sending it (user, group), and what to do (allow, alert, block, quarantine, coach). Missing one dimension yields an answer that is technically a feature but not the policy described.
What to do instead
For every DLP question, write the four slots explicitly (data, direction/destination, subject, action) and check the chosen option fills the slot the stem is testing. Practise distinguishing detect-and-alert from block, and inline enforcement from out-of-band/reporting-only paths.
Assuming DLP inspection happens everywhere automatically, including inside encrypted SaaS sessions or on traffic that never traverses an inspection point, and answering that a DLP policy alone guarantees blocking regardless of deployment path.
DLP is a policy layer that needs a data path and, for encrypted traffic, the ability to inspect it. Candidates who learn policy objects in isolation forget the enforcement prerequisite, which is exactly what scenario questions probe.
What to do instead
Before answering, locate the inspection point for the described flow: forward proxy or security stack for web, API integration for sanctioned SaaS, endpoint for local actions. If the stem's traffic bypasses inspection or is encrypted without inspection, the correct answer is about enabling inspection or choosing a different control, not about tightening the pattern.