Prisma Access SASE Design Interview Questions: What Architects Are Really Asked
Prisma Access interviews at the architect level are not about recalling product feature lists or subscription tiers. Interviewers want to know whether you can design with the platform — how you architect mobile user connectivity for 50,000 remote workers, how GlobalProtect tunnels interact with Prisma Access infrastructure locations, how service connections integrate the headquarters data centre, and critically, how you enforce Zero Trust policy across a heterogeneous estate without breaking existing application flows.
This guide covers the most important design-focused Prisma Access SASE interview questions — from foundational architecture through SD-WAN integration, Autonomous DEM, policy design, and enterprise migration — answered with the architectural reasoning that distinguishes a strong candidate at the architect level.
① SASE Architecture & Prisma Access Fundamentals
Q1
Explain the Prisma Access architecture and how it differs fundamentally from a traditional hub-and-spoke VPN with on-premises firewalls.
Prisma Access is a cloud-delivered security platform built on a global network of infrastructure locations — Palo Alto Networks-managed points of presence in over 100 locations worldwide. Each infrastructure location runs the full Palo Alto Networks next-generation firewall stack (App-ID, User-ID, Content-ID) as a cloud service. Traffic from mobile users and branch sites is tunneled to the nearest infrastructure location, where all security inspection occurs before the traffic is forwarded to its destination. This fundamentally inverts the traditional hub-and-spoke model: instead of backhauling all traffic to a central data centre firewall (which creates latency bottlenecks and single points of failure), Prisma Access moves the security inspection point close to both the user and the cloud destination. The data centre is no longer the hub — the cloud is the security fabric, and the data centre becomes just another destination reachable via a service connection.
Q2
What are the three primary connectivity models in Prisma Access and what design decisions drive the choice between them?
Prisma Access serves three distinct user populations through different tunnel architectures:
| Connectivity Model | Mechanism | Design Driver |
|---|---|---|
| Mobile Users | GlobalProtect agent over IPsec/SSL | Remote workforce; laptop/mobile with GP client installed |
| Remote Networks (Branches) | IPsec tunnels from CPE/SD-WAN device to Prisma Access | Fixed sites with existing WAN infrastructure |
| Service Connections | IPsec tunnels from HQ/DC to Prisma Access | Private resource access — on-premises apps, shared services |
The design decision is driven by who needs access and from where. A global enterprise will typically deploy all three simultaneously — mobile users connect from anywhere via GP, branch offices connect via IPsec from their SD-WAN edge, and the data centre connects via service connection so that all users can reach internal applications through the Prisma Access security fabric.
Q3
How does Prisma Access select which infrastructure location serves a mobile user or branch site, and what happens during an infrastructure location failure?
Infrastructure location selection uses a combination of IP geolocation, BGP anycast routing, and latency probing. When a GlobalProtect client connects, it probes multiple infrastructure locations and selects the one with the lowest round-trip latency — this is the primary gateway. For remote networks (branch IPsec tunnels), the administrator configures primary and secondary infrastructure locations explicitly, with automated failover driven by IKE dead peer detection. During an infrastructure location failure, GlobalProtect clients automatically re-probe and reconnect to the next-lowest-latency location — typically within 30 seconds. Branch IPsec tunnels fail over to the secondary location via the pre-configured backup tunnel. The critical design implication is that no single infrastructure location is a SPOF — Palo Alto Networks operates each location as a distributed cluster, and the global fabric inherits the redundancy model. Engineers should configure at least two infrastructure locations per geographic region in their remote network design to guarantee sub-minute failover.
② GlobalProtect Tunnel Design & Split Tunnelling
Q4
When would you recommend full-tunnel versus split-tunnel for GlobalProtect users connecting to Prisma Access, and what are the security implications of each?
Full tunnel routes all user traffic — including internet-bound traffic — through the Prisma Access infrastructure location, where it undergoes full NGFW inspection (App-ID, URL Filtering, Threat Prevention, DLP). This provides the strongest security posture because no traffic bypasses inspection. The trade-off is latency: a user in Singapore connecting to a local SaaS application may see their traffic routed through the nearest Prisma Access infrastructure location and then out to the SaaS endpoint — adding round-trip overhead. For most organisations this is acceptable because Prisma Access infrastructure locations are close to major SaaS providers.
Split tunnel routes only specific destinations (corporate subnets, private applications) through the Prisma Access tunnel, while all other traffic goes directly to the internet from the endpoint. This reduces latency for internet traffic but means direct internet traffic bypasses all cloud-delivered inspection. The Prisma Access split tunnel model supports traffic-based, application-based, and domain-based exclusions, allowing fine-grained control. For compliance-driven organisations (healthcare, finance) full tunnel is almost always mandatory. For organisations with globally distributed remote workforces where latency tolerance is low, a carefully defined split tunnel with domain exclusions for known-safe SaaS (Microsoft 365 endpoints published by Microsoft) is architecturally defensible.
Q5
What is the pre-logon tunnel in GlobalProtect and when is it architecturally required?
Pre-logon establishes an IPsec/SSL tunnel to Prisma Access using a machine certificate before the user logs into Windows or macOS. This tunnel authenticates the device (not the user) and enables several critical enterprise capabilities: domain login over VPN (Active Directory authentication for users working remotely who have never logged into the machine on the corporate network), machine-based GPO application, and endpoint compliance enforcement before user access. Pre-logon is architecturally required in any environment where domain-joined machines must authenticate against on-premises Active Directory before user login, or where your Zero Trust policy requires machine identity verification as a precondition for user session establishment. The pre-logon tunnel hands off seamlessly to a user-tunnel after authentication without interrupting network connectivity.
③ Zero Trust Policy & Security Design
| # | Question | Architect-Level Answer |
|---|---|---|
| Q6 | How does Prisma Access enforce Zero Trust for both mobile users and branch sites using a unified policy model? | Prisma Access uses Strata Cloud Manager (formerly Panorama) as the centralised policy control plane. Security rules use User-ID and Device-ID as match criteria — meaning policy is identity-driven, not IP-driven. A mobile user in Singapore and a branch user in London can share the same security rule based on their Active Directory group or HIP (Host Information Profile) posture, regardless of which infrastructure location they connect through. This unified policy model means a Zero Trust rule (deny by default, allow only explicitly permitted user-to-application flows) applies consistently across all connection types without per-location rule duplication. |
| Q7 | What is HIP (Host Information Profile) and how do you use it in a Zero Trust access design? | HIP is a mechanism for GlobalProtect to collect endpoint posture data — OS version, patch level, antivirus status, disk encryption, firewall enabled, registry key values — and report it to Prisma Access. HIP objects match specific posture criteria, and HIP profiles combine multiple objects into a compliance check. In a Zero Trust design, HIP is the device trust signal: a security rule can require that a device match a HIP profile (e.g. Windows 11, patched within 30 days, Cortex XDR running) before accessing sensitive applications. Non-compliant devices are redirected to a remediation VLAN or shown a captive portal page. This ensures that even authenticated users on compromised or unpatched devices cannot access crown-jewel resources. |
| Q8 | How does Prisma Access handle SaaS application access control — what makes its App-ID different from URL filtering alone? | App-ID identifies applications based on behavioural signatures, port, protocol, and application-layer content — not just the URL or port number. For SaaS, this means Prisma Access can distinguish between Microsoft Teams (allow), Microsoft Teams file uploads to personal OneDrive (block), and Microsoft OneDrive sync (allow for corporate tenant only). URL filtering categorises the domain; App-ID identifies the specific application function within that domain. Combined with Cloud Access Security Broker (CASB) capabilities in Prisma Access, this enables tenant restriction — allowing corporate Microsoft 365 but blocking personal Microsoft accounts from the same endpoint, and shadow IT discovery — identifying unsanctioned SaaS usage without requiring a separate CASB proxy deployment. |
⚠ Common Interview Trap: Candidates often describe Prisma Access as "a firewall in the cloud." The correct framing is a converged security platform delivering NGFW, SWG, CASB, ZTNA, and SD-WAN as a unified service. Interviewers at architect level listen specifically for this distinction — it signals whether you understand the SASE model versus simply knowing the product.
④ SD-WAN Integration & Service Connections
Q9
How does Prisma SD-WAN (formerly CloudGenix) integrate with Prisma Access, and what is the design advantage over a standalone SD-WAN with third-party SASE?
Prisma SD-WAN uses the ION device (SD-WAN edge appliance) at branch sites, which natively integrates with Prisma Access via an automated IPsec tunnel onboarding process orchestrated through Strata Cloud Manager. The ION device performs application-aware path selection across MPLS, broadband, and LTE transports for WAN traffic, while routing all security-policy-subject traffic to the nearest Prisma Access infrastructure location. The design advantage of the integrated Palo Alto stack is policy consistency: the same App-ID, User-ID, and Threat Prevention profiles applied to mobile users in Prisma Access apply identically to branch users traversing the SD-WAN to Prisma Access — without any policy translation or vendor normalisation overhead. Third-party SD-WAN integrations with Prisma Access are supported but require manual IPsec configuration and lack the automated lifecycle management that the native ION integration provides.
Q10
Design a service connection architecture for a customer with an on-premises data centre hosting 50 internal applications that must be accessible to all mobile users via Prisma Access.
A service connection establishes an IPsec tunnel from the customer's data centre edge (firewall or router) to a Prisma Access infrastructure location, advertising the internal application subnets via BGP or static routes. The design requires: First, select the infrastructure location geographically closest to the data centre to minimise service connection latency — this is the primary location, with a secondary for failover. Second, advertise only the specific application subnets needed (never a default route) into Prisma Access from the service connection — this prevents the data centre from becoming an inadvertent transit path for all internet-bound traffic. Third, configure BGP with a private ASN on both sides. Fourth, define Security policy rules that permit mobile user IP pools (the subnets allocated to GP clients) to reach the specific internal application subnets on the required ports — using User-ID to layer identity-based policy on top of IP-based connectivity. The service connection becomes the private backbone for all user-to-data-centre traffic, replacing traditional split-tunnel VPN to an on-premises firewall.
⑤ Autonomous DEM & Operational Visibility
| # | Question | Architect-Level Answer |
|---|---|---|
| Q11 | What is Autonomous DEM in Prisma Access and how does it change the operational model for troubleshooting user experience issues? | Autonomous Digital Experience Management (ADEM) continuously measures end-to-end application experience from the GlobalProtect endpoint through the Prisma Access fabric to the SaaS or data centre application destination. It collects real user monitoring (RUM) data — latency, jitter, packet loss, application response time — at every hop: endpoint to infrastructure location, within the Prisma Access fabric, and infrastructure location to application. When a user reports "Salesforce is slow," ADEM immediately shows whether the issue is on the endpoint's ISP connection, within the Prisma Access infrastructure, or at the Salesforce origin — eliminating the traditional "the problem is on your end" troubleshooting loop between network and application teams. This shifts the operational model from reactive ticket-based troubleshooting to proactive experience scoring with automated alerting when user experience degrades below defined thresholds. |
| Q12 | How does Strata Cloud Manager provide a unified management plane, and what is its role in a multi-tenant enterprise deployment? | Strata Cloud Manager (SCM) is the cloud-based management and analytics platform for the entire Palo Alto Networks Strata portfolio — Prisma Access, Prisma SD-WAN, and on-premises NGFWs can all be managed from a single policy and visibility plane. In a multi-tenant enterprise (multiple business units or subsidiaries with different security requirements), SCM supports hierarchical policy management: a global base policy defined at the parent tenant level propagates to all child tenants, while each child tenant can define local policy additions without overriding the global baseline. This is critical for compliance-driven enterprises where global minimum security standards must be enforced consistently but local variations (specific application access, regional data-residency requirements) need to be accommodated without a separate deployment per business unit. |
⑥ Migration Strategy & Brownfield Design
| # | Question | Architect-Level Answer |
|---|---|---|
| Q13 | A customer is migrating from Cisco AnyConnect to Prisma Access GlobalProtect for 20,000 remote workers. What migration strategy do you recommend and what are the critical risk points? | A phased migration using parallel operation is mandatory — never a cut-over. Phase 1: deploy Prisma Access infrastructure (service connections to data centre, infrastructure location configuration) in parallel with existing Cisco ASA/Firepower VPN. Phase 2: migrate a pilot group (100-200 users, preferably IT staff) to GlobalProtect with Prisma Access, validating application reachability, HIP compliance, and authentication flows against all identity providers (SAML/LDAP). Phase 3: regional wave migration — 1,000-2,000 users per wave with 48-hour validation windows. Critical risks: (1) IP address pool overlap — GlobalProtect IP pools must not overlap with existing AnyConnect pools or internal subnets; (2) Application DNS resolution — internal application DNS must resolve correctly for GP users, requiring DNS split-horizon or dedicated internal DNS servers reachable via service connection; (3) Legacy application compatibility — some applications use source IP-based access control and must be updated to accept the GP IP pool before migration. |
| Q14 | How does Prisma Access handle DNS security and what design decisions govern whether you use Prisma Access DNS Security versus an on-premises DNS resolver? | Prisma Access DNS Security uses the same cloud-delivered DNS sinkholing and malicious domain detection as Palo Alto Networks DNS Security subscription, applied inline to all DNS queries processed by the infrastructure location. For mobile users in full-tunnel mode, all DNS queries transit Prisma Access and are inspected — this provides complete visibility and protection without client-side DNS changes. For split-tunnel users, only DNS queries for corporate domains (routed through the tunnel) are inspected; internet-bound DNS goes directly to the ISP resolver unless the DNS proxy is configured to redirect all DNS through the tunnel. The design decision for on-premises DNS revolves around internal application resolution: Prisma Access must be able to forward internal domain queries (corp.internal, app.company.com) to an internal DNS server reachable via service connection. This requires explicit DNS proxy configuration in Strata Cloud Manager with domain-based forwarding rules. |
Q15 — The Architect Closer
A global financial services firm has 30,000 mobile users, 200 branch offices, two data centres (London, Singapore), on-premises Palo Alto NGFWs at HQ, and a Cisco SD-WAN fabric. Design the full Prisma Access SASE architecture.
Mobile Users (30,000): Deploy GlobalProtect with Prisma Access, pre-logon enabled for domain-joined devices, full-tunnel for all traffic (financial compliance). Select primary infrastructure locations by region: EMEA (Amsterdam, London), APAC (Singapore, Sydney), Americas (New York, Los Angeles). HIP profiles enforce Windows/macOS patch status, Cortex XDR presence, and disk encryption as preconditions for accessing trading applications. Branch Offices (200): Existing Cisco SD-WAN fabric connects via IPsec tunnels from each site to nearest Prisma Access infrastructure location. Two infrastructure locations per region as primary/secondary. App-ID-based policy steers SaaS traffic directly (with Prisma Access inspection) and private application traffic via service connection. Data Centres (London, Singapore): One service connection per DC, BGP advertising internal application subnets. Prisma Access infrastructure locations nearest to each DC serve as the service connection anchor. On-premises NGFWs: Managed via Strata Cloud Manager alongside Prisma Access in a unified policy hierarchy — on-premises policy mirrors cloud policy for consistent Zero Trust rules. ZTNA for Private Apps: Replace legacy VPN with Prisma Access ZTNA for application-specific access — trading systems, risk management, HR — with per-app MFA enforced via SAML IdP. Autonomous DEM: Deployed globally for proactive experience monitoring — SLA-based alerting for trading application latency exceeding 20ms threshold at the infrastructure-location-to-application segment.
Key Principles to State in Any Prisma Access SASE Interview
| Prisma Access is not "a firewall in the cloud" | It is a converged SASE platform: NGFW + SWG + CASB + ZTNA + SD-WAN |
| Infrastructure locations ≠ SPOF | Each is a distributed cluster; clients auto-failover to next-nearest location |
| HIP = device trust signal | Zero Trust requires both identity (User-ID) and device posture (HIP) match |
| Service connections = private backbone | Advertise only specific subnets — never a default route into Prisma Access |
| ADEM closes the visibility gap | End-to-end path analysis from endpoint to app — eliminates "not my problem" loops |
Approaching the Prisma Access SASE Interview
The questions above share one consistent thread: every strong answer frames Prisma Access as a design platform, not a product checklist. Interviewers are listening for whether you understand the architectural trade-offs — full-tunnel versus split-tunnel, native SD-WAN integration versus third-party, service connection subnet scope, HIP posture as a Zero Trust gate — and whether you can sequence a real-world migration without creating an outage.
Lead with the constraint that drives the design decision. Name the alternative and explain why you discarded it. State clearly what the chosen approach costs — in latency, operational complexity, or licence scope. That reasoning is what defines a Prisma Access SASE architect in every interview room.
Prisma Access features and Strata Cloud Manager capabilities evolve with each platform release. Validate all design decisions against current Palo Alto Networks deployment guides and Best Practice Assessment documentation for your target software version and subscription tier.
