# Prisma Access Deep-Dive: Compute Locations, Onboarding, Identity, ZTNA & ADEM Source: https://ai.techclick.in/blog_paloalto_prisma_access_deep_dive Markdown: https://ai.techclick.in/blog_paloalto_prisma_access_deep_dive.md Publisher: Techclick Infosec Pvt Ltd An operations-grade deep dive into Palo Alto Prisma Access — the 3-tier service infrastructure, compute location selection, production-grade onboarding for Mobile Users, Remote Networks and Service Connections, Cloud Identity Engine + HIP posture, ZTNA App Gateway, ADEM telemetry, and log streaming to SIEM. Includes IKEv2 / BGP config snippets, a real branch + WFH design, and a 10-question scenario assessment. Prisma Access Deep-Dive: Compute Locations, Onboarding, Identity, ZTNA & ADEM student learning map A visual study map for Prisma Access Deep-Dive: Compute Locations, Onboarding, Identity, ZTNA & ADEM showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Prisma Access Deep-Dive: Compute Locations,... Palo Alto · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start Pick where you want to start 2. Understand The Prisma Access service... 3. Prove Compute location selection — how... 4. Practice Mobile Users in production —... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Infographic: concept-to-practice path Prisma Access Deep-Dive: Compute Locations, Onboarding,... Learn Pick where you want to start Map The Prisma Access service... Operate Compute location selection — how... Verify Mobile Users in production —... Read in this order so the topic becomes a working runbook, not isolated notes. Start with the mental model, then move into the workflow, evidence, and practice questions. Infographic: evidence ladder Do not answer from memory only - prove the stage Scope who, what, where, when Policy rule, condition, action Telemetry logs, event, metric Retest original symptom fixed Interview signal: every claim should map to observable evidence. Use this ladder when the question asks for troubleshooting, rollout, or proof. Infographic: healthy vs broken thinking Healthy answer vs broken answer Healthy Names the object, follows the flow, checks logs, and validates the result. Broken Lists features randomly, changes production first, or skips verification. Your goal: connect the concept to a realistic production decision. This comparison turns the article into an interview and troubleshooting checklist. Infographic: mini runbook Mini runbook for this topic Before baseline and scope During change one thing After monitor and rollback Use this page to prepare one practical story: problem, evidence, fix, verification. Convert the learning into a practical story you can explain to a manager or interviewer. ## Pick where you want to start 1 ### Service infrastructure Portal, Gateway, Compute Location — the three layers, one fabric. 2 ### Mobile Users CIE auth, HIP posture and split-tunnel for a real fleet. 3 ### Remote Networks Branch onboarding with real IKEv2 + BGP + ECMP. 4 ### Service Connections The one-way pipe into your private estate — done right. ## The Prisma Access service infrastructure — three layers, one fabric Before you click anything in SCM, fix the mental model of what is actually running in Palo Alto's cloud on your behalf. Prisma Access is delivered as three logical layers stitched together inside the service: - The Portal layer. A globally anycast endpoint that every Mobile User agent reaches first. The Portal authenticates the user (via Cloud Identity Engine), evaluates HIP posture, returns the list of Gateways the user is allowed to use, and hands the client a signed configuration. There is exactly one Portal per tenant, replicated worldwide. - The Gateway layer. Per-region cloud Gateways are where the user's IPSec / SSL-VPN tunnel actually terminates. Gateways run the App-ID + Threat Prevention engine and apply your Security policy. The Portal picks the best Gateway per user based on geographic proximity, latency probes and bandwidth load. - The Compute Location layer. The physical region where a Gateway runs (e.g. asia-south1 (Mumbai) , us-east4 (Virginia) ). Compute Locations are the units you reserve bandwidth against and what you allocate Service Connections to. Same compute location can serve Mobile Users and Remote Networks at the same time, sharing the regional bandwidth pool. For Remote Networks, the same Gateway-and-Compute-Location concept applies, but the "user" is a branch CPE building an IPSec tunnel up to a region. For Service Connections, the same again, but now the on-prem firewall is the device terminating into the Compute Location to advertise private routes. Legend endpoint / on-prem side (royal) Prisma Access cloud — Portal & Gateway (cyan) compute location / regional pool (magenta) healthy / traffic flowing broken / dropped Figure 1 — Prisma Access service infrastructure A layered diagram with three rows. Top row shows three Mobile User endpoints reaching a global Portal. Middle row shows three regional Gateways (APAC, EMEA, Americas) each inside a Compute Location with a bandwidth pool. Bottom row shows two on-prem entry points — a branch CPE building an IPSec Remote Network tunnel, and an HQ firewall building a Service Connection IPSec tunnel. Arrows connect endpoints to the Portal, the Portal hands back a Gateway list, then traffic terminates at the regional Gateway and traverses to the internet or to a Service Connection. - Portal → Gateway → Compute Location WFH laptop Hotel laptop Mobile phone PORTAL · global anycast authN + HIP + Gateway-list issuance Compute · asia-south1 Gateway · Mumbai BW pool: 500 Mbps App-ID + Threat Prevention Compute · europe-west2 Gateway · London BW pool: 750 Mbps App-ID + Threat Prevention Compute · us-east4 Gateway · Virginia BW pool: 500 Mbps App-ID + Threat Prevention Branch CPE Remote Network IPSec tunnel HQ firewall Service Connection (private reach) Mobile Users hit the Portal first, get a Gateway list, then build the tunnel directly to a regional Gateway running inside a Compute Location. Branches (Remote Networks) and on-prem firewalls (Service Connections) terminate directly at the regional Compute Location. Bandwidth is reserved per region, shared across all three onboarding modes that use it. ## Compute location selection — how does Prisma pick one? For Mobile Users, the Portal hands the agent a list of allowed Gateways. The agent then runs latency probes to each one and connects to the lowest-RTT Gateway that has spare capacity. If two Gateways have similar RTT, ties break on load. Re-evaluation happens on connect, on network change, and at a configurable interval (default ~120 s). For Remote Networks and Service Connections, you pick the compute location at onboarding time. Prisma will not move a branch tunnel between regions on its own — the operator chooses. The way to handle a regional outage is the same way you'd handle one with a pair of physical firewalls: two tunnels to two different compute locations , BGP advertising the same prefixes, ECMP load-balancing. ### Bandwidth allocation — the most-missed slider Every Prisma Access tenant has a total purchased bandwidth (e.g. 2 Gbps). That total has to be allocated to compute locations. An unallocated region cannot accept traffic. If you forget to allocate bandwidth to asia-south1 before onboarding a Mumbai branch, the IPSec tunnel will negotiate up to Phase 2 and then drop traffic with no obvious cause. Allocate before you onboard. 💡 Pro Tip Over-allocate by ~20% in regions that host both Mobile Users and Remote Networks. The two share the same regional pool — a Friday-afternoon WFH surge can starve a busy branch if you sized to the average instead of the peak. Palo Alto IPSec Simulator Prisma Access Simulator Quick check · Bandwidth allocation You onboard a Mumbai branch into asia-south1 , but forgot to allocate bandwidth to that compute location first. What's the symptom you'll see? a) The IKEv2 negotiation fails at Phase 1 with a clear error. b) The tunnel negotiates up to Phase 2, then traffic silently drops at the Gateway — an unallocated region cannot accept traffic. c) Prisma automatically borrows bandwidth from another region. d) The branch is moved to the nearest region with capacity. Correct: b. An unallocated region cannot accept traffic. The Phase 2 SA comes up but the Gateway drops the data — a "Phase-2-up-but-no-data" symptom in a freshly onboarded region is almost always missing regional bandwidth. Allocate first, onboard second. ## Mobile Users in production — beyond the demo A demo Mobile User is one laptop with one rule. A production fleet of 4,000 endpoints needs deliberate choices on three fronts: authentication, posture, and split-tunnel . ### Authentication via Cloud Identity Engine Cloud Identity Engine (CIE) is the SAML / SCIM layer Prisma Access uses to bring user + group identity into policy. You point CIE at Entra ID, Okta, Ping or any SAML 2.0 IdP, configure the SAML assertion mapping (NameID = UPN, group claim = on), and Prisma now sees every authenticated session by username and group membership. Combine with MFA at the IdP (Entra Conditional Access, Okta Sign-On Policy) and there is no need for a separate Prisma-side OTP step. ### HIP — Host Information Profile HIP is the device-posture gate that runs after auth but before Security policy is applied. Common production checks: Disk encryption is on (BitLocker for Windows, FileVault for macOS). - Endpoint AV (Crowdstrike, Defender, Sentinel One) is running and signature ≤ 7 days old. - OS patch level is within N days of current. - Required certificate is present in the user / machine store. - Required process is running (a custom checker exe, EDR agent, etc.). HIP profiles compose into HIP objects , which are then referenced in Security policy: "only users whose endpoint matches HIP-Object-Compliant can reach Finance apps" . A failed HIP check can drop the tunnel, restrict access to a quarantine subnet, or push a remediation message — your call. ### Split-tunnel design Most production tenants run an include-domain / exclude-domain split-tunnel. Two patterns dominate: - "Tunnel everything except media" — default route through Prisma, but exclude Microsoft Teams / Zoom voice domains so RTP goes direct. Saves Prisma bandwidth and improves call quality. - "Tunnel corporate apps only" — pin specific corporate FQDNs to the tunnel and let everything else go direct. Useful for contractors and BYOD where you don't want to inspect personal traffic. Both modes need accurate domain lists; the Microsoft 365 published JSON of optimize-required-default endpoints is the standard input for the first pattern. Quick check · Identity & posture Your Security policy uses source-user any-in-group('Finance') via Cloud Identity Engine + Entra ID SAML, but it never matches. What's the most likely fix? a) Disable SAML and switch CIE to Kerberos. b) Configure Entra to emit security-group claims in the SAML assertion (or use SCIM) so CIE knows the user's group membership. c) Hardcode each user's UPN into the rule. d) Turn HIP off — posture is blocking the match. Correct: b. Without the group claim in the SAML assertion (or a SCIM feed), CIE has the username but not the groups, so any group-based match fails. Entra's enterprise application config has a checkbox to emit the user's assigned security groups in the token. ## Remote Networks — branch onboarding with real config The Remote Network onboarding flow in SCM walks you through naming, region selection, bandwidth and tunnel parameters. What it does not tell you is how to express the same parameters on a real branch CPE. Here is the production-grade pair: IKEv2 + ESP, with primary + secondary tunnels. IKEv2 + ESP proposal accepted by Prisma Access (CPE side) ! ---- IKEv2 (Phase 1) ---- encryption : aes-256-cbc integrity : sha384 dh-group : group20 (ECP-384) authentication : pre-shared-key lifetime : 28800 seconds dpd : on-demand, 30 s interval, 3 retries ! ---- ESP (Phase 2) ---- encryption : aes-256-gcm integrity : null (implicit with GCM) pfs : group20 lifetime : 3600 seconds, 4 GB data ! ---- Identifiers ---- local-id : fqdn / branch-mumbai-01.example.com remote-id : fqdn / pa-asia-south1.prisma-access.com ! ---- Routing ---- mode : routed (NOT policy-based) local-net : advertised via BGP remote-net : advertised via BGP BGP is the right answer for any branch with more than one prefix or more than one tunnel. Static routes work but become a maintenance burden the moment you add a new internal VLAN. BGP from branch CPE to Prisma Access (primary tunnel) router bgp 64512 bgp router-id 10.20.0.1 neighbor 169.254.10.1 remote-as 65000 ! Prisma Access ASN neighbor 169.254.10.1 ebgp-multihop 2 neighbor 169.254.10.1 update-source Tunnel1 address-family ipv4 unicast network 10.20.10.0/24 ! branch user VLAN network 10.20.20.0/24 ! branch printers VLAN neighbor 169.254.10.1 prefix-list FROM-PA in neighbor 169.254.10.1 prefix-list TO-PA out exit-address-family Duplicate the entire block for the secondary tunnel pointing at a different compute location, then ECMP across both. When Prisma withdraws the prefix it learns from a Service Connection during maintenance, BGP will silently steer that traffic onto the surviving tunnel within seconds. ! Common pitfall Setting NAT-T off on the CPE because "Prisma is reachable directly". Most branches sit behind an ISP-provided NAT — if NAT-T is off the tunnel will negotiate but ESP will be silently dropped. Always leave NAT-Traversal on; the per-packet overhead is negligible. ## Service Connections — the pipe into your private estate A Service Connection is structurally another IPSec tunnel into a Prisma compute location, but its role is one-directional reach: it lets Mobile Users and Remote Networks reach private apps that live behind your on-prem firewall, cloud transit gateway, or IaaS VPC. It is not a path for internet egress. Three production rules: - Two Service Connections from two DCs, into two compute locations. Active-active, both advertising the same private prefixes with BGP. ECMP load-balances; either side surviving a regional outage keeps private reach alive. - Advertise summary routes, not host routes. A typical mistake is advertising 10.30.5.13/32 for an SAP server. Advertise the subnet ( 10.30.5.0/24 ) and let the on-prem fabric route within it. - Don't run a default route over a Service Connection. If you do, every Mobile User on the planet will pull internet through your HQ and Prisma will dutifully hairpin it. That is exactly the design Prisma replaces. Quick check · Service Connections A Service Connection from HQ is advertising the default route ( 0.0.0.0/0 ) into Prisma Access. What happens? a) Nothing — that's the recommended design for Service Connections. b) Prisma rejects the route because a Service Connection can't carry a default. c) Every Mobile User's and branch's internet traffic hairpins through HQ before Prisma sends it out — defeating local breakout and creating a single point of failure. d) Mobile Users immediately lose access to internal apps. Correct: c. Advertising 0/0 over the Service Connection tells Prisma "send all internet traffic to HQ". The SC will accept the route — that's the trap — and every Mobile User and Remote Network then hairpins internet via HQ, exactly the centralised-egress design Prisma replaces. ## The request lifecycle — eight hops in detail Figure 2 — A single HTTPS request through Prisma Access A linear flow diagram: endpoint, GP agent, Portal authentication via Cloud Identity Engine, HIP posture evaluation, Gateway selection, tunnel build, security policy lookup, SSL decryption, App-ID and Threat Prevention, egress to SaaS, with telemetry to ADEM and logs forwarded to Strata Logging Service and SIEM. - A Mobile User opens https://salesforce.com 1. GP agent cert + SAML init 2. Portal · CIE auth SAML to Entra/Okta 3. HIP posture disk, AV, patch 4. Gateway list closest + capacity 5. IPSec / SSL tunnel built to closest regional Gateway (compute location) 6. Security policy User-ID · App-ID · URL 7. SSL decrypt + TP AV · IPS · WildFire · DLP 8. Egress to SaaS via Prisma egress IP ADEM probes per-hop latency + experience score Strata Logging Service → NSS → SIEM traffic, threat, decryption, system Steps 1–4 are control-plane (auth + posture + Gateway selection). Step 5 is the tunnel itself. Steps 6–8 are the data-plane NGFW pipeline. ADEM probes and log forwarding run in parallel and are what makes the service operable on day 2. ### ▶ Watch a Mobile User connect through Prisma Access A WFH laptop in Mumbai opens salesforce.com . Press Play for the healthy path, then Break it to see the classic "bandwidth never allocated" failure — and the fix. ① Portal The GP agent reaches the global anycast Portal first. Cloud Identity Engine authenticates the user via SAML to Entra/Okta. ▼ ② HIP + Gateway list The Portal evaluates HIP posture (disk encryption, AV, patch level), then returns the list of Gateways this user is allowed to use. ▼ ③ Gateway select The agent runs latency probes and builds the IPSec/SSL tunnel to the lowest-RTT Gateway with spare capacity — asia-south1 (Mumbai) . ▼ ④ Inspect The Gateway applies Security policy and the App-ID + Threat Prevention pipeline (User-ID, URL, SSL decrypt, WildFire, DLP) on the session. ▼ ⑤ Egress + telemetry If policy allows, traffic egresses to Salesforce via the Prisma egress IP. ADEM scores each segment; logs stream to the Strata Logging Service → NSS → SIEM. Press Play to step through the healthy path, then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · The request path In the healthy flow above, what does the Portal hand back to the GlobalProtect agent before any tunnel is built? a) The decrypted traffic, ready to forward. b) A signed configuration plus the list of Gateways the user is allowed to use — the agent then probes and picks the lowest-RTT one. c) A fixed single Gateway, chosen by the Portal alone. d) Nothing — the agent connects directly to the destination. Correct: b. The Portal authenticates the user, evaluates HIP, then issues a signed config and the allowed-Gateway list . The agent runs latency probes against that list and connects to the lowest-RTT Gateway with spare capacity — that's why a closer region without bandwidth or out of scope can be skipped. ## ZTNA on Prisma Access — App Gateway + Clientless Browser Access The same Prisma Access service can publish private apps in two flavours: full-tunnel (Mobile User connects, Security policy decides what private subnets they can reach) and ZTNA App Gateway (per-app reverse-proxy publishing, no tunnel needed). The second is the closer match to a Zscaler ZPA / Cloudflare Access experience. With App Gateway, you register an internal app (e.g. jira.internal ), point Prisma at the on-prem reverse-proxy reachable through a Service Connection, and Prisma publishes a public URL like jira.access.example.com . Users authenticate to that URL via SAML, Prisma runs Security policy (App-ID, URL, Threat Prevention) on the reverse-proxied connection, and the user never sees the internal hostname or IP. Clientless Browser Access is the same App Gateway with no agent on the endpoint — useful for contractors or unmanaged devices. Just a browser, SAML SSO, and the per-app reverse proxy. Mode Agent needed Best for Catch Full tunnel (Mobile User) GlobalProtect Managed corporate fleet Tunnel = full network reach unless tightly policied ZTNA App Gateway (agent) GlobalProtect Per-app access on managed devices Per-app policy needs careful per-FQDN config Clientless Browser Access None Contractors, BYOD, vendor portals Limited to web apps; no thick clients ## ADEM — the day-2 observability you already paid for Autonomous Digital Experience Management ships with every Prisma Access tenant. It runs synthetic probes from the agent and from the Gateway to surface per-segment performance: Endpoint segment — CPU, memory, Wi-Fi RSSI, local DNS resolution time. - ISP / Wi-Fi → Prisma Gateway segment — RTT, jitter, packet loss to the tunnel endpoint. - Prisma Gateway → SaaS segment — TCP connect time, HTTPS first-byte, full-page load. - Application-level — synthetic transactions against M365, Salesforce, Workday, etc. The output is a per-user experience score on a 1–10 scale. When a user complains "Teams is bad", ADEM tells you within 30 seconds whether the bad segment is their Wi-Fi, the ISP, the Prisma path or the destination SaaS — eliminating the 45-minute triage you used to do over chat. ✓ Verify a Mobile User is fully onboarded end-to-end Mobile User verification # 1) On the endpoint gpcli --show-status # Connected, Gateway = pa-asia-south1, Internal = false # 2) In SCM # Manage → Insights → Mobile Users → Connected # Filter on the user: expect Username from IdP, HIP = Match, Gateway name, # Source IP = endpoint NAT IP, Internal IP = a /32 from the Mobile User subnet. # 3) Trigger a known-blocked test curl -v https://web.telegram.org/ # expect Prisma block page (TLS handshake to Prisma cert, then RST) # 4) Confirm the log # SCM → Activity → Log Viewer → Traffic # Filter: ( app eq telegram-base ) and ( action eq deny ) # The Source User column must show the IdP identity, Rule = your contractor block rule. # 5) ADEM sanity # SCM → Insights → ADEM → User score for this username. # Score should be 8+ on a normal home network; drill down on any failing segment. ## Logs & SIEM integration — where the data lives, how it gets out Every log Prisma Access generates lands first in the Strata Logging Service — Palo Alto's hosted log store. Retention defaults are typically 30 days; you can extend with additional licence. You access them three ways: - SCM Log Viewer — interactive filter, drill-down, save searches. - Log Forwarding to NSS / SIEM — for long-term retention and cross-correlation. NSS (Network Security System) is the forwarder; it streams logs in CEF, LEEF, or syslog to Splunk, QRadar, Sentinel, Elastic, Chronicle. - API access — XSOAR playbooks pull events for automated response. Sensible log categories to forward day-1: Traffic, Threat, URL, WildFire, Decryption, GlobalProtect events, System . Skip Auth-Success unless you have a specific use case — the volume is enormous and the value is low. ## A real-world day-2 scenario — branch tunnel flap It's 14:00 IST. The Mumbai branch reports "internet is slow, sometimes nothing loads". The branch has primary + secondary Remote Network tunnels to asia-south1 and asia-southeast1 respectively. The L3 triage flow: - SCM → Insights → Remote Networks → Mumbai-Branch. Tunnel 1 status flapping — Up / Down / Up — every ~3 minutes. Tunnel 2 stable. - BGP session table on the branch CPE: neighbour to Prisma on Tunnel 1 keeps re-establishing. Routes withdrawn during each flap → ECMP repaints to Tunnel 2 → users notice ~5 s of "frozen" connections per flap. - System log filter on the CPE: IKEv2 SA expires at minute marks matching tunnel-flap timing → DPD timeout. ISP path between branch and Prisma is dropping outer ESP under load. - Resolution. Lower DPD interval from 30 s to 10 s to make the failover faster. Open a ticket with the ISP for the underlying packet loss. Verify in ADEM that user score for that branch climbed from 6.2 back to 8.8. This is the muscle memory L3 SASE engineers build: Insights → BGP → System log → fix the root cause → verify with ADEM. Never close a ticket without the verification step. Reproduce the branch tunnel flap Walk the Mobile User onboarding flow ## Common Mistakes ! Mistake 1 — Forgetting to allocate bandwidth to the region you're onboarding Without allocation, the Phase 2 SA negotiates and traffic silently drops at the Gateway. The fix is one slider in SCM, but the symptom looks like a routing or policy bug for hours if you don't know to look. Allocate first, onboard second. ! Mistake 2 — Skipping HIP because "we have EDR" EDR detects compromise after the fact. HIP gates connection before the user reaches anything. They are complementary — turn HIP on with at least three checks (disk encryption, AV running, OS patch level) on day one. Friction is minimal and the security value is enormous. ! Mistake 3 — Pushing the SSL decryption CA to all users in one shot A bad CA push has every browser on every endpoint throwing cert errors on every site. Stage it: pilot ring → 10% → 50% → 100% with explicit rollback gates. Only after the CA is universally trusted should you flip the Decryption policy to "decrypt". ! Mistake 4 — Letting branches keep their old central-egress habit The whole point of Remote Networks is local breakout to internet at the closest Prisma compute location. If you steer all branch internet through a Service Connection back to HQ, you re-create the centralised-egress latency you were paying Prisma to eliminate. ! Mistake 5 — Trusting ADEM scores without baselining An "ADEM 6" is meaningless without context. Baseline normal score per region on a healthy day, then alert on a sustained drop, not on an absolute threshold. Otherwise SecOps will mute the alert by week two. ## Pro Tips 💡 Tip 1 — Use SAML group claims for policy Have your IdP send the group memberships in the SAML assertion (Entra: emit security groups; Okta: emit group attribute filtered to relevant groups). Then write Prisma Security rules in terms of those groups. Adding a new Finance user becomes "put them in the Finance AD group" — zero Prisma change required. 💡 Tip 2 — Always set Always-On + Pre-Logon on managed devices Always-On stops users from disabling the tunnel. Pre-Logon brings the tunnel up before the Windows login screen so domain auth, GPO, and Intune policy can reach corporate services from any network. Two settings, massive operational value. 💡 Tip 3 — Stream Decryption logs to your SIEM separately Decryption logs are the canary that tells you a pinned app, an OCSP failure, or a CRL outage broke a critical SaaS. They are noisy but cheap to keep — give them their own SIEM index so SOC can search them without drowning in Traffic logs. 💡 Tip 4 — Build a "Prisma down" runbook before you need one If a single compute location degrades, do you know which branches you have to manually pin to the secondary? Document the failover map: branch → primary region → secondary region → manual cutover steps. Pin the runbook to the same Confluence page as the design. 🔑 Lock in the key terms — tap to flip 🌐 Compute Location tap to flip The physical region where a Gateway runs (e.g. asia-south1 ). It's the unit you reserve bandwidth against — an unallocated region cannot accept traffic. One pool is shared by Mobile Users and Remote Networks. 🛡️ HIP tap to flip Host Information Profile — the device-posture gate that runs after auth but before Security policy. Checks disk encryption, AV freshness, OS patch, certs. A failed check can drop the tunnel or quarantine the user. 🔌 Service Connection tap to flip An IPSec tunnel into a compute location whose role is one-directional reach to private apps behind your estate. It is not a path for internet egress — never advertise a default route over it. 📊 ADEM tap to flip Autonomous Digital Experience Management — synthetic probes that score each segment (endpoint, ISP→Gateway, Gateway→SaaS, app). Your first stop for any "the app is slow" ticket: it localises the bad hop in seconds. ## Quick Reference ### The lesson on one screen - Three layers — Portal (global anycast, authN + HIP), Gateway (regional NGFW pipeline), Compute Location (the region + bandwidth pool). - Compute location selection — agent picks lowest RTT Gateway from the Portal-issued list; branches and Service Connections are operator-chosen. - Allocate regional bandwidth first. Unallocated region cannot accept traffic. - Mobile Users = CIE auth + HIP posture + split-tunnel design. Always-On + Pre-Logon on managed devices. - Remote Networks = IKEv2 + ESP + BGP + ECMP across two tunnels to two compute locations. - Service Connections = active-active from two DCs into two regions; advertise summaries; no default route. - ZTNA App Gateway publishes a private app behind a SAML-protected public URL. Clientless Browser Access for agentless users. - ADEM gives per-segment experience scores — your first stop for any "the app is slow" ticket. - Logs live in Strata Logging Service; forward Traffic, Threat, URL, WildFire, Decryption, GP events, System to SIEM via NSS. - Triage flow — Insights → BGP / system log → root cause → verify with ADEM. Never skip the verification step. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. The exact framing an interviewer wants to hear. What are the three layers of Prisma Access? How does Prisma pick a Gateway for a Mobile User? Why must I allocate bandwidth before onboarding? Remote Network vs Service Connection — what's the difference? What does HIP actually check, and when? How do I triage a "Teams is slow" ticket with ADEM? Pre-curated from this lesson's prose + Prisma Access interview Q&A. For a live tenant issue, bring your SCM Insights + ADEM output to chat.techclick.in. ### 🎯 Scenario Assessment — 10 Questions Hit 70% (7 of 10) to mark this lesson complete. Submit to see scoring and per-question reasoning. Q1 A new Mumbai branch IPSec tunnel negotiates Phase 1 and Phase 2 successfully, but no traffic flows from the branch to internet. What is the most likely Prisma-side cause? a) The IKEv2 proposal is wrong b) Bandwidth was never allocated to the asia-south1 compute location, so the Gateway accepts the SA but drops traffic c) The branch needs a public IP d) Prisma Access cannot reach Mumbai Answer: b. If the proposal was wrong (a), Phase 1 / Phase 2 would never complete. Prisma needs explicit regional bandwidth allocation before a Gateway will pass traffic — a Phase-2-up-but-no-data symptom in a freshly onboarded region is almost always this. (c) is wrong — NAT-T means a private IP is fine. (d) is wrong — asia-south1 covers Mumbai. Q2 A user complains that Microsoft Teams calls are choppy from home only. ADEM shows the endpoint segment red, ISP segment green, Prisma segment green, SaaS segment green. The most likely cause is: a) Prisma Threat Prevention is dropping RTP b) Their IdP session expired c) The user's home Wi-Fi or device CPU is the bottleneck — endpoint segment red points there d) Salesforce is down Answer: c. ADEM's whole purpose is to localise the bad segment. Endpoint red + every other segment green points squarely at Wi-Fi RSSI / device CPU / local DNS. Telling the user to test on Ethernet usually proves it in 60 seconds. (a) would manifest as Prisma segment red. (b) and (d) are unrelated to this signal pattern. Q3 You're publishing an internal Jira instance to contractors who use personal laptops. The cleanest pattern is: a) Install GlobalProtect on every contractor laptop and use Mobile User mode b) Open Jira to the internet behind an IP allowlist c) Publish Jira through a Prisma Access ZTNA App Gateway with Clientless Browser Access — no agent, SAML SSO, Security policy still applies d) Send them a VPN client over email Answer: c. Clientless Browser Access on the App Gateway is exactly this scenario — no agent on the BYOD laptop, SAML SSO via your IdP, Prisma still inspects and applies Security policy. (a) requires installing managed software on a personal device. (b) bypasses Prisma's inspection. (d) is the worst of all worlds for a contractor footprint. Q4 A Remote Network branch is on Tunnel 1 to asia-south1 and Tunnel 2 to asia-southeast1, both with BGP. The asia-south1 Gateway goes down for maintenance. What happens? a) Tunnel 1 BGP session drops, prefixes withdrawn, ECMP repaints to Tunnel 2 within seconds — users see a brief blip and continue b) The branch is offline until asia-south1 is restored c) The branch must manually fail over d) Internet stays up but private apps disappear Answer: a. This is exactly why you design primary + secondary with BGP. The withdrawn prefixes drive ECMP to drop Tunnel 1 from the path, and the secondary continues to carry traffic. (b) and (c) describe a single-tunnel design. (d) would only happen if Service Connections were affected, not the local Gateway path. Q5 A Service Connection from HQ to Prisma Access is advertising the default route (0.0.0.0/0) into Prisma. Symptom? a) Nothing — that's the recommended design b) Mobile Users lose access to internal apps c) Service Connections cannot carry a default route d) Every Mobile User's internet traffic is pulled through HQ before Prisma sends it out — defeating local breakout and creating a single point of failure Answer: d. Advertising 0/0 over the Service Connection tells Prisma "send all internet traffic to HQ". Every Mobile User and Remote Network then hairpins internet via HQ — exactly the design Prisma replaces. (a) is the opposite of best practice. (c) is technically false; the SC will accept the route, that's the trap. (b) doesn't follow from this misconfig. Q6 In Cloud Identity Engine, you've integrated Entra ID via SAML but your Security policy that uses "source-user any-in-group('Finance')" doesn't match. What's the most likely fix? a) Disable SAML and use Kerberos b) Configure Entra to emit security-group claims in the SAML assertion (or use SCIM provisioning) so CIE knows the user's group membership c) Disable User-ID d) Hardcode the user's UPN in the rule Answer: b. Without the group claim in the SAML assertion (or a SCIM feed), CIE has the username but not the groups, so any group-based match fails. Entra's enterprise application config has a checkbox to emit "security groups assigned to the user" in the token. (a) and (c) defeat the whole identity model. (d) works for one user but does not scale. Q7 Which combination is the correct order for ROLLING OUT SSL Decryption on Prisma Access without breaking users? a) Flip Decryption to "decrypt" in policy → push the Prisma CA to endpoints next sprint b) Disable HIP first c) Push the Prisma forward-proxy CA to all endpoints in stages (pilot → 10% → 50% → 100%), verify trust, THEN flip Decryption policy to "decrypt" d) Decryption requires no CA work on the endpoint Answer: c. Endpoints must trust the Prisma decryption CA before you start MITMing TLS sessions — otherwise every browser screams. Stage the CA push, verify with a ring, then flip the policy. (a) is the wrong order and produces a fleet-wide TLS error storm. (b) is irrelevant. (d) is flat wrong. Q8 You need long-term retention of Prisma Access Traffic and Threat logs for compliance (>1 year). Which mechanism do you use? a) Just keep them in Strata Logging Service indefinitely b) Email the logs to your CISO daily c) Disable logging to save space d) Configure Log Forwarding via NSS to your SIEM (Splunk, Sentinel, etc.) and rely on the SIEM's retention policy Answer: d. Strata Logging Service has a finite default retention. NSS streams logs in CEF / syslog to your SIEM, which then owns the long-term retention story. This also enables cross-correlation with non-Prisma sources. (a) requires expensive licence extensions and still has limits. (b) and (c) are non-answers. Q9 A WFH Mobile User is in Mumbai but the GP agent is connecting to a London Gateway. What's the right diagnosis? a) The Mumbai Gateway is broken b) Check the Portal's allowed-Gateway list for the user (Mumbai may not be in scope), or the user's Gateway-selection latency probe results, or whether asia-south1 has bandwidth allocated c) GP always picks London first d) The user is on the wrong subscription Answer: b. Three things drive Gateway selection: the allowed list pushed by the Portal, the latency probes from the agent, and whether the closer region has capacity. Check all three. (a) is the lazy first guess and usually wrong. (c) is false — GP picks lowest RTT from the allowed list. (d) is unrelated. Q10 You're designing HIP for a Windows-laptop fleet. Which set of checks gives the best signal-to-friction ratio on day one? a) Disk encryption ON + Endpoint AV running with signatures ≤7 days + OS patched within 30 days — three checks, near-zero friction, huge security uplift b) Just check OS version c) 30+ checks including registry inspection d) Skip HIP entirely Answer: a. The three checks in (a) catch the overwhelming majority of "compromised endpoint" scenarios while being almost invisible to compliant users. (b) is too thin. (c) creates a friction wall that the help-desk will demand you weaken in week two. (d) wastes the most valuable native control Prisma ships with. Submit answers Try again Lesson complete — saved to your profile. Almost! Review the sections above and try again — you need 70% (7 of 10) to mark this lesson complete. ### What's next? Next up in the Palo Alto track: Prisma Cloud Defender deployment on EKS and AKS, IaC scanning in CI/CD with Bridgecrew/Prisma Code Security, Prisma SD-WAN ION devices and CloudBlade integration, and a complete day-2 runbook for the L3 SASE on-call. Practice the Mobile User and branch flows on the simulators, then take the cert-style scenario set on exam.techclick.in. All lessons → Practice on exam.techclick.in 📩 Quiz me on this in 7 days. Opt in and we'll email you 3 micro-questions from this lesson at Day 1, Day 7 and Day 30 — spaced repetition is how it sticks. Un-tick any time. --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt