Prisma Access Interview Q&A — 40 questions a panel actually asks

Three connection types: Mobile Users — roaming laptops and phones connect via the GlobalProtect agent (or Explicit Proxy) to a cloud gateway. Remote Networks — branch or office sites connect over IPSec/IKEv2 tunnels from their edge router or SD-WAN device. Service Connections — these reach your private apps in a data centre or HQ; they are the path Prisma Access uses to send traffic to internal resources, not a user on-ramp.

Said simply: Mobile Users and Remote Networks bring users in; Service Connections let that traffic reach private apps.

A Service Connection (also called a Corporate Access Node / CAN) is an IPSec tunnel from Prisma Access to your data centre or HQ, used to reach private apps and to let Mobile Users and Remote Networks talk to each other. A Remote Network is a branch on-ramp that mainly needs secured internet egress.

Key difference: a Service Connection is not for internet breakout and is not bandwidth-metered the way Remote Networks are — it advertises your internal routes (typically via BGP) so the cloud knows how to reach 10.20.0.0/16. Mis-labelling a DC link as a Remote Network instead of a Service Connection is a classic design mistake.

The Portal is the control point: the agent first contacts it to download configuration — which gateways exist, agent settings, and authentication method. It does not carry user data traffic. The Gateway is the dataplane: after the portal hands over the list, the agent builds its tunnel to the best gateway, and that is where security policy, App-ID, User-ID, and decryption are applied.

In Prisma Access both run as cloud services. Interview tip: if asked "where is policy enforced for a mobile user?", the answer is the gateway, never the portal.

GPCS (GlobalProtect Cloud Service) is the cloud backbone that hosts the firewall instances. A Prisma Access location is a specific point of presence you onboard to — say India South (near Chennai) or India West (Mumbai). A compute location groups two or more nearby Prisma Access locations and is the level at which you actually allocate bandwidth and where the cloud can shift load.

So you onboard a branch to a location, but you buy and allocate bandwidth at the compute location aggregate. This matters when sizing — you don't reserve per-site.

Strata Cloud Manager (SCM) is the cloud-native console — task-driven onboarding, AIOps, ADEM, best-practice baseline policies, no on-prem appliance. Panorama-managed uses the Prisma Access plugin on a Panorama you operate, which suits shops with heavy existing Panorama estates and complex device-group/template stacks.

For a new rollout in 2026 I'd choose SCM: Palo Alto stopped offering Panorama-based multi-tenancy for new Prisma Access deployments from 15 April 2026, and ADEM and many visibility features live in SCM regardless of management mode. I'd only stay on Panorama if the customer already runs a large Panorama-driven hardware fleet and wants one pane for both.

Two meters. Mobile Users are licensed per user (the count of named or concurrent users you buy). Remote Networks are licensed by bandwidth, allocated at the compute location aggregate (Mbps), not per site. Service Connections typically come bundled with the deployment up to a count.

For 4,000 users + 30 branches: buy a 4,000+ Mobile User license, then sum branch egress — if 30 branches average 50 Mbps that's ~1.5 Gbps, allocated across the relevant compute locations (e.g. India West and India South) with headroom. Because bandwidth is per compute location, a busy Mumbai branch can borrow from a quiet one in the same group instead of needing a dedicated reservation.

Both ultimately traverse the cloud backbone to the Service Connection that terminates at the Mumbai DC. The Bangalore user's GlobalProtect tunnel lands on a gateway; the Chennai branch's Remote Network IPSec tunnel lands on its Remote Network node. From there, Prisma Access routes the packet to the Service Connection that advertises 10.30.0.0/16 (the app subnet) and forwards it down that tunnel to the DC.

The single requirement that ties it together: the app's route must be reachable via the Service Connection — learned by BGP from the DC router or configured statically. No route on the SC, no access, no matter how clean the user tunnel is.

IPSec with IKEv2 (IKEv1 is supported but IKEv2 is the recommended default). The branch device — a Palo Alto firewall, a Cisco/Fortinet edge, or an SD-WAN appliance — builds a site-to-site IPSec tunnel to the Prisma Access Remote Network node. You define IKE Phase 1 (authentication, DH group, encryption) and Phase 2 (the IPSec SA / proxy-IDs or route-based tunnel) to match on both ends.

For dynamic routing you run BGP over the tunnel; for small sites you can use static routes instead.

Steps: (1) In SCM, create the Remote Network, pick the Prisma Access location (e.g. India South) and the compute location bandwidth. (2) Define an IKE Gateway — peer = the branch public IP (or dynamic with an IKE ID), pre-shared key or certificate, IKEv2. (3) Define the IPSec tunnel/crypto profile matching the branch's Phase 2. (4) Enable BGP: set the Prisma Access ASN and the branch ASN, advertise the branch LAN 192.168.40.0/24, and Prisma Access advertises the cloud-side prefixes back.

On the Wipro edge, mirror the IKE/IPSec settings and form the BGP session over the tunnel. Verify the tunnel is up and the BGP neighbor shows Established with routes both ways.

Originally you reserved bandwidth per Remote Network site, which wasted capacity — a quiet site held Mbps a busy one needed. With aggregate bandwidth (Prisma 1.8+), you allocate a pool at the compute location, and Prisma Access distributes it dynamically across all Remote Networks in that group based on load.

Practical effect: for five Maharashtra branches you buy, say, 300 Mbps at the West compute location instead of fixed 60 Mbps each. A branch with a traffic spike can use more, as long as the aggregate isn't exhausted. You size the pool to peak concurrent demand, not the sum of every site's max.

Build two IPSec tunnels from the branch — one per ISP — to the Prisma Access Remote Network, ideally to two different IKE gateways/IPs. With BGP over both, you advertise the branch LAN on both tunnels. ECMP lets Prisma Access (and the branch) load-share return/forward traffic across both equal-cost paths instead of idling one.

If you prefer active/standby, set BGP attributes — higher local-preference or AS-path prepending on the backup — so the primary ISP carries traffic and the secondary takes over on failure. The design choice is ECMP (use both, more throughput) versus deterministic failover (one primary). State clearly which you'd pick and why; panels love that you know the trade-off.

Over the Service Connection you typically run BGP between the DC edge router and Prisma Access. The DC advertises internal prefixes (e.g. 10.20.0.0/16, 10.30.0.0/16); Prisma Access advertises the Mobile User pool and Remote Network prefixes back so the DC can return traffic.

Order/scope matters because Prisma Access uses these advertisements to decide which Service Connection reaches a given app. If two SCs both advertise 10.20.0.0/16, you need consistent BGP attributes (or summarisation) or traffic may take a suboptimal SC. Always confirm the DC actually has a return route to the Mobile User subnet — a one-way advertisement gives you the classic "tunnel up, app half-works" symptom.

Prisma Access resolves the best path much like a firewall: most-specific prefix wins first (a /24 beats a /16), then routing-protocol and attribute logic. Across BGP paths it applies standard selection — local-preference, AS-path length, then MED — and within equal-cost paths it can ECMP.

Where candidates slip: a Service Connection route and a Remote Network route can both claim a subnet. You control the outcome with prefix specificity and BGP attributes rather than hoping. For private apps you generally want the Service Connection path preferred; for internet you want local breakout at the Remote Network. Make the intent explicit in your advertisements instead of relying on defaults.

With Prisma SD-WAN, the ION device at the branch uses a CloudBlade integration to automate the IPSec tunnels and routing to Prisma Access — the SD-WAN controller programs the Remote Network connectivity for you, so you don't hand-build every tunnel. ADEM can also be enabled on those SD-WAN Remote Networks for path visibility.

A third-party SD-WAN (Cisco, Fortinet, VeloCloud) onboards as a standard Remote Network: the SD-WAN edge originates the IPSec/IKEv2 tunnel and BGP session exactly like any branch router. The win with native Prisma SD-WAN is automation and end-to-end visibility; third-party works fine but you build and monitor the tunnels yourself.

GlobalProtect agent — a full tunnel from a managed device; carries all traffic, supports HIP posture checks, and gives the richest control. Use it for corporate laptops. Explicit Proxy — the browser/OS is pointed at a Prisma Access proxy (PAC file or explicit settings); good for unmanaged or browser-centric access where you can't deploy an agent. Clientless VPN — users hit a portal page and reach specific web apps through the browser, no agent at all; handy for contractors and BYOD reaching a few internal web apps.

Rule of thumb in interviews: managed device → agent; unmanaged but proxy-capable → Explicit Proxy; quick browser-only access to a handful of web apps → Clientless.

The Cloud Identity Engine (CIE) is Palo Alto's cloud-based directory and authentication service. It syncs users and groups from Azure AD / Entra ID, on-prem AD, or an LDAP/SCIM source and brokers authentication (SAML/OIDC) so Prisma Access can do User-ID and group-based policy without you deploying User-ID agents or domain controllers in the cloud.

Why it matters: in a cloud-delivered firewall you still need to write rules like "Finance group can reach the payroll app." CIE provides that user-to-group mapping and identity in the cloud, which is exactly what makes group-based security policy and ZTNA decisions possible for roaming users.

HIP (Host Information Profile) is an endpoint-posture report the GlobalProtect agent sends to the gateway — disk encryption state, OS patch level, antivirus running and up to date, firewall on, a required process present, domain membership, and so on. You define HIP objects/profiles and reference them in security policy to gate access.

Example for a Hyderabad SOC: write a rule that lets the SOC group reach the SIEM only if the laptop reports disk encryption = on AND EDR running. A device failing HIP gets a notification and is denied or sent to a remediation page. That's posture-based access — identity and device health, not just credentials.

Functionally it's the same engine: App-ID identifies the application from the traffic itself (not just port), and User-ID maps the source to a user/group so policy reads "who + what," e.g. "Marketing can use youtube-base but not youtube-uploading." The difference is where mappings come from.

On-prem you collect User-ID via the agent reading DC logs. In Prisma Access the source of identity is typically GlobalProtect login (the user authenticates to connect) plus CIE for group mapping, with optional Directory Sync. There are no domain controllers in the cloud, so you don't run a traditional User-ID agent — identity arrives with the tunnel and the directory sync. App-ID and the policy logic are unchanged.

It's SSL Forward Proxy running in the cloud gateway: Prisma Access presents a certificate signed by your Decryption CA (which you push to endpoints as trusted), decrypts the session, inspects with App-ID, threat prevention, and URL filtering, then re-encrypts to the server. SCM ships a best-practice decryption baseline you tune.

You exclude traffic that breaks or shouldn't be inspected: certificate-pinned apps (many banking and some Microsoft/Apple update channels), categories like financial-services and health-and-medicine for privacy/compliance, and anything using mutual TLS. Use a decryption exclusion / no-decrypt policy by URL category or custom list. For an Indian BFSI you'd typically also exclude regulator and core-banking endpoints by policy.

The ZTNA Connector is a lightweight connector you deploy next to your private apps (in the DC or a cloud VPC). It makes an outbound connection to Prisma Access, so you publish specific applications rather than building an inbound Service Connection that exposes whole subnets. Users reach only the apps they're authorised for; there's no broad network route and no inbound firewall hole.

This is true Zero Trust app access: policy is per-application and identity-aware, the app is dark to the internet, and you avoid the "VPN gives the laptop the whole 10.0.0.0/8" problem. Contrast with a Service Connection, which routes a user onto the corporate network — fine for broad access, but the ZTNA Connector is the tighter, app-by-app model for sensitive or third-party access.

I'd publish that single app via the ZTNA Connector (or Clientless VPN if it's a simple browser app and I want zero install). Both give access to just that app without putting the contractor's unmanaged laptop onto the corporate network.

I would not hand them the full GlobalProtect tunnel — that's for managed devices and grants broad network reach plus HIP overhead they can't meet. The principle: least privilege. A contractor gets exactly one application, identity-checked, with the app never exposed to the internet. ZTNA Connector if I want per-app policy and posture signals; Clientless if it's truly just one web app and speed of onboarding wins.

Prisma Access Browser is an agentless secure enterprise browser (Chromium-based, from the Talon acquisition). Security controls — decryption, URL filtering, DLP, copy/paste and download restrictions — run inside the browser, so the work happens on unmanaged or BYOD devices without installing a full tunnel client. The user signs in, the browser enforces policy on the SaaS and private web apps they open, and Strata Cloud Manager governs it.

Choose it for contractors, third parties, and BYOD reaching web/SaaS apps where you can't push GlobalProtect or a HIP agent. It now carries real exam weight (about 22% of the 2026 SSE-Engineer blueprint). Keep the GP agent for managed laptops needing a full tunnel; use the Browser where the access is web-app-only and the device isn't yours.

Two layers. Inline (forward proxy) DLP runs in the gateway dataplane: as traffic to SaaS apps is decrypted, an Enterprise DLP profile scans it against data patterns (PAN, Aadhaar, card numbers) and blocks or alerts on uploads — same engine for GlobalProtect users, Remote Networks, and the Browser. SaaS Security (CASB) adds visibility and control: an inline component classifies sanctioned vs shadow-SaaS apps, and an API-based (out-of-band) component connects to tenants like Microsoft 365 or Google Workspace to scan data at rest and fix risky shares after the fact.

So for an Indian BFSI: inline DLP stops a card number being pasted into a personal Gmail in real time, while SaaS API scanning finds an already-shared sensitive file in OneDrive. You attach the DLP profile in security policy and onboard the SaaS tenants in Strata Cloud Manager.

Pre-logon brings up the GlobalProtect tunnel using a machine certificate before any user logs in to Windows — the device authenticates as itself, so connectivity exists at the lock screen. Once the user signs in, the session transitions to user authentication. It's enabled in the GP portal agent config with a pre-logon connect method and a machine-cert profile.

You need it when the endpoint must reach the network without a logged-in user: domain controllers reachable for first-ever domain join or GPO/login-script processing, cached-credential-free logins, and remote OS/patch management. For a corporate Pune fleet that must apply group policy and let a brand-new laptop authenticate to AD over Prisma Access, pre-logon is the design answer — without it the user can't get a Kerberos ticket because the DC was never reachable at logon.

ADEM (Autonomous Digital Experience Management) gives end-to-end visibility of a user's experience — it synthetically and passively measures each hop of the path: endpoint → Wi-Fi/LAN → ISP → Prisma Access → the application. It surfaces latency, packet loss, and jitter per segment, so you can prove whether a slowdown is the user's home Wi-Fi, their ISP, the cloud, or the app itself.

Why panels love it: help-desk tickets say "Salesforce is slow." ADEM lets you answer "it's Aman's home ISP adding 180 ms, not Prisma Access" instead of guessing. It runs from a GlobalProtect endpoint agent and on Remote Networks, and you view it in Strata Cloud Manager.

Prisma Access firewalls forward logs to Cortex Data Lake (CDL) — the cloud-scale logging store Palo Alto uses instead of an on-prem log collector. Traffic, threat, URL, and decryption logs land in CDL, and Strata Cloud Manager / the dashboards read from it. You don't size or manage log-collector appliances; you buy a CDL storage allotment.

From CDL you can also forward logs onward to a SIEM. Quick framing: in a hardware deployment Panorama + Log Collectors hold logs; in Prisma Access that role is Cortex Data Lake, a managed cloud log lake.

Two common paths. (1) NSS / Log Forwarding from Cortex Data Lake — you stand up the Palo Alto Strata Logging Service forwarding (historically the NSS, the syslog forwarding service) or the native log-forwarding app that streams CDL logs to your syslog/SIEM collector. (2) The SIEM vendor's API integration pulls from CDL.

For a Mumbai bank's Splunk: deploy the forwarder, point it at the CDL tenant, filter to the log types Splunk needs (traffic + threat), and validate volume against your Splunk license. Key interview nuance: logs originate in CDL first, then forward out — you're not pulling directly off each cloud firewall.

Strata Cloud Manager is the cloud console: it owns onboarding, policy, AIOps, ADEM, and reporting for cloud-managed tenants — and you use SCM for visibility/ADEM even in Panorama-managed deployments. The Panorama plugin manages Prisma Access policy and config from a Panorama you run, fitting shops that already drive a hardware fleet through Panorama device-groups and templates.

Operationally: SCM means no appliance, faster onboarding, and best-practice baselines; Panorama means a single pane across cloud and on-prem hardware and reuse of existing template stacks. With Panorama multi-tenancy closed to new deployments from 15 April 2026, new builds default to SCM while large legacy Panorama estates stay on the plugin.

Prisma Access runs a dataplane PAN-OS version that Palo Alto upgrades as a service — you don't TFTP an image onto a box. In SCM you schedule/approve the upgrade window; the cloud rolls the gateways and Remote Network nodes. There's a notion of a preferred/innovation version versus a more conservative one, and you can stage.

The gotcha: feature parity and agent compatibility. A new dataplane version may expose a feature your Panorama plugin or GlobalProtect agent version doesn't yet support, and some features land in cloud-managed before Panorama-managed. So before approving, check the compatibility matrix — dataplane version against your management mode and agent version — and schedule the window off business hours for the affected India regions.

Open the user's ADEM dashboard in Strata Cloud Manager and read the path segment by segment: endpoint → Wi-Fi/LAN → ISP → Prisma Access → application. ADEM reports latency, loss, and jitter at each hop, so you can see exactly where the time goes.

Typically you'll find the delay sits before the cloud — say 160 ms of jitter on the user's home ISP or saturated branch Wi-Fi — which clears Prisma Access. If the cloud or app segment is the culprit, you've got hard numbers to escalate to the right owner instead of arguing. The interview point: ADEM turns a subjective complaint into per-segment evidence, and most "the cloud is slow" tickets resolve to ISP or last-mile.

Phase, never flip. (1) Design & onboard — stand up Mobile Users on the right India locations, build Service Connections to the DCs, and rebuild policy/HIP/decryption in Strata Cloud Manager, validated against the old ruleset. (2) Parallel run — keep the legacy VPN live and pilot a small group (one office, ~100 users) on Prisma Access; the two paths coexist because users just get a new portal/agent config. (3) Wave rollout — move users office-by-office, watching ADEM and help-desk volume, with the old VPN as instant rollback. (4) Cutover & decommission — once a wave is stable, withdraw its access on the legacy gateway; retire old concentrators only after the last wave.

Gotchas: push the GlobalProtect agent and remove the old AnyConnect client; re-map split-tunnel and DNS rules (don't assume); license the full 20,000 before the final waves; pre-stage machine certs if you use pre-logon. Auth (SAML/MFA) and internal-DNS are the risk points — test those first.

Build one (ideally two, for redundancy) Service Connection from Prisma Access to the DC edge. Components: an IKE Gateway and IPSec/IKEv2 tunnel terminating on the DC firewall/router, anchored to the nearest compute location (India West). Routing: run BGP over the SC — the DC advertises the app subnets (summarise the 50 apps into a few prefixes like 10.20.0.0/16 rather than 50 host routes), and Prisma Access advertises the Mobile User pool and Remote Network prefixes back so the DC has a return path.

Add an internal DNS rule so the corporate suffix resolves to 10.20.0.53 over this SC, and a security rule allowing the right groups to the apps. Bandwidth: a Service Connection is not the internet-egress meter — it's sized for east-west app traffic, so estimate aggregate concurrent app load and place a second SC (different DC router / ISP) for failover. The single make-or-break: every app prefix must be reachable via the SC, advertised both ways.

Map each population to a connectivity model. Remote workforce → Mobile Users with GlobalProtect (managed laptops) plus Explicit Proxy / Prisma Access Browser for BYOD, landing on India West and India South gateways. 30 branches → Remote Networks over IPSec/IKEv2 with BGP, bandwidth bought as an aggregate pool per compute location sized to concurrent peak, dual tunnels for the larger sites. DCs/private apps → redundant Service Connections (BGP), with the ZTNA Connector for sensitive per-app access.

Security: one policy model — CIE for User-ID/groups, App-ID rules, decryption with sensible exclusions, HIP posture gates, threat/URL/DNS Security and Enterprise DLP profiles. Identity: SAML/MFA via CIE to Entra ID. Operations: Strata Cloud Manager as the console, ADEM for per-segment experience, Cortex Data Lake for logs forwarded to the SIEM. The narrative that wins: users in (MU/RN), private apps reached over SC/ZTNA, one cloud policy plane, visibility through ADEM + SCM.

Start from where users and branches actually are, not a default. Onboard Prisma Access locations closest to each cluster — typically India West (Mumbai/Pune) and India South (Chennai/Bangalore/Hyderabad), adding an APAC location only for frequent travellers. The goal is local breakout near the user so traffic doesn't hairpin across regions.

Bandwidth: Mobile Users are licensed by user count and the cloud auto-scales gateway capacity, so you license enough concurrent users per region. Remote Networks are sized by aggregate Mbps at the compute location — sum each region's branch egress to concurrent peak (not the arithmetic sum of every site's max) and add headroom; e.g. 18 western branches at ~50 Mbps busy-hour might need ~700–800 Mbps in the West pool rather than 18×max. Validate post-go-live with ADEM per-segment latency and grow the pool before it saturates. Region selection is a latency decision; bandwidth is a concurrency decision — keep them separate.

Bottom-up. (1) Reachability — can the branch public IP reach the Prisma Access IKE gateway IP at all (ISP up, no upstream filtering of UDP 500/4500)? (2) IKE Phase 1 — check both ends for matching IKEv2 settings, pre-shared key, and IKE ID; a PSK or ID mismatch is the most common cause. (3) IPSec Phase 2 — confirm the crypto profile and proxy-IDs/route-based settings match. (4) BGP — once the tunnel is up, is the neighbor Established and are routes exchanged?

In SCM check the Remote Network status and tunnel monitor; on the branch firewall read the IKE/IPSec logs. Name the failing phase before you touch config — that's what separates an L2 answer from "I'd reboot it."

Asymmetric routing means the request goes out one path and the reply tries to return by another, so the stateful firewall drops the reply (no matching session). Confirm by checking whether two Service Connections (or an SC plus a Remote Network) both advertise the app subnet, causing forward and return to land on different nodes. Look for session/TCP-state drops in the traffic logs and inconsistent paths in ADEM.

Fix by making routing deterministic: summarise or make one path more specific, or set BGP local-preference / AS-path so the app subnet has a single preferred Service Connection for both directions. Ensure the DC advertises the Mobile User / Remote Network return prefixes consistently down the same SC. The goal is one symmetric path per flow.

Private name resolution needs Prisma Access to send internal queries to your internal DNS servers. Check the DNS proxy / DNS settings in the Mobile Users config: there should be a rule that forwards the private domain (e.g. *.corp.tcs.local) to the internal resolver at 10.20.0.53, reachable over a Service Connection. Public/everything-else goes to the default/public resolver.

Common causes: the internal-domain DNS rule is missing, the internal resolver isn't routable via the SC, or split-DNS isn't configured so the corporate suffix isn't matched. Verify the SC has a route to 10.20.0.53 and that the domain-to-resolver mapping exists — then the app's hostname resolves and traffic follows.

Top causes, fastest to slowest: (1) Authentication — wrong creds, expired SAML/MFA session, or a misconfigured auth profile; check the gateway auth logs. (2) Portal/gateway reachability — DNS to the portal FQDN, or a captive-portal/local firewall blocking the GlobalProtect ports. (3) HIP failure — the device fails posture (disk encryption off, EDR not running) and policy denies it. (4) Agent/version or certificate — outdated agent or a distrusted portal certificate.

Method: read the GlobalProtect agent logs on the laptop and the gateway logs in SCM together — they usually name the stage (auth vs HIP vs connectivity). Fix the named stage rather than reinstalling blindly.

This is suboptimal gateway/location selection. The user's GlobalProtect agent may be landing on a non-nearest gateway, or the location mapping/compute-location config is steering them away from India South. Causes: portal returning a distant gateway, a manual gateway selection, the nearest location not licensed/onboarded, or DNS/GeoIP resolving the user to the wrong region.

Fix: confirm the nearest Prisma Access location is onboarded and has bandwidth, check the gateway priority / location settings so the agent picks the closest one, and validate with ADEM that the user now egresses from Chennai/India South. For Remote Networks, verify the site is mapped to the correct compute location. The principle: traffic should break out near the user, not hairpin across regions.

Two different meters. Mobile Users scale by user license count and the cloud auto-scales gateway capacity in each onboarded location — your job is to license enough users and onboard the locations close to where people actually work (India West, India South, plus any APAC sites for travellers). Remote Networks scale by aggregate bandwidth at the compute location; you size that pool to concurrent peak branch egress, not the sum of every branch's max.

For scale planning: watch ADEM and bandwidth utilisation per compute location, add Mbps before you saturate the pool, and add gateway locations only when users cluster in a new region. The trap candidates fall into is reserving per-site bandwidth or under-licensing concurrent mobile users during peak hours.