# Palo Alto Prisma SASE Deep-Dive: Prisma Access + Prisma Cloud Source: https://ai.techclick.in/blog_paloalto_prisma_sase_deep_dive Markdown: https://ai.techclick.in/blog_paloalto_prisma_sase_deep_dive.md Publisher: Techclick Infosec Pvt Ltd A practical, hands-on deep dive into Palo Alto's full SASE stack — Prisma Access (Mobile Users, Remote Networks, Service Connections), Prisma Cloud (CSPM + CWPP + IaC) and Prisma SD-WAN — with architecture diagrams, configuration walkthroughs, production gotchas and a 10-question scenario assessment. Palo Alto Prisma SASE Deep-Dive: Prisma Access + Prisma Cloud student learning map A visual study map for Palo Alto Prisma SASE Deep-Dive: Prisma Access + Prisma Cloud showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Palo Alto Prisma SASE Deep-Dive: Prisma Access +... Palo Alto · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start Pick where you want to start 2. Understand Why Prisma exists — the on-prem... 3. Prove The Prisma portfolio at a glance 4. Practice Prisma Access — the three... 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 Palo Alto Prisma SASE Deep-Dive: Prisma Access + Prisma... Learn Pick where you want to start Map Why Prisma exists — the on-prem... Operate The Prisma portfolio at a glance Verify Prisma Access — the three... 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 ### Why Prisma exists SaaS, WFH and IaaS broke the on-prem NGFW — meet Access, Cloud, SD-WAN. 2 ### Three onboarding modes Mobile Users, Remote Networks, Service Connections — which goes where. 3 ### The request path One HTTPS connection, eight hops, from agent to SaaS egress. 4 ### Prisma Cloud (CNAPP) CSPM, CWPP, CIEM, IaC — protecting the apps users reach. ## Why Prisma exists — the on-prem firewall ran out of road Palo Alto built its reputation on the PA-Series — single-pass parallel processing, App-ID, User-ID, Threat Prevention. For a decade that NGFW was the company's centre of gravity. Then three things broke the model at the same time: SaaS made the office stop being where work happens, WFH made the office stop being where users sit, and IaaS made the data centre stop being where applications live. You cannot inspect traffic that never crosses your perimeter. Backhauling every roaming user over a VPN to a corporate firewall added 80–200 ms of latency, blew up MPLS spend and still missed every direct-to-SaaS path. The cloud-delivered model — the same App-ID and Threat Prevention pipeline, but run as a global service close to the user — is what Palo Alto calls Prisma . Prisma is not one product, it is three: - Prisma Access — the SSE / SASE service. Cloud-delivered NGFW for Mobile Users, branches, and hybrid HQ traffic. Often described as "your PA-Series, but running in 100+ Google + AWS regions and reachable from anywhere". - Prisma Cloud — the CNAPP. Cloud Security Posture Management, Cloud Workload Protection, Cloud Infrastructure Entitlement Management, IaC scanning, and Web/API security across AWS, Azure, GCP, OCI and Kubernetes. - Prisma SD-WAN — the CloudGenix-derived application-defined SD-WAN. Branch ION devices, SLA-based path steering, CloudBlade integration that hands traffic straight into Prisma Access. Together they cover the full SASE definition Gartner originally drew — network as a service plus security as a service, both consumed from the same cloud edge. ## The Prisma portfolio at a glance Before any configuration screen, fix the picture of what fits where. The three Prisma products sit at three different layers and protect three different things. Legend the Prisma cloud edge — Strata Cloud Manager / compute locations a Prisma product / pipeline stage security-policy pipeline (App-ID · User-ID · Threat Prevention) legacy / hybrid PA-Series NGFW broken / misconfigured step Figure 1 — Prisma portfolio (hub-and-spoke) A hub-and-spoke diagram. At the centre is Strata Cloud Manager / Panorama. Four spokes branch out to Prisma Access (Mobile Users, Remote Networks, Service Connections), Prisma Cloud (CSPM, CWPP, CIEM, IaC), Prisma SD-WAN (ION branch devices, path steering), and on-prem PA-Series NGFW. - Strata Cloud Manager — single pane for the whole Prisma + NGFW estate Strata Cloud Manager (or Panorama) policy · logs · health · AIOps Prisma Access Mobile Users Remote Networks (branches) Service Connections (HQ/DC) Prisma Cloud (CNAPP) CSPM · CIEM · compliance CWPP · container runtime IaC scan · WAAS Prisma SD-WAN ION branch devices App-defined path steering CloudBlade → Prisma Access PA-Series (legacy / hybrid) Physical / VM NGFW Same App-ID engine Same policy syntax One control plane, four enforcement surfaces. Engineers writing Security policy in SCM target Prisma Access, Prisma SD-WAN policy, and on-prem NGFWs from the same workflow — Prisma Cloud is a separate console today (Palo Alto is consolidating, but treat it as its own tenant for design purposes). ## Prisma Access — the three onboarding modes This is the part candidates fumble in L2 interviews. Prisma Access has exactly three ways traffic enters the service. Memorise these three or you cannot reason about a single design. ### 1. Mobile Users — the laptop in a coffee shop The GlobalProtect agent on the endpoint connects to the closest Prisma Access compute location and terminates an IPSec / SSL tunnel. From the agent's point of view it is still GlobalProtect; from the cloud's point of view this is a "Mobile User" connection that lands on the GlobalProtect Cloud Service portal and gateway hosted inside Prisma Access. Authentication runs against the Cloud Identity Engine (CIE) — SAML to your IdP (Entra ID, Okta, Ping), with HIP posture and optional MFA. Split-tunnel decisions are pushed from policy. Always-on, pre-logon and on-demand modes all work as on a physical GP gateway. ### 2. Remote Networks — the branch / small office An on-prem device — a PA-Series, a SD-WAN box, or any IKEv2-capable router — builds an IPSec tunnel up to a Prisma Access service connection point. The branch advertises its internal subnets, and Prisma Access can steer that traffic out to the internet, to SaaS, or across to an HQ via a Service Connection. Production designs always use primary + secondary tunnels with BGP, ECMP across the two, and a tested failover path. A single-tunnel branch is a 2 AM ticket waiting to happen. ### 3. Service Connections — the HQ / data centre / IaaS VPC Service Connections are what give Prisma Access reach back into your private estate. The Service Connection is itself an IPSec tunnel from your on-prem firewall or cloud transit gateway up to Prisma Access. Once it is up, Mobile Users and Remote Networks can reach private apps that sit behind it (an on-prem SAP, an AWS VPC, an Azure file share). Note the directionality — the Service Connection is not a destination for internet-bound traffic; it is the pipe into private. Best-practice designs run Service Connections active-active across two compute locations so the loss of one region does not strand your DC. 💡 Pro Tip If you forget which is which: Mobile Users come in . Remote Networks come in . Service Connections reach out to private. Internet egress always happens at the closest Prisma Access compute location for the user — you never bridge through a Service Connection just to reach Google. Quick check · Onboarding modes A branch needs its users to reach an on-prem SAP app that lives in your HQ data centre. Which Prisma Access construct gives Prisma reach into that private estate? a) A Remote Network tunnel from the branch — that automatically exposes HQ apps. b) A Service Connection — the IPSec pipe from your DC/transit gateway up to Prisma that lets Mobile Users and Remote Networks reach private apps. c) Mobile Users — install GlobalProtect on the SAP server. d) Internet egress at the nearest compute location. Correct: b. Service Connections are what give Prisma Access reach back into your private estate (on-prem SAP, AWS VPC, Azure file share). Mobile Users and Remote Networks come in ; the Service Connection reaches out to private — and it is not a path for internet-bound traffic. ## The request path — what actually happens to one HTTPS connection Every L3 interviewer asks this. "A mobile user opens https://salesforce.com — walk me through every hop." Here is the right answer in eight steps, the same one Palo Alto draws in the SCM documentation. Figure 2 — Mobile User → SaaS through Prisma Access A linear flow diagram showing eight hops: endpoint, GlobalProtect agent tunnel, Prisma Access compute location, Cloud Identity Engine, security policy pipeline, SSL decryption, App-ID / Threat Prevention, internet egress to SaaS. A single HTTPS request — Mobile User to SaaS 1. Endpoint GP agent up 2. IPSec / SSL tunnel to nearest PoP 3. Prisma Access Compute Location 4. Cloud Identity SAML/IdP + HIP 5. Security policy lookup — App-ID, User-ID, URL category, schedule, source/dest first-match-wins, evaluated against the rulebase pushed from SCM or Panorama 6. SSL Decryption forward-proxy MITM 7. App-ID + Threat Prevention AV, IPS, WildFire, DLP, URL 8. Egress to SaaS via Prisma egress IP Logs → Strata Logging Service + ADEM The endpoint never has a session with Salesforce directly — Prisma Access terminates the TLS, runs the full NGFW pipeline, and rebuilds a new TLS session to the destination. Two TLS legs, one user experience. Every step is logged to the Strata Logging Service and surfaced in ADEM. Palo Alto IPSec Simulator Prisma Access Simulator ### ▶ Watch one request travel through Prisma Access A Mobile User opens https://salesforce.com . Press Play for the healthy path, then Break it to see the classic SSL-decryption-CA mistake — and the fix. ① Endpoint The GlobalProtect agent is up. The browser opens salesforce.com ; the agent steers the connection into its tunnel. ▼ ② Tunnel An IPSec / SSL tunnel carries the traffic to the nearest Prisma Access compute location — no backhaul to a corporate firewall. ▼ ③ Identify + policy The Cloud Identity Engine resolves the user/group from the SAML assertion (plus HIP posture); the rulebase is evaluated first-match-wins (App-ID, User-ID, URL category). ▼ ④ Decrypt + inspect Forward-proxy SSL Decryption terminates the TLS so App-ID and Threat Prevention (AV, IPS, WildFire, DLP, URL) can run on the cleartext. ▼ ⑤ Egress + log Prisma rebuilds a fresh TLS session out to Salesforce via its egress IP; every step is logged to the Strata Logging Service and surfaced in ADEM. 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, does the endpoint ever hold a TLS session directly with Salesforce? a) Yes — Prisma just watches the existing session pass through. b) No — Prisma Access terminates the TLS, runs the NGFW pipeline, then rebuilds a new TLS session to the destination. Two TLS legs, one user experience. c) Only when SSL Decryption is turned off. d) Yes — the Cloud Identity Engine proxies the session. Correct: b. With forward-proxy decryption the compute location is a man-in-the-middle: it terminates the user's TLS, inspects the cleartext (App-ID + Threat Prevention), then opens its own TLS leg to Salesforce. That is exactly why the endpoint must trust the Prisma decryption CA — otherwise every site throws a certificate error. ## Panorama-managed vs Strata Cloud Manager — pick the right control plane Until 2023 the only way to drive Prisma Access was Panorama, the same template/device-group beast Palo Alto admins had used for years. Strata Cloud Manager (SCM) is the newer cloud-native console — and as of 2025 it is the default for new tenants and the recommended path Palo Alto wants every customer on. The two are not interchangeable, and migration is one-way. Dimension Panorama-managed SCM-managed (Strata Cloud Manager) Control plane Panorama VM you run (or Palo Alto-hosted Panorama) Palo Alto-hosted SaaS console Policy model Templates + Device Groups + pre/post rules Folder-based config + snippets + variables NGFW management Yes — physical and VM-Series Yes — PAN-OS 11.x and later Best for Existing Panorama estates, complex inherited config Greenfield Prisma deployments, AIOps-driven ops AIOps + ADEM Integrated but separate UX Native, single pane Migration → SCM via "Onboard to SCM" tool (one-way) Cannot move back to Panorama Rule of thumb: if you already have a Panorama estate with hundreds of templates and device groups, stay on Panorama until you have the budget for a clean migration window. If you are spinning up Prisma Access for the first time on a fresh tenant, start on SCM — Palo Alto's product investment is going there, AIOps and ADEM feel native, and folders are far less painful than template stacks. ## Security policy in Prisma Access — what changes, what stays the same The good news for Palo Alto admins: the policy syntax does not change. App-ID, User-ID, URL Filtering categories, Threat Prevention profiles, SSL Decryption profiles — all identical to the on-prem PA-Series. What changes is the surface those rules apply to. ### Policy ordering — pre, local, post Whether you drive Prisma Access from Panorama or SCM, rules are evaluated in three tiers: Pre-rules — global guardrails the central team writes (e.g. "block known-bad URL categories everywhere, no exceptions"). - Local rules — the bulk of your day-to-day policy, scoped to mobile users, remote networks, or specific service connections. - Post-rules — catch-alls (default-deny logging rules, broad observability rules). The same first-match-wins rule applies inside each tier. The PAN-OS engine still does the work — Prisma Access just runs that engine at the cloud edge. ### SSL Decryption — at scale this is non-negotiable Without forward-proxy SSL decryption, App-ID degrades to "ssl" or "web-browsing" and Threat Prevention has nothing to look at. In Prisma Access the deployment difference is that the decryption certificate is hosted in the cloud — you upload your enterprise CA (or let Prisma generate one) and push it to every endpoint via Intune / Jamf / GPO so the browser trusts the Prisma-signed certificate that fronts every external site. Without that trust step, every TLS connection breaks with a cert warning. ### App-ID and User-ID at cloud scale User-ID populates from the SAML assertion the Cloud Identity Engine receives during Mobile User authentication. That means every flow already carries the username and group context — you write policy like source-user any-in-group("VPN-Power-Users") instead of "subnet x.x.x.x". App-ID profiles still ride on the same threat content updates the on-prem firewalls receive; the difference is that the content gets pushed straight from Palo Alto's cloud to the Prisma compute locations on their own cadence. Security rule example — block Telegram for the contractor group Name : Block-Telegram-Contractors Source : Mobile User Internal Gateway Source User : any-in-group("contractors") Destination : Internet Application : telegram, telegram-base Service : application-default URL Category : Any Action : deny Log Setting : Default Profile Setting : Group → "outbound-strict" (AV, A-spyware, Vulnerability, URL, File, WildFire, DLP) Description : Sanctioned chat = Teams. Telegram blocked for contractors per ISMS-2026. ✓ Verify it worked Three deterministic checks every Prisma admin should run after a rule change: Prisma Access verification — admin + endpoint side # 1) Confirm the rule is pushed and counted # SCM → Manage → Configuration → Security → Security Services → Security Policies # Click your rule → "Rule Usage" → "Hit Count" should be > 0 within 5 minutes # Panorama equivalent: Commit log → Push to Prisma Access → all device groups: success # 2) Trigger the rule from a Mobile User endpoint curl -v https://web.telegram.org/ # Expected: TLS handshake completes to a Prisma-signed cert, # then the connection is reset / a block page is returned by Prisma Access. # 3) Confirm the log # SCM → Activity → Log Viewer → Traffic # Filter: ( app eq telegram-base ) and ( action eq deny ) # The Source User column must show the contractor identity from the IdP. # The Rule column must show "Block-Telegram-Contractors". ## Prisma Cloud — the CNAPP layer Prisma Access keeps the user safe on the way to the application. Prisma Cloud keeps the application itself safe. Together they cover the two halves of any modern security programme. CNAPP — Cloud Native Application Protection Platform — is the umbrella label, and Prisma Cloud delivers four pillars under it: - CSPM — Cloud Security Posture Management. Continuous scan of AWS / Azure / GCP / OCI for misconfigurations: public S3 buckets, security groups with 0.0.0.0/0, IAM policies with *:* , missing encryption-at-rest. Mapped against CIS, NIST, PCI, HIPAA, ISO benchmarks out of the box. - CWPP — Cloud Workload Protection. Defenders deployed on hosts, containers and serverless. Image scanning in CI/CD, vulnerability detection, runtime defence, Kubernetes admission control, file-integrity monitoring. - CIEM — Cloud Infrastructure Entitlement Management. Surfaces over-permissioned IAM roles, dormant access keys, identity blast radius. "Who can do what" with severity scoring. - IaC + WAAS. Scans Terraform, CloudFormation, Helm and Kubernetes manifests for misconfig before the deploy lands. WAAS gives you a web-application + API firewall on top of any workload Defender protects. The onboarding pattern for an AWS account is dead simple: in the Prisma Cloud console, add the account, run the supplied CloudFormation template (creates a cross-account IAM role with read-only permissions), and within 30 minutes the asset inventory and posture findings appear. CWPP comes later — you install Defenders as a DaemonSet on each EKS cluster, or as a host agent on each EC2. Quick check · Prisma Cloud pillars An alert flags an EC2 with a public IP, an SSH security group open to 0.0.0.0/0 , and an IAM role that can assume any other role. Which two Prisma Cloud pillars produced this together? a) CWPP (runtime) + WAAS (web/API firewall). b) CSPM (open security group + public IP) + CIEM (over-permissioned IAM role). c) IaC scanning only — it catches everything before deploy. d) Prisma Access — it inspects the EC2's traffic. Correct: b. Network and configuration misconfigs (open security group, public IP) are CSPM territory; the over-permissioned IAM role is CIEM. CWPP would matter if the finding were about the workload runtime/vulns, and WAAS is the web-app/API firewall — neither is the source here. The blast-radius story shows when CSPM and CIEM correlate. ## A real-world scenario — a 60-branch retailer goes SASE A 60-branch retail chain, ~12,000 employees, runs MPLS to every store and backhauls all internet through two HQ NGFWs. Latency is fine for in-office staff and awful for the 4,000 WFH employees who VPN home. SaaS bills (Microsoft 365, Workday, Salesforce) keep climbing and bandwidth at the HQ break-out is saturated by mid-afternoon. The customer wants three things: kill the WFH VPN concentrator, give branches a direct-to-cloud path, and not lose a single Threat Prevention feature. The Prisma design that ships: - Mobile Users + Prisma Access for the 4,000 WFH users. Cloud Identity Engine fronts Okta. Always-on GP agent, split-tunnel excludes Microsoft Teams media so voice goes direct. The VPN concentrator at HQ is decommissioned in week 8. - Remote Networks from every branch via IKEv2. Each branch builds two tunnels to two Prisma compute locations, BGP-advertises its internal subnets, ECMP across both. Local breakout for SaaS, central security policy for everything else. - Two Service Connections — one from each HQ data centre — into Prisma Access. Active-active. Any user or branch that needs an on-prem SAP/HR app reaches it through the Service Connection, never via the MPLS. - Prisma Cloud onboarded to the two AWS prod accounts. CSPM caught 47 public S3 buckets in week 1, CWPP rolled to the EKS clusters in week 4, IaC scanning wired into the GitHub Actions pipeline in week 6. The metric that gets the CIO on board: average WFH SaaS latency drops from 240 ms to 38 ms because users now hit a Prisma PoP 30 km away instead of bouncing through the corporate VPN. MPLS spend halves in the next renewal cycle. Threat Prevention coverage actually improves because every user — branch or WFH — now sees the same NGFW pipeline. Try the branch IPSec setup Walk the Mobile User onboarding flow ## Common Mistakes ! Mistake 1 — Forgetting that Service Connection is not for internet egress Engineers new to Prisma will often steer a Remote Network's internet-bound traffic through a Service Connection back to an HQ NGFW "just to keep the egress path the same". That defeats the entire point of Prisma. Internet egress should happen at the Prisma compute location closest to the branch. Service Connections exist for private-app reach only. ! Mistake 2 — Single Remote Network tunnel per branch If you onboard a branch with one IPSec tunnel to one compute location, the day Palo Alto does scheduled maintenance on that region you are off the air. Always primary + secondary, BGP, ECMP. The licence already covers it — there is no reason not to. ! Mistake 3 — Pushing the Prisma decryption CA to "all users next week" SSL decryption only works if the endpoint trusts the Prisma forward-proxy CA. Treat the CA push as its own change with a phased rollout (pilot → 10% → 50% → 100%) and explicit rollback. A bad push has every browser screaming TLS errors on every site for 12,000 employees. Sequence the CA push before you flip Decryption to "decrypt" in policy. ! Mistake 4 — Treating Prisma Cloud as "SCM with another tab" Prisma Cloud is a separate console, a separate licence, separate IAM, and a separate cost line. Provision it with its own admins, its own change process, and its own alert pipeline. CSPM findings are usually the loudest output of week one — tune them or you will train SecOps to ignore the inbox. ## Pro Tips 💡 Tip 1 — ADEM is the diagnostic console you didn't know you bought Autonomous Digital Experience Management ships with Prisma Access. It surfaces per-user latency, packet loss and application response time as a synthetic score. When a single user complains "Teams is bad", ADEM tells you in 30 seconds whether the bad hop is Wi-Fi, ISP, the Prisma tunnel or the destination SaaS — saving you 45 minutes of triage on every ticket. 💡 Tip 2 — Use HIP profiles to filter who even gets a tunnel HIP (Host Information Profile) lets you require disk encryption, AV running, OS-patched, certificate-present, before the GP agent is allowed to bring the tunnel up. This is the cheapest device-posture gate in the industry — it ships with Prisma Access at no extra licence cost. 💡 Tip 3 — In SCM, use Folders the way Panorama users used Device Groups A folder-per-business-unit + variables for per-region values gives you the same scope-and-inherit power as templates / device groups, with a fraction of the operational pain. Once you have your folder taxonomy right, day-2 changes drop from "edit five templates and pray" to "drop the rule in the right folder". ## Quick Reference ### The lesson on one screen - Prisma = Access (SASE) + Cloud (CNAPP) + SD-WAN. All three sit under Strata Cloud Manager. Prisma Cloud is its own console for now. - Three onboarding modes in Prisma Access — Mobile Users (laptops), Remote Networks (branches), Service Connections (HQ/IaaS). - Mobile Users + Remote Networks come in . Service Connections reach out to private. - Internet egress always happens at the closest Prisma compute location. Don't backhaul via Service Connection. - SSL Decryption needs the Prisma CA pushed to every endpoint — sequence the CA push before flipping decrypt-on. - Cloud Identity Engine handles SAML auth + group lookup + HIP posture. - Policy tiers — pre-rules → local rules → post-rules. First-match-wins inside each tier. - SCM vs Panorama — greenfield → SCM, legacy estate → stay on Panorama until you can plan the one-way migration. - Prisma Cloud CNAPP = CSPM + CWPP + CIEM + IaC + WAAS. CSPM lights up the loudest in week one. - ADEM is the per-user experience score — your first stop for any "the app is slow" ticket. 🔑 Lock in the key terms — tap to flip 🌐 Prisma Access tap to flip The cloud-delivered SSE / SASE service — your PA-Series NGFW pipeline run in 100+ regions for Mobile Users , Remote Networks and Service Connections . ☁️ Prisma Cloud (CNAPP) tap to flip The Cloud Native Application Protection Platform: CSPM + CWPP + CIEM + IaC + WAAS . It protects the apps and workloads users reach, not the path to them. 🔌 Service Connection tap to flip An IPSec tunnel from your DC / transit gateway up to Prisma that gives reach into your private estate. It is not a path for internet egress — that happens at the nearest compute location. 📊 ADEM tap to flip Autonomous Digital Experience Management — synthetic probes from the agent score per-hop latency (Wi-Fi → ISP → Prisma → SaaS), so "Teams is slow" gets an evidence-based answer in 30 seconds. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. The exact framing an L2/L3 interviewer wants to hear. What are the three Prisma products? Mobile Users vs Remote Networks vs Service Connections? Walk me through a Mobile User HTTPS request. Why does SSL Decryption break every site? SCM or Panorama — which control plane? What does Prisma Cloud cover that Prisma Access doesn't? Pre-curated from Palo Alto docs + interview Q&A, scoped to this lesson. For a live tenant issue, paste your SCM log filter into 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 small branch office with ~25 users needs to onboard to Prisma Access. The branch already has a SonicWall edge router that supports IKEv2. Which Prisma Access onboarding mode fits? a) Mobile Users — install GlobalProtect on every laptop b) Remote Networks — build a primary + secondary IKEv2 tunnel from the SonicWall up to two Prisma compute locations c) Service Connection — terminate an IPSec tunnel from the branch into Prisma so the branch can be reached by HQ d) None of the above — Prisma Access only supports Palo Alto devices on the branch side Answer: b. Branch onboarding through an IKEv2-capable edge device is exactly the Remote Networks pattern. Primary + secondary tunnels to two different compute locations is the production-grade design. (a) burns endpoint licences and skips the branch's local breakout. (c) inverts directionality — Service Connections are for private reach into your estate, not for branch internet egress. (d) is false — any IKEv2-capable router works. Q2 A Mobile User on a Mac complains every external HTTPS site is throwing a certificate error since you turned on SSL Decryption in Prisma Access. The Prisma policy is fine. What is the most likely root cause? a) Prisma Access decryption is broken — open a TAC case b) The Prisma forward-proxy CA certificate was never pushed to the Mac's keychain, so the OS rejects the Prisma-signed certificate c) The user's IdP session expired d) HIP profile failed — endpoint is non-compliant Answer: b. Forward-proxy decryption only works if the endpoint trusts the Prisma decryption CA. On macOS that means the CA must live in the System keychain (typically pushed via Jamf). Without it, every TLS handshake to a decrypted site fails with an untrusted-issuer warning. (a) is wrong — the policy turn-on works as designed; the missing step is endpoint trust. (c) breaks auth, not TLS validation. (d) blocks the tunnel coming up, not TLS errors mid-session. Q3 Your CISO asks "what does Prisma Cloud cover that Prisma Access doesn't?" The shortest correct answer is: a) Prisma Cloud is just Prisma Access with a different licence skin b) Prisma Cloud replaces all need for Prisma Access c) Prisma Cloud is the CNAPP — CSPM, CWPP, CIEM, IaC and WAAS — protecting the cloud apps and workloads themselves; Prisma Access protects the user on the way to the app d) Prisma Cloud only does compliance scanning Answer: c. Prisma Access secures the path the user takes to reach the app. Prisma Cloud secures the cloud account, the workload, the container, the IAM entitlements and the IaC. They are complementary halves of the SASE + CNAPP story. (a) and (b) are flat wrong. (d) is half-right — compliance/CSPM is one of four pillars; CWPP, CIEM and IaC are the others. Q4 An engineer designs a Prisma Access deployment where every Remote Network's internet-bound traffic is steered through a Service Connection back to the HQ NGFW "so logging stays consistent". What is the main problem? a) Nothing — that is the recommended pattern b) It works but doubles licence cost c) It hairpins internet traffic through the HQ, defeating the latency and cost benefits of SASE — and it makes the Service Connection a single point of failure for everyone's internet d) Service Connections cannot carry internet-bound traffic at all Answer: c. Internet egress from Prisma Access should happen at the compute location closest to the branch — that's the whole point of moving off centralised egress. Backhauling via Service Connection re-creates the latency and bandwidth problems SASE was meant to fix, and concentrates risk on one tunnel. (d) is technically wrong (it can be done) but operationally the design is bad. Q5 A greenfield customer is building a brand-new Prisma Access tenant with no legacy Panorama estate. Which control plane should you recommend? a) Strata Cloud Manager (SCM) — folder-based config, native AIOps, the path Palo Alto is investing in b) Panorama — because it has more knobs c) Either is fine, but pick Panorama for cloud-native deployments d) Both at once, in active-active Answer: a. Greenfield Prisma deployments belong on SCM. Folders + variables are easier to operate than Panorama's template stacks and device groups, AIOps and ADEM feel native, and product roadmap investment is going to SCM. Panorama remains valid for customers who already have a sprawling on-prem estate they don't want to re-platform. (d) is incorrect — a tenant has one control plane, not two. Q6 In Prisma Access, when an admin commits a security rule change, which sequence is correct? a) Local rules → pre-rules → post-rules, first-match-wins across the whole rulebase b) Pre-rules → local rules → post-rules, first-match-wins within each tier c) Rules are evaluated alphabetically by name d) Post-rules run first because they are catch-alls Answer: b. Pre-rules ship from the central team as global guardrails (top of the rulebase), local rules are the per-scope policy, post-rules are catch-alls. First-match-wins applies inside each tier. (a) inverts the order. (c) and (d) are nonsense distractors. Q7 A single Mobile User says "Teams audio is unusable from home". Three other users in the same household are fine. Which Prisma tool surfaces the per-user latency / loss / app-response evidence fastest? a) Threat Logs filtered by user b) ADEM — Autonomous Digital Experience Management — gives you per-hop latency and app-response score for that one user c) Prisma Cloud Asset Inventory d) Open the user's BIOS Answer: b. ADEM is purpose-built for exactly this — synthetic probes from the agent surface per-hop latency (Wi-Fi → ISP → Prisma → SaaS) and per-app response time. The score immediately points at the bad hop. (a) is the wrong console — Threat Logs cover security events, not performance. (c) is the wrong product entirely. (d) is a joke distractor — pick something that looks plausible but isn't a Prisma tool, like the Mobile User would say. Q8 In Prisma Cloud, the security team gets an alert that an EC2 instance has a public IP, an IAM role that lets it assume any other role in the account, and the SSH security group is open to 0.0.0.0/0. Which Prisma Cloud pillars together produced this finding? a) Only CSPM b) Only CWPP c) CSPM (security group, public IP) + CIEM (over-permissioned IAM role) d) WAAS only Answer: c. Network and configuration misconfigs (open security group, public IP) are CSPM territory. The over-permissioned IAM role belongs to CIEM. CWPP would come in if the alert was about the workload itself (runtime, vuln). WAAS is the web-app/API firewall — not relevant here. The full Prisma Cloud value shows when CSPM and CIEM correlate to highlight the blast-radius story together. Q9 A Prisma Access tenant has Mobile Users authenticated via SAML to Okta. Security policy needs to allow "the Finance department" to reach Bloomberg Terminal. The cleanest way to express this is: a) Hard-code the IP subnet of the Finance VLAN as the source — the simplest match b) Use source-user with the Okta group "Finance" (pushed via SAML / Cloud Identity Engine), so the rule follows the user regardless of network c) Disable User-ID — it slows policy lookup d) Match by Mobile User device serial number Answer: b. The whole point of Cloud Identity Engine is to make user/group context available to the policy engine. Writing the rule in terms of the IdP group means the policy follows the user across networks and survives a laptop refresh. (a) breaks the moment Finance moves subnet or works from home. (c) defeats the User-ID story Prisma Access is built around. (d) is operationally brittle. Q10 A Prisma Access design uses a single Service Connection from one HQ data centre. The Service Connection terminates on a single PA-Series at HQ. What is the most important resilience change to make before go-live? a) Nothing — Prisma Access has its own redundancy in the cloud b) Add a second Service Connection from the other HQ data centre to a different Prisma compute location, active-active, so any single tunnel or region outage doesn't strand private access c) Disable BGP across the tunnel and use static routes d) Move the Service Connection logic to a Remote Network Answer: b. A single Service Connection from one DC to one compute location is one failure away from cutting every Mobile User and Remote Network off your private apps. Active-active across two DCs and two compute locations is the right pattern. (a) ignores the on-prem and tunnel single points of failure. (c) reduces, not increases, resilience. (d) confuses two different onboarding modes — Remote Networks do not give Prisma reach into your private estate. 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: GlobalProtect on Prisma Access deep-dive, ZTNA + App Gateway for private-app publishing, Prisma SD-WAN ION devices, and Prisma Cloud Defender deployment on Kubernetes. Practice the Mobile User onboarding flow on the simulator, and try the cert-style scenario questions 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