# Zero Trust & Prisma Access Complete Guide

Source: https://ai.techclick.in/blog_zero_trust_prisma
Markdown: https://ai.techclick.in/blog_zero_trust_prisma.md
Publisher: Techclick Infosec Pvt Ltd

Complete Zero Trust & Prisma Access guide: 6 pillars of Zero Trust, Palo Alto NGFW policy logic, Prisma Access SASE, SCM setup, HQ firewall config and

Zero Trust &amp;amp; Prisma Access Complete Guide student learning map
                     A visual study map for Zero Trust &amp;amp; Prisma Access Complete Guide showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Zero Trust &amp;amp; Prisma Access Complete Guide
                     Palo Alto · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   Pick where you want to start

   2. Understand
   1. Introduction

   3. Prove
   2. Zero Trust Concept — Old Model...

   4. Practice
   3. 6 Pillars of Zero Trust in Palo...

                     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

                 Zero Trust &amp;amp; Prisma Access Complete Guide

   Learn
   Pick where you want to start

   Map
   1. Introduction

   Operate
   2. Zero Trust Concept — Old Model...

   Verify
   3. 6 Pillars of Zero Trust in Palo...   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

### Zero Trust concept

 Old "trust but verify" model vs never trust, always verify.

                  2

### The 6 pillars

 User-ID, HIP, App-ID, zones, DLP, threat prevention.

                  3

### Policy decision logic

 The 6 checks every session must pass — in order.

                  4

### Mobile user flow

 Remote laptop → Mumbai PoP → HQ private app, no VPN.

## 1. Introduction

         This document covers how Palo Alto Networks implements Zero Trust — both on physical NGFW and via Prisma Access (cloud-delivered SASE). It explains the architecture, configuration, and policy logic for a company with HQ, branch offices, and remote users.

              💡 Key Principle

             Zero Trust is not a product — it is a security framework. Palo Alto implements it through a combination of features: User-ID, App-ID, HIP, SSL Decryption, DLP, WildFire, and Prisma Access working together.

## 2. Zero Trust Concept — Old Model vs Zero Trust

                 ✗ Old Model — Trust But Verify

                     Inside network = trusted automatically

                     Perimeter firewall is the only control

                     Once inside LAN, move anywhere freely

                     VPN gives full network access

                     No device posture check

                     IP-based rules only — no user context

                 ✓ Zero Trust — Never Trust, Always Verify

                     Every access request verified regardless of location

                     Microsegmentation — no lateral movement

                     Identity-aware policies (user + group)

                     Device posture checked before access

                     Least privilege — only what you need

                     Continuous re-verification — not one-time

             Legend
               user / endpoint side (royal)
               Prisma Access / NGFW enforcement (cyan)
               destination — internet / private app (magenta)
               verified / allowed
               failed / denied

             Old perimeter model vs Zero Trust — the same access request

                     Old perimeter model versus Zero Trust
                     Two side-by-side flows. Left: old model — a user crosses one perimeter firewall and is then trusted to move freely across the flat LAN. Right: Zero Trust — every request is verified on identity, device posture and per-app policy before reaching only the one app it is allowed to use.

- OLD MODEL — trust but verify ZERO TRUST — never trust, always verify User VPN / on LAN Perimeter firewall Flat LAN — trusted, no inspection inside Finance HR ERP lateral movement — free User + device anywhere VERIFY EVERY REQUEST User-ID · HIP posture · App-ID · least-privilege policy SSL decrypt · DLP · threat prevention ERP — allowed this one app only HR — denied no lateral move every zone crossing inspected In the old model a user who clears one perimeter firewall is trusted to move freely across a flat LAN. Under Zero Trust there is no trusted inside — every request re-proves identity, device posture (HIP) and per-app policy, so a compromised session reaches only the one app it is explicitly allowed and can't pivot to HR or Finance. Quick check · Zero Trust concept A laptop is already plugged into the corporate LAN at HQ. Under Zero Trust, what happens when it requests the ERP app? a) It's trusted automatically — it's inside the network. b) Identity, device posture (HIP) and per-app policy are still verified — being "inside" earns no trust, and it reaches only the apps policy allows. c) Only its source IP is checked against an allow-list. d) The perimeter firewall opens the whole subnet to the ERP zone. Correct: b. Zero Trust assumes there is no trusted "inside". Every access request is verified on user, device posture and per-app policy and only ever reaches the specific app it's allowed — there's no flat LAN to roam, so lateral movement is gone. 🔑 Lock in the key terms — tap to flip 🛡️ Zero Trust tap to flip A security framework , not a product: "never trust, always verify". Every access request is authenticated, authorised and inspected regardless of location. 🌐 Prisma Access tap to flip Palo Alto's cloud-delivered SASE — the NGFW stack as a service. Remote users and branches connect to the nearest PoP; the same inspection runs there, no box per site. 💻 HIP tap to flip Host Information Profile. The GlobalProtect agent reports device posture (disk encryption, AV, patch level); policy only allows access when the device is compliant. ⚙️ SCM tap to flip Strata Cloud Manager — Palo Alto's cloud-native, single-pane manager for Prisma Access (Service Connections, Mobile Users, policy, commit & push). ## 3. 6 Pillars of Zero Trust in Palo Alto i Heads-up This is Techclick's 6-pillar framing. Palo Alto's official Zero Trust Enterprise whitepaper uses 5 pillars : User, Device, Application, Infrastructure, Data. We split 'Threat' out as a 6th for teaching clarity — when interviewing at Palo Alto, default to their 5. All 6 pillars must pass for a session to be allowed. Failure in any single pillar results in deny or quarantine. Pillar 01 User Identity User-ID + SAML + MFA Maps every IP to a real username via AD Security Event logs. Policies reference usernames/groups, not IP addresses. Step-up MFA enforced for sensitive resources. Pillar 02 Device Trust HIP Check via GlobalProtect GlobalProtect agent reports device posture — AV installed, disk encrypted, OS patched, domain joined. Valid credentials alone are not enough — device must also pass HIP. Pillar 03 Application Control App-ID — Layer 7 inspection Identifies actual application inside traffic regardless of port. Port 443 could be Office365, Dropbox, TeamViewer, or malware. Allow named apps only — deny everything else. Pillar 04 Network Segmentation Zones + Microsegmentation Every zone crossing is inspected. Finance servers cannot reach HR servers without explicit allow rules. Attacker who compromises one host cannot move laterally. Pillar 05 Data Security SSL Decrypt + DLP 90% of traffic is encrypted — without SSL decryption you are blind. Decrypts, inspects for sensitive data (PII, credit cards, IP), re-encrypts. Blocks exfiltration even by trusted users. Pillar 06 Threat Prevention IPS + WildFire + DNS Security Even authenticated, compliant users on allowed apps — traffic itself is scanned. WildFire sandboxes unknown files. DNS Security blocks C2 domains. IPS catches exploit patterns. Quick check · The 6 pillars A user has valid AD credentials and is in the allowed group, but their laptop's disk encryption is turned off. What happens? a) Access is granted — valid credentials are enough. b) The Device Trust pillar (HIP via GlobalProtect) fails, so the session is denied or quarantined — any single pillar failing blocks access. c) Only App-ID is checked; HIP is optional. d) The user is allowed but logged for review later. Correct: b. All 6 pillars must pass for a session to be allowed. Device Trust (HIP) checks posture like disk encryption, AV and OS patch level — valid credentials alone are not enough, so a non-compliant device is denied or quarantined. ## 4. Zero Trust Policy Decision Logic This is what Prisma Access evaluates for every single session — in order. All checks must pass. 👤 Check 1 — User-ID Is "ram.dixit@corp.com" in allowed AD group? Pass ✓ 💻 Check 2 — HIP / Device Disk encrypted + AV running + OS patched? Pass ✓ 📱 Check 3 — App-ID Application = web-browsing to ERP? Not TeamViewer? Pass ✓ 🔒 Check 4 — Zone Policy Source=Prisma-Zone → Dest=ERP-Zone policy exists? Pass ✓ 📄 Check 5 — DLP Any sensitive data (PII, credit card) being sent out? Pass ✓ ⚡ Check 6 — Threat Any exploit signatures, malware, C2 callbacks? Pass ✓ ✓ Result All 6 checks passed → Session ALLOWED. If any single check fails → DENY or QUARANTINE. That is Zero Trust. ## 5. Why Prisma Access — Not Just Physical PA Physical PA firewall protects your building . Prisma Access protects your users and data — wherever they are . Scenario Physical PA Only Prisma Access (SASE) Branch protection Need PA box at every branch IPSec tunnel — no hardware needed Remote / WFH user VPN → backhauled to HQ GP → nearest PoP (Mumbai for India) SaaS inspection Traffic hairpins through HQ Inspected in cloud before reaching SaaS Policy management Per-device or Panorama Strata Cloud Manager — single pane Scaling Buy more hardware Elastic — auto-scales New branch setup Ship hardware, rack, configure Configure tunnel in SCM — done CapEx High — PA-3200/5200 series Zero — OpEx subscription Zero Trust coverage Where hardware exists Everywhere — all users, all locations ## 6. Mobile User → Private App Flow This is how a remote user in Pune accesses an internal ERP application at HQ Delhi — without a traditional VPN. STEP 01 User opens laptop GP auto-connects → STEP 02 SSL tunnel To Mumbai PoP → STEP 03 IdP Auth + HIP SAML + posture → STEP 04 Policy check SCM security rule → STEP 05 IPSec svc conn Prisma → HQ PA → STEP 06 Private app LAN delivery 💡 Pro Tip The Service Connection is the bridge. One IPSec tunnel at HQ serves all remote users globally. You don't need VPN concentrators or per-user firewall rules at HQ. Prisma handles all user sessions in the cloud. ### ▶ Watch a remote user reach the HQ ERP through Prisma Access A laptop in Pune opens the internal ERP at HQ Delhi. Press Play for the healthy path, then Break it to see the classic HIP / posture failure — and the fix. ① Connect The user opens the laptop. GlobalProtect auto-connects and builds an SSL tunnel to the nearest Prisma PoP (Mumbai for India). ▼ ② Auth + HIP The IdP (Azure AD / Okta) authenticates the user via SAML, and the GlobalProtect agent submits its HIP report — disk encryption, AV, OS patch level. ▼ ③ Policy The SCM security rule is evaluated: source = mobile-user zone + AD group, HIP = compliant-devices, App-ID matches — all 6 pillars must pass. ▼ ④ Service Connection Prisma forwards the session over the IPSec Service Connection to the HQ PA firewall — one tunnel serves every remote user globally. ▼ ⑤ Private app The HQ firewall delivers the session to the ERP on the LAN (10.10.0.0/16). The user reaches one app — no full network access, no VPN concentrator. Press Play to step through the healthy path, then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Mobile user flow In the flow above, what carries the remote user's session from the Prisma cloud into the HQ LAN to reach the private ERP? a) A per-user VPN tunnel to a concentrator at HQ. b) The user's laptop routes directly to the HQ public IP over the internet. c) The IPSec Service Connection — one tunnel from Prisma to the HQ firewall that serves all remote users globally. d) Direct Internet Access (DIA) straight out of the Prisma Service Edge. Correct: c. The Service Connection is the bridge for private-app access: one IPSec tunnel from Prisma to the HQ PA firewall serves every remote user, so you need no VPN concentrators or per-user rules at HQ. DIA is for internet/SaaS, not for reaching the HQ ERP. ### Mobile User Flow — Direct Internet Access (DIA) The most common Prisma Access traffic pattern: user → Prisma Service Edge → direct to SaaS / internet (DIA) , NOT backhauled through HQ. Security stack (App-ID, Threat Prevention, URL Filtering, WildFire, DNS Security) runs on the Service Edge in line. The HQ-backhaul flow (Service Connection → on-prem firewall) is for private app access only — Office365, Salesforce, web browsing all go DIA. ### Strata Cloud Manager (SCM) vs Panorama with Prisma Access plug-in Panorama with Prisma Access plug-in remains the dominant management surface for tenants migrating from on-prem PAN. SCM is Palo Alto's strategic direction (cloud-native, multi-product), but if you already operate Panorama at scale, the plug-in path is the lower-risk migration. ### Cortex Data Lake (CDL) — where the logs live Cortex Data Lake (CDL) is where all Prisma Access logs land. Sized in storage tier (1 TB, 10 TB, etc.) — separate license from Prisma Access. Every Prisma operator deals with CDL daily for log queries, AutoFocus integration, and Cortex XSOAR/XSIAM ingest. ### Licensing — sized in Gbps, not user count Prisma Access licensing model: sized in Gbps (peak bandwidth) , NOT user count. Sales conversations always start with 'how many Gbps?' — internalize this number for any Prisma role interview. ### HIP enforcement mechanism HIP enforcement: Z-App's HIP report is evaluated against HIP match objects, which can be referenced in security policy as a match condition. Posture violation → policy fires the configured action (block, isolate, restrict). HIP report distribution is per-session; mid-session HIP changes don't tear down existing sessions. ### Cert path for Prisma Access roles Cert path: PCNSE → PCCSE (Prisma Cloud) for cloud-native security roles; PCNSE → PCSAE (Prisma Access SASE Engineer) for SASE/Prisma Access roles. Pick PCSAE if your job is Prisma Access operations. ## 7. SCM Portal Setup — Step by Step 1 #### Service Connection — HQ IPSec Tunnel Define the IPSec tunnel from Prisma cloud to your HQ firewall. After saving, SCM gives you Prisma's public IP — copy it for HQ firewall config. Manage → Service Connections → Add

- 2 #### Mobile User Configuration Set the PoP region (India South — Mumbai), IP pool for GP users (100.64.0.0/10), internal DNS server, DNS suffix, and split-tunnel setting. Manage → Mobile Users → Add

- 3 #### IdP Integration (Azure AD / Okta) Upload SAML Federation Metadata XML from Azure AD. Map attributes: username → userprincipalname, groupname → groups. Copy ACS URL back to Azure. Identity Services → Identity Provider → Add

- 4 #### HIP Profile — Device Posture Define checks: AV running + definitions

                   Field  Service Connection Value

                      Name  HQ-Delhi-SC
                      Region  Asia Pacific — India South (Mumbai)
                      Subnets to advertise  10.10.0.0/16 (your HQ LAN)
                      IKE Version  IKEv2
                      Encryption  AES-256-GCM
                      DH Group  Group 20
                      Pre-Shared Key  Generate strong PSK — save for HQ firewall

## 8. HQ Firewall IPSec Config — Palo Alto

         After completing SCM setup, configure the IPSec peer on your HQ PA firewall.

              💡 Modern best practice

              Certificate-based authentication for Service Connections (PAN-OS 11+)  eliminates PSK rotation overhead. PKI: device cert issued by your internal CA, trusted on the Prisma Access side. PSK examples below are kept for legacy compatibility but new deployments should be cert-based.

             IKE Crypto Profile
              # Network → Network Profiles → IKE Crypto → Add
 Name          :  Prisma-IKE-Crypto
 DH Group      :   group20
 Authentication:   sha256
 Encryption    :   aes-256-gcm
 Key Lifetime  :  8 hours

             IPSec Crypto Profile
              # Network → Network Profiles → IPSec Crypto → Add
 Name          :  Prisma-IPSec-Crypto
 Protocol      :   ESP
 Encryption    :   aes-256-gcm
 Authentication:   none   (GCM is AEAD — auth is built-in)
 DH Group      :   group20
 Key Lifetime  :  1 hour

             IKE Gateway
              # Network → Network Profiles → IKE Gateways → Add
 Name              :  Prisma-SC-GW
 Version           :   IKEv2 only
 Interface         :  ethernet1/1  (WAN interface)
 Local IP          :  203.x.x.x  (HQ WAN IP)
 Peer IP           :   34.100.x.x   (Prisma SC IP from SCM)
 Authentication    :  Pre-Shared Key
 PSK               :   YourStrongPSKHere
 IKE Crypto Profile:  Prisma-IKE-Crypto

             IPSec Tunnel + Static Route
              # Network → IPSec Tunnels → Add
 Name              :  Prisma-SC-Tunnel
 Tunnel Interface  :  tunnel.10  (zone = Prisma-Zone)
 IKE Gateway       :  Prisma-SC-GW
 IPSec Crypto      :  Prisma-IPSec-Crypto

 # Static Route — return path for mobile users
 Destination       :   100.64.0.0/10   (GP IP pool)
 Next Hop          :  tunnel.10

## 9. Verification Commands

             Palo Alto CLI
              # IKE Phase 1 status
 show vpn ike-sa

 # IPSec Phase 2 status
 show vpn ipsec-sa

 # Traffic counter through tunnel
 show vpn flow tunnel-id &lt;id&gt;

 # User-ID mapping check
 show user ip-user-mapping all

 # HIP report for a specific IP
 show user hip-report ip &lt;ip&gt;

 # Active GlobalProtect sessions
 show global-protect-gateway current-user

                   Test  Expected Result

                      GP agent connects  Status = Connected, IP = 100.64.x.x assigned
                      ping 10.10.1.50 from laptop  Reply from HQ server
                      tracert 10.10.1.50  Hops: 100.64.x.x → Prisma PoP → HQ LAN
                      show vpn ike-sa  State = ESTABLISHED, Peer = 34.100.x.x
                      SCM → Monitoring → Traffic  User session visible with App-ID resolved
                      Non-compliant device (AV off)  HIP fails → access denied, remediation page

## 10. Zero Trust Coverage: Physical PA vs Prisma Access

                      PA Feature  Zero Trust Role  Physical PA  Prisma Access

                      User-ID  Verify WHO — username not IP   HQ only    All locations
                      GP + HIP  Verify WHAT device — posture check   VPN users    All users globally
                      App-ID  Verify WHAT application — not just port   HQ only    All locations
                      Zones + Policy  Least privilege — no lateral movement   Where hardware exists    Cloud-wide
                      SSL Decryption  See inside encrypted traffic   HQ only    All users, all apps
                      DLP  Protect what data is leaving   Limited    Full SaaS + web
                      WildFire + IPS  Verify traffic is not malicious   HQ only    All locations

              💡 Summary

             Zero Trust in Palo Alto is not one toggle — it is the combination of all these features working together, enforced on every session, continuously re-evaluated. Prisma Access extends this enforcement to every user, every location, without requiring hardware at each site.

              ✓ Quick Lab

              Quick Lab (15 min):  (1) Log into the Strata Cloud Manager demo or your Prisma Access tenant. Navigate to Service Connections — note auth method (PSK vs cert). (2) Open Cortex Data Lake; run a search for the past hour's threat events. (3) Build a HIP match object requiring disk encryption + AV updated within 7 days. Attach to a security rule. Verify by toggling the criteria on a test endpoint.

### 🤖 Ask the AI Tutor

             Tap any question — instant, scoped to this lesson. The exact framing an interviewer wants to hear.

                 Is Zero Trust a product I can buy?
                 How is Zero Trust different from a VPN?
                 What is Prisma Access — and when do I use it vs an on-prem NGFW?
                 What is HIP and how is it enforced?
                 What's the difference between User-ID and App-ID?
                 Why does SSL decryption matter for Zero Trust?

             Pre-curated from this lesson + Palo Alto interview Q&amp;A. For a live tenant issue, paste your  show vpn ike-sa  output into chat.techclick.in.

## 📝 Check your understanding

             10 scenario questions — same depth you'll see in PCNSE / PCSAE interviews. Pick one answer per question. You need  70% (7 of 10)  to mark this lesson complete on your profile.

                     Q1
                     An interviewer asks:  "Is Zero Trust a product you can switch on in Palo Alto?"  What's the most accurate answer?

                            (a)  Yes — enable the "Zero Trust" license and it's done.
                            (b)  Zero Trust is a security  framework , not one toggle — Palo Alto implements it by combining User-ID, App-ID, HIP, zones, SSL decryption, DLP and WildFire/IPS, enforced on every session.
                            (c)  Yes — it's just the GlobalProtect VPN with MFA.
                            (d)  No — Zero Trust only exists in Prisma Access, never on a physical firewall.

                      Correct: (b).  Zero Trust is a framework — "never trust, always verify" — not a product or a toggle. Palo Alto implements it through a combination of features working together on every session. (a) and (c) reduce it to one feature; (d) is wrong because Zero Trust applies to both physical NGFW and Prisma Access.

                     Q2
                     A developer says:  "Just give me a VPN to the internal LAN."  Why is per-application Zero Trust access the better answer?

                            (a)  A VPN is faster, so there's no reason to change.
                            (b)  A VPN can't encrypt traffic, but Zero Trust can.
                            (c)  A classic VPN drops the user onto the network with implicit trust to roam; Zero Trust / ZTNA grants access per application after verifying user and device, so there's no "inside the LAN" to move around in.
                            (d)  They are identical — only the marketing name differs.

                      Correct: (c).  A classic VPN grants network-location-based trust — once connected you can reach anything routable. Zero Trust grants access  per application, not per network : the user is verified, device posture checked, and they only ever reach the specific apps policy allows. (b) is false — VPNs do encrypt; (a)/(d) miss the architectural point.

                     Q3
                     Which feature verifies that a connecting laptop has disk encryption on, AV running, and the OS patched  before  it reaches a sensitive app?

                            (a)  App-ID.
                            (b)  User-ID.
                            (c)  HIP (Host Information Profile) reported by the GlobalProtect agent and matched against a HIP object in policy.
                            (d)  WildFire.

                      Correct: (c).  HIP = Host Information Profile. The GlobalProtect agent reports device posture; the firewall matches it against a HIP object so policy only allows compliant devices. A laptop with disabled disk encryption can be blocked or quarantined. User-ID is "who", App-ID is "what app", WildFire sandboxes files.

                     Q4
                     On the same port 443 you must allow Microsoft 365 but block TeamViewer. Which Palo Alto capability makes that possible?

                            (a)  App-ID — it identifies the actual application inside the traffic regardless of port, so policy can allow named apps and deny the rest.
                            (b)  A port-based rule allowing 443 and denying everything else.
                            (c)  User-ID group mapping.
                            (d)  DNS Security.

                      Correct: (a).  App-ID performs Layer 7 inspection — port 443 could be Office365, Dropbox, TeamViewer or malware. App-ID identifies the real application regardless of port so you allow named apps and deny everything else. A port rule (b) can't tell those apart on the same port.

                     Q5
                     Roughly 90% of traffic is encrypted. Why is SSL/TLS decryption essential to a Zero Trust deployment?

                            (a)  It speeds up the connection by removing encryption.
                            (b)  It replaces the need for User-ID.
                            (c)  It is only used to block all banking and health sites.
                            (d)  You cannot verify what you cannot see — without decryption, App-ID, threat prevention and DLP are blind to anything inside HTTPS, so "always verify" breaks down.

                      Correct: (d).  Most traffic is encrypted, and you can't verify what you can't see. SSL decryption lets the firewall open the session, inspect it for threats, exfiltration and disallowed apps, then re-encrypt. Sensitive categories (banking, health) are typically  exempted  for privacy — so (c) is backwards.

                     Q6
                     A 12-person remote sales team needs the same protection as HQ but you can't ship a firewall to each home. What's the right fit?

                            (a)  Ship a PA-3200 to each person's house.
                            (b)  Prisma Access — remote users connect via the GlobalProtect agent to the nearest PoP, where the same security stack runs in the cloud; no hardware per user.
                            (c)  Tell them to use a personal VPN service.
                            (d)  Open inbound ports on the HQ firewall to each home IP.

                      Correct: (b).  Prisma Access is best for remote users and branches where a firewall per site is impractical — inspection happens in the cloud and remote users connect via GlobalProtect to the nearest PoP (Mumbai for India). On-prem NGFW stays at HQ / data centre; you run both under one policy model.

                     Q7
                     When you create the HQ Service Connection in SCM, which crypto settings match the lesson's recommended IPSec config to the HQ PA firewall?

                            (a)  IKEv1, 3DES, DH Group 2.
                            (b)  IKEv2, AES-256-GCM, DH Group 20.
                            (c)  IKEv2, DES, DH Group 1.
                            (d)  IKEv1, AES-128-CBC, DH Group 5.

                      Correct: (b).  The lesson's Service Connection uses IKE Version IKEv2, Encryption AES-256-GCM and DH Group 20 — matched by the HQ firewall's IKE/IPSec Crypto profiles. With GCM (an AEAD cipher) the IPSec authentication can be "none" because auth is built in. Legacy IKEv1/3DES/DES choices are weak and not recommended.

                     Q8
                     After bringing up the tunnel, which CLI command on the HQ PA firewall confirms IKE Phase 1 is established with the Prisma peer?

                            (a)   show user hip-report ip &lt;ip&gt;
                            (b)   show global-protect-gateway current-user
                            (c)   show vpn ike-sa  — it shows IKE Phase 1 state ESTABLISHED with the Prisma peer IP.
                            (d)   show user ip-user-mapping all

                      Correct: (c).   show vpn ike-sa  reports IKE Phase 1 status — expected state ESTABLISHED, peer = the Prisma SC IP.  show vpn ipsec-sa  checks Phase 2. (a) reads device posture, (b) lists GP sessions, (d) checks User-ID mappings — none confirm Phase 1.

                     Q9
                     In a flat network an attacker who lands on one host can pivot to others. How does Palo Alto's microsegmentation stop that east-west movement?

                            (a)  Zones + least-privilege, App-ID/User-ID-aware rules inspect every zone crossing, so a host reaches only what's explicitly allowed — Finance can't reach HR without a rule.
                            (b)  By encrypting the LAN with IPSec end to end.
                            (c)  By giving every host a public IP.
                            (d)  By disabling SSL decryption inside the data centre.

                      Correct: (a).  Microsegmentation puts least-privilege policy between workloads. On Palo Alto every zone crossing is inspected with App-ID/User-ID-aware rules, so even traffic inside the data centre is allowed only where explicitly needed — a compromised host has nowhere to spread.

                     Q10
                     Your team already runs Panorama at scale on-prem and is adopting Prisma Access. The lesson's guidance on management surface is:

                            (a)  You must rip out Panorama and move everything to SCM immediately.
                            (b)  Panorama is deprecated and unsupported for Prisma Access.
                            (c)  Prisma Access can only be managed by CLI.
                            (d)  Panorama with the Prisma Access plug-in remains the dominant, lower-risk surface for tenants migrating from on-prem PAN; SCM is the strategic cloud-native direction.

                      Correct: (d).  Panorama with the Prisma Access plug-in remains the dominant management surface for tenants migrating from on-prem PAN — the lower-risk path if you already operate Panorama at scale. SCM (Strata Cloud Manager) is Palo Alto's strategic, cloud-native, multi-product direction.

                 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.

## Frequently Asked Questions

             The Zero Trust and Prisma Access questions that come up in interviews, design reviews, and the first week on a SASE project.

                 Is Zero Trust a product you can buy?

                     No.  Zero Trust is a security framework , not a single product or a toggle. Its core idea is "never trust, always verify" — every access request is authenticated, authorised, and inspected regardless of where it comes from.

                     Palo Alto  implements  Zero Trust by combining features:  User-ID  (who),  App-ID  (what), zones + least-privilege policy,  SSL decryption ,  HIP  device posture, DLP, and WildFire/IPS — all enforced on every session, continuously re-evaluated.

                 What is the difference between Zero Trust and a traditional VPN?

                     A classic VPN drops the remote user  onto the network  — once connected, they can often reach anything that's routable, with no per-application control. That's implicit trust based on network location.

                     Zero Trust (and ZTNA specifically) grants access  per application, not per network . The user is verified, the device posture is checked, and they only ever reach the specific apps policy allows — there is no "inside the LAN" to move around in.

                 What is Prisma Access?

                     Prisma Access is Palo Alto's  cloud-delivered SASE  — effectively their next-gen firewall stack running as a service in the cloud. Remote users and branch offices connect to the nearest Prisma Access location, and the same security inspection (App-ID, threat prevention, decryption, DLP, URL filtering) runs there instead of on a box at each site.

                     It extends one consistent Zero Trust policy to every user and location  without shipping hardware to each one .

                 Prisma Access vs an on-prem NGFW — when do I use which?

- On-prem NGFW : best at HQ / data centres where you control the hardware and need line-rate inspection of local and north-south traffic.

- Prisma Access : best for remote users and branch offices, where standing up and maintaining a firewall per site is impractical.

                     In practice most enterprises run  both  and manage them with one policy model (often via Panorama / Strata Cloud Manager), so a user gets the same protection at the office, at a branch, or working from home.

                 What is HIP in Palo Alto?

                      HIP = Host Information Profile.  The GlobalProtect agent reports the device's posture — is the disk encrypted, is antivirus running and up to date, is the OS patched, is a required process present — and the firewall matches that against a HIP object.

                     You then write policy that only allows access when the device is compliant. A laptop with disabled disk encryption can be blocked or quarantined before it ever reaches a sensitive app. This is the "verify the device" pillar of Zero Trust.

                 How does microsegmentation stop lateral movement?

                     In a flat network, once an attacker lands on one host they can pivot freely to others (east-west movement).  Microsegmentation  puts least-privilege policy between workloads — segment A can talk to the database it needs and nothing else.

                     On Palo Alto this is enforced with zones + App-ID/User-ID-aware rules, so even traffic  inside  the data centre is inspected and allowed only where it's explicitly needed. A compromised host has nowhere to spread.

                 What role does SSL decryption play in Zero Trust?

                     Most traffic is encrypted, and  you cannot verify what you cannot see . SSL/TLS decryption lets the firewall (or Prisma Access) open the session, inspect it for threats, data exfiltration, and disallowed apps, then re-encrypt it.

                     Without decryption, "always verify" breaks down — App-ID, threat prevention, and DLP would all be blind to anything inside HTTPS. Sensitive categories (banking, health) are typically exempted for privacy and to avoid breaking certificate-pinned apps.

                 What are the pillars of Zero Trust in Palo Alto?

                     The commonly taught set, all working together on every session:

- User-ID — verify the user/group, not just an IP.

- App-ID — verify the application, not just the port.

- Zones + least-privilege policy — no lateral movement.

- SSL decryption — see inside encrypted traffic.

- DLP — control what data leaves.

- WildFire + IPS — verify traffic is not malicious.

                 Does Prisma Access need hardware at every site?

                     No — that's the point of it. Because inspection happens in the cloud, branches connect via  Service Connections / IPSec tunnels  and remote users connect via the  GlobalProtect  agent. There's no firewall appliance to buy, rack, patch, or refresh per location.

                     You still keep on-prem NGFWs where it makes sense (HQ, data centre), but new branches and a growing remote workforce don't each need their own box.

                 What's the difference between User-ID and App-ID?

                      User-ID  answers  who  — it maps an IP/session to a real identity (and AD group) so policy can say "Finance group may use this app".  App-ID  answers  what  — it identifies the actual application in the traffic regardless of port or evasion, so policy can allow "Microsoft 365" while blocking "BitTorrent" on the same port 443.

                     Together they replace the old "IP + port" rule with an identity-aware, application-aware rule — the foundation of a Zero Trust policy.

             Keep going &rarr;

### What's next?

             Go deeper on the model — how ZTNA actually replaces the VPN, broker by broker, policy by policy.

              Next · ZTNA Explained: Zero Trust Network Access That Finally Kills the VPN &rarr;  Practice on exam.techclick.in &rarr;

## Learn Zero Trust hands-on

             Techclick's  Palo Alto Prisma Access training  covers everything in this guide with lab access. Looking at the wider Zero Trust stack? See the  SASE combo  (Prisma + Zscaler + Cisco Umbrella), the  Zscaler ZIA/ZPA syllabus , or the foundational  Palo Alto PCNSA + PCNSE course .

                 Enroll &rarr;
                 All courses

             📩  Quiz me on this in 7&nbsp;days.  Opt in and we'll email you 3 micro-questions from this lesson at Day&nbsp;1, Day&nbsp;7 and Day&nbsp;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
