Destination picks the lane. Salesforce is ZIA: Client Connector or GRE lands on a Public Service Edge; two TLS sessions; SSMA then Firewall → SSL → ATP → AV → Cloud App Control → URL → File Type → DLP → Sandbox. payroll.internal:443 is ZPA: both ends dial outbound 443, the broker stitches, Access Policy allows one App Segment. I prove internet with ip.zscaler.com plus Web Insights. I prove the private app with Diagnostics — not with an inbound firewall rule.
1. Ticket hook — Salesforce up, payroll dark
Night shift. A Pune BFSI user can open Salesforce. Banking throws a certificate warning. The new payroll portal at 172.16.8.20:443 returns app unreachable. Other ZPA apps work. A junior wants SSL inspection disabled “so banking works,” another wants an inbound 443 hole to the payroll server, a third never opened ip.zscaler.com.
That is the interview. Tenant-wide SSL off blinds every later engine. An inbound hole undoes ZPA. An empty Web Insights row is a forwarding miss, not a URL-filter miss. Name the lane, then the hop, then one surgical change.
ZTE — Zero Trust Exchange, the cloud that brokers every connection. ZIA — Internet Access, inline Public Service Edge (older docs still say ZEN). ZPA — Private Access, ZTNA, no inbound ports. ZDX — Digital Experience, splits device vs ISP vs Zscaler hop vs app. Central Authority — control plane, not in the data path. SSMA — Single-Scan Multi-Action inside the PSE. SSL Inspected — Web Insights Yes/No. App Connector — software next to the private app; outbound TLS 443 only. Application Segment — FQDN/IP + port you publish. Z-Tunnel 2.0 — Client Connector all-ports over DTLS/TLS. Do Not Inspect — SSL bypass; later engines do not see the body.
2. Mental model: two lanes on one exchange
Interviewers mix “Zscaler” with “VPN” on purpose. A VPN puts the laptop on a subnet. ZPA never does. A network firewall permits TCP/443. SQLi and DLP ride inside that HTTPS body — only after ZIA decrypts. A policy with no forwarding inspects nothing.
What ZIA owns
Outbound internet and SaaS. Full proxy: two TLS sessions, then SSMA. URL Filtering, Cloud App Control, Cloud Firewall, DLP, sandbox. Proof: ip.zscaler.com + Web Insights.
What ZPA owns
One private app, not the network. App Segment + Server Group + App Connector group + Access Policy. Both ends outbound. Proof: Diagnostics / app health, not a green ZCC icon.
Object tree you should be able to draw cold:
- Laptop with Client Connector — ZIA tunnel (prefer Z-Tunnel 2.0) and ZPA service enabled.
- Office Location — GRE (or IPSec) to two Public Service Edges; sub-location for guest Wi-Fi.
- ZIA: SSL/TLS Inspection Policy, then web-module order. Bypass list for finance / pinned.
- ZPA: App Segment
payroll.internal:443/172.16.8.20:443→ Server Group → Mumbai App Connector group → Access Policy forFinanceSCIM group.
3. Request order on ZTE
Flowchart first. Recite the split; do not skip forwarding.
Destination first. ZIA is a proxy with two TLS legs. ZPA is a stitch of two outbound tunnels. Empty logs mean forwarding failed.
Start from the destination. No PSE hostname is not a URL-filter ticket. A healthy connector serving other apps is not a healthy path to this subnet.
4. How to choose forwarding, inspect, segment
Three tables. Interviewers mix them. Keep the verbs separate: steer, decrypt, broker.
Forwarding into ZIA
| GRE | IPSec IKEv2 | PAC | Client Connector | |
|---|---|---|---|---|
| Use when | Large office, protocol 47 allowed | GRE blocked, or the path must be encrypted | Browser-only, or to fill gaps | Managed / roaming laptops |
| What it carries | Site internet to two Public Service Edges | Same site goal over IKE + ESP | What FindProxyForURL returns |
Z-Tunnel 2.0: all ports (DTLS UDP/443 or TLS TCP/443). 1.0: web CONNECT, typically 80/443 |
| Help limit | Up to 1 Gbps/tunnel when internal IPs are not behind NAT; two DCs | ~400 Mbps per public source IP — scale out or move to GRE | PAC-aware apps only; carve RFC1918 DIRECT | Not a branch firewall. Pair with GRE on trusted LAN (ZIA none, ZPA still on) |
| Interview trap | “GRE is encrypted” — it is not; use IPSec if the transit is untrusted | One tunnel + spare ISP = per-tunnel ceiling, not a bad circuit | “PAC covers all traffic” — it does not cover SSH, QUIC, or non-PAC apps | Z-Tunnel 1.0 + “we have Cloud Firewall” — the FW is blind off 80/443 |
SSL Inspection vs Do Not Inspect
| Inspect | Do Not Inspect (bypass) | CA missing | |
|---|---|---|---|
| What happens | Two TLS sessions; Zscaler intermediate signs the client-side cert; later engines see the body | Tunnel without decrypt; URL/Firewall still see connection metadata, not payload | Browser cert errors on every inspected site |
| Choose when | Default for SaaS and general web after the CA is trusted | Finance categories, certificate-pinned apps/SDKs, after the CA is already deployed | Never leave this as the standing design — push the Zscaler root CA via MDM/GPO |
| Interview trap | “Inspection is on so DLP always ran” — File Type can stop the chain first | Tenant-wide bypass to fix one bank — blinds ATP/DLP everywhere | Removing the CA to “fix” pinning — breaks all inspected HTTPS |
ZPA objects vs a VPN
| Knob | ZPA | Legacy VPN |
|---|---|---|
| What the user gets | One App Segment (host:port), if Access Policy matches group + posture | A route to a subnet — they can scan the rest |
| How the DC opens | App Connector outbound TLS 443; zero inbound | Inbound concentrator / UDP 500 / 4500 |
| Unreachable one app | Segment FQDN:port, Server Group, connector-to-server route | Usually “the tunnel is down” — wrong model here if other apps work |
| SIPA | Selected ZIA traffic can egress via a connector so a partner sees your stable IP | NAT on the VPN head-end — different product, different ticket |
ZIA and ZPA share Client Connector and identity (SAML at login, SCIM groups for policy). They do not share a destination path. “ZIA already inspects everything, so we do not need ZPA” is the panel’s favourite false merge.
5. Do: ip.zscaler.com + Diagnostics
Do not start by disabling SSL inspection or opening inbound 443. Prove the lane, prove the hop, then one object. Lab: Salesforce via ZIA; payroll 172.16.8.20:443 via ZPA Mumbai connectors.
Policies › Common Configuration › SSL/TLS Inspection › SSL/TLS Inspection Policy
Rule · finance-pinned-bypass
Fields interviewers ask you to point at: Rule Action Inspect vs Do Not Inspect, URL category, the Zscaler intermediate CA. Path from Help: About SSL/TLS Inspection Policy. Logs → Insights → Web Insights → Logs is where SSL Inspected lands.
Private Access › Application Segments › payroll-prod
payroll-prod
Miss the Server Group and the app is defined but unreachable. Bind the segment to a connector group that can route to 172.16.8.0/24. Diagnostics “connector up, server unreachable” is that miss — not SAML.
-
Side A — prove the lane and the hop
On the user’s device browse
https://ip.zscaler.com(Help: My IP Address). You want a Public Service Edge virtual IP and hostname, not a raw public-IP lookup. If Salesforce is the complaint and there is no PSE, stop — forwarding is the ticket. If payroll is the complaint, skip ZIA URL rules; open ZPA Diagnostics. -
Side B — prove inspect vs broker objects
ZIA: Logs → Insights → Web Insights → Logs. Quote User, Location, Traffic Forwarding, SSL Inspected, Policy Action. ZPA: Application Segment FQDN:port, Server Group, App Connector group health, Access Policy for the SCIM group. Connector service, outbound 443, DNS/NTP if the whole site is dark.
-
Side C — one change, then re-prove
Banking certs with CA already trusted: do-not-decrypt for that category, keep Inspect as default. Payroll unreachable with a healthy connector: bind the Server Group to the Mumbai connectors that can reach
172.16.8.20. Re-test the original URL. Do not flip the tenant.
# ZIA — device https://ip.zscaler.com # expect: Public Service Edge hostname + virtual IP (not a naked ISP IP) # ZIA — Admin Logs → Insights → Web Insights → Logs # columns: User | Location | Traffic Forwarding | SSL Inspected (Yes/No) | Policy Action # ZPA — object chain Application Segment: payroll.internal:443 / 172.16.8.20:443 Server Group → App Connector group that routes to 172.16.8.0/24 Access Policy: Finance SCIM group + posture App Connector: outbound TLS 443 only — never inbound
# never: disable SSL inspection for the tenant # never: remove the Zscaler root CA # never: open inbound 443 to 172.16.8.20 “because ZPA is down” # never: App Segment 172.16.8.0/24 for everyone # never: claim Cloud Firewall on Z-Tunnel 1.0
ip.zscaler.com shows a PSE VIP and hostname. Web Insights has a row for that user with Traffic Forwarding named (Z-Tunnel / GRE / IPSec / PAC) and SSL Inspected matching the rule. ZPA Diagnostics shows the connector healthy and the backend reachable for that segment. A green Client Connector icon with empty logs is an editor lie — the session never arrived.
6. Runtime path after go-live
After go-live, every new request still picks a lane. Signature and category updates do not move a session from ZIA to ZPA. A Forwarding Profile that mis-detects home Wi-Fi as trusted LAN sets ZIA to none for roamers only — office GRE users stay up. That split is the ticket.
- Internet/SaaS → forward → nearest healthy Public Service Edge → SSL rule → SSMA engines → new TLS to the destination.
- Private FQDN → ZPA broker → Access Policy → stitch to an App Connector that can reach the host:port.
- Z-Tunnel 2.0 keeps Cloud Firewall and DNS Control in path for roamers. 1.0 does not.
- Slowness: ZDX splits device vs Cloud Path/ISP vs Zscaler hop vs app. Do not blame the cloud first.
7. Eight interview scenarios
Q1 · Architecture — two lanes, one exchange
Salesforce loads. payroll.internal is unreachable. A panelist says “ZIA already inspects all traffic, so ZPA is optional.” How can both symptoms be true on the same laptop, and what sits in the ZTE that a router never does?
Strong framing (say this)
ZIA = way out (proxy). ZPA = way in (broker, no inbound). Same agent, same identity, different destination path. I quote the lane before I open a policy.
Evidence to name
ip.zscaler.com PSE hostname for Salesforce; ZPA Diagnostics for payroll.internal; CA vs Service Edge (control vs data). Architecture lesson: Help About Policies (ZPA) + ZIA traffic-forwarding verify.
Q2 · Compare — GRE vs IPSec vs PAC vs ZCC
An 800-user Chennai office must forward to ZIA from the branch firewall with the highest throughput per tunnel. A junior pushed a PAC. Another wants Client Connector on the core switch. Which method, and what fails if they pick a single IPSec tunnel instead?
Strong framing (say this)
GRE for the site, two DCs. IPSec when GRE is blocked, then scale out. ZCC for roamers on Z-Tunnel 2.0. PAC fills gaps.
Evidence to name
Location bound to the tunnel; Insights / VPN tunnel per-tunnel bandwidth; ip.zscaler.com still proves the PSE. Help GRE + IPSec deployment notes.
Q3 · Scenario — banking breaks, keep inspection on
A Pune BFSI: ordinary HTTPS works. Banking and a pinned payment SDK fail only when ZIA SSL inspection is on. A junior wants inspection disabled for the tenant. First action — not a reboot, not “turn Zscaler off.”
Strong framing (say this)
CA first for the many. Do-not-decrypt for the pinned few. I will not disable inspection to make a bank SDK happy.
Evidence to name
Policies → SSL/TLS Inspection Policy Rule Action; Web Insights SSL Inspected Yes/No; served cert chain (Zscaler intermediate vs origin). Help Choosing the CA Certificate for SSL/TLS Inspection.
Q4 · Evidence — ip.zscaler.com, not a guess
A user says “internet is down.” Ping 8.8.8.8 works. Half the SaaS apps load. A junior starts rewriting URL Filtering. What do you search first, and which fields on that row do you quote?
https://ip.zscaler.com (My IP Address). Quote the Public Service Edge virtual IP and hostname. Then Logs → Insights → Web Insights → Logs: User, Location, Traffic Forwarding, SSL Inspected, Policy Action. No row and no PSE hostname means hop 2 failed — Client Connector / GRE / PAC — not a category rule. If SSL Inspected is No, later engines never saw the body.Strong framing (say this)
Give me ip.zscaler.com and one Web Insights row before I touch a rule.
Evidence to name
ip.zscaler.com PSE VIP + hostname; Web Insights columns above; Traffic Forwarding value. Help: Verifying a User’s Traffic is Being Forwarded to the Zscaler Service.
Q5 · Troubleshoot — one ZPA app unreachable
ZPA sign-in works. ZCC shows connected. Other private apps load. A new HR portal at 10.20.5.40:8443 is app unreachable. The App Connector is healthy. First check, then the surgical fix.
10.20.5.0/24. Diagnostics “connector up, server unreachable” is a route/firewall between connector and server, not Zscaler cloud. Bind the Server Group to the local connectors. Do not open inbound 443.*.corp.local mapped to Server Groups in two regions load-balances users to the far DC.Strong framing (say this)
Segment, policy, Server Group, then connector-to-server. I do not punch a hole because one portal is dark.
Evidence to name
ZPA Diagnostics / app health; Application Segment TCP ports; Server Group membership; connector logs. Help About Application Segments / About Policies.
Q6 · Compare — Z-Tunnel 1.0 vs 2.0
A Hyderabad SOC says “remote laptops have ZIA Cloud Firewall, so all ports are protected.” Client Connector status shows Z-Tunnel 1.0. Are they covered, and what would a real Chrome SQLi vs an outbound SSH session look like?
Strong framing (say this)
1.0 is a web proxy. 2.0 is the full tunnel. I will not claim Cloud Firewall until Firewall Insights shows non-80/443 from that user.
Evidence to name
Client Connector tunnel mode; ZIA Firewall Insights for a non-web port; Help Client Connector Z-Tunnel 2.0 (DTLS/TLS). Traffic flow lesson: prefer 2.0 on managed laptops.
Q7 · Unsafe shortcut — SSL off, inbound hole, whole subnet
To “fix” last night’s tickets a junior (a) disabled SSL inspection tenant-wide, (b) opened inbound 443 to 172.16.8.20, and (c) published 172.16.8.0/24 as one App Segment for everyone. What do you undo, and which direction does each control face?
172.16.8.20:443 and an Access Policy for the Finance SCIM group. SSL faces the internet path (ZIA). The connector faces the private app (ZPA). A subnet segment is a VPN in ZPA clothing.Strong framing (say this)
Inspect by default. Bypass the pinned few. Publish the host:port. No inbound. I do not open the tenant to hide one failure.
Evidence to name
SSL policy default Inspect; firewall showing no inbound 443 to payroll; App Segment host:port; Access Policy group. Related ZIA/ZPA scenario lessons.
Q8 · Architecture — inside-out stitch and least privilege
Finance must reach only payroll at 172.16.8.20:443 through ZPA, nothing else on that subnet. Draw the path in words: which side initiates, on which port, and which object enforces “Finance only”?
172.16.8.20:443 (plus FQDN if used), bind a Server Group to connectors that can route there, allow only the Finance SAML/SCIM group. Opening inbound 443 or a /24 segment defeats the model.Strong framing (say this)
Both ends outbound 443. Broker stitches. Segment is the host:port. Policy is the group. I can draw it without a VPN cloud in the middle.
Evidence to name
Connector enrollment / outbound 443; Application Segment definition; Access Policy first-match on SCIM groups; Diagnostics stitch. Help About App Connectors + About Policies.
8. Traps and proof checklist
| Trap | What you see | Safer next step |
|---|---|---|
| No forwarding | Ping works; empty Web Insights; ip.zscaler.com is a naked ISP IP | Fix ZCC / GRE / PAC before any URL rule |
| SSL Inspected = No, still “DLP should have fired” | Bypass or Do Not Inspect; body engines skipped | Quote the SSL column; do not tune DLP yet |
| Tenant-wide SSL off | Banking works; ATP/DLP go dark on SaaS | CA + do-not-decrypt for finance/pinned only |
| One IPSec tunnel for HQ | ~400 Mbps plateau, spare ISP | Scale out IPSec or move the site to GRE |
| Z-Tunnel 1.0 + Cloud Firewall | Rules look live; SSH never logs | Move endpoints to Z-Tunnel 2.0; prove Firewall Insights |
| ZPA segment, wrong Server Group | Connector healthy; one app unreachable | Bind connectors that can route to that subnet |
| Inbound 443 “for ZPA” | App is on the internet again | Close the hole; connector already dials out |
| Whole-subnet App Segment | Users can reach every host in 172.16.8.0/24 | Host:port + group; discovery is not production |
| “Zscaler is slow” | No hop evidence | ZDX: device vs ISP vs Zscaler hop vs app |
- Lane spoken: Salesforce = ZIA Public Service Edge; payroll = ZPA broker + App Connector.
- Forwarding named (Z-Tunnel 2.0 / GRE / IPSec / PAC) and proved on
ip.zscaler.com. - Web Insights row quoted: User, Location, Traffic Forwarding, SSL Inspected, Policy Action.
- SSL: CA trusted; Inspect default; do-not-decrypt only for finance/pinned.
- ZPA chain spoken: App Segment host:port → Server Group → connector group (outbound 443) → Access Policy.
- Unsafe shortcuts refused: tenant SSL off, inbound hole, /24 segment, Cloud Firewall on tunnel 1.0.
Knowledge check
Six judgment items. Each maps to a promise bullet. Check answers, then reset and re-read the traps table if you miss any.
Sources
- Zscaler Help — Verifying a User’s Traffic is Being Forwarded to the Zscaler Service — ip.zscaler.com / My IP Address; Public Service Edge virtual IP and hostname
- Zscaler Help — ZIA Policy Leading Practices Guide — SSMA, firewall vs web module, web-module order, File Type vs DLP
- Zscaler Help — About SSL/TLS Inspection Policy — Inspect vs Do Not Inspect; rule action
- Zscaler Help — Choosing the CA Certificate for SSL/TLS Inspection — two TLS tunnels; Zscaler intermediate vs custom
- Zscaler Help — About Policy Enforcement
- Zscaler Help — About Policies (ZPA) — Access Policy, first-match
- Zscaler Help — About Application Segments — FQDN/IP + ports; Server Group binding
- Zscaler Help — About App Connectors — outbound connectivity to the cloud
Related: ZIA scenario questions · ZPA scenario questions · ZIA traffic flow · Zscaler interview hub