A contractor on a personal MacBook needs to read your industry's risky-news sites for an investigation project. The corporate URL policy blocks the News category. Which Zscaler action gives the business the access while keeping security comfortable?

Correct answer: Build a URL Filtering rule with action ISOLATE for the News category scoped to the contractor's user-group. Correct: B. CBI (action ISOLATE) is exactly the third path between "block" and "allow" — the user gets the content as pixels, no executable code touches the BYOD laptop. (A) creates a security hole; (C) ZPA is for private apps, not public web; (D) SSL Inspection has nothing to do with this category decision.

A user reports that pasting an OTP from their phone's SMS app into an isolated banking page does nothing. The CBI profile has Clipboard = Outbound only. What's actually happening?

Correct answer: Outbound clipboard means CBI → user direction only, so paste from user → CBI is blocked. The user needs Inbound or Bidirectional to paste into the isolated page. Correct: A. Clipboard direction is named from the CBI farm's perspective — Outbound = CBI → user. To paste into the isolated page the user needs Inbound (or Bidirectional). Banking-OTP flows are the classic example where Inbound-only is the right setting. (D) is false — clipboard works fine in CBI, it's just controlled by policy. Disclaimer: clipboard direction naming convention varies by Zscaler product version. In recent docs, "Outbound" = direction from the isolated viewport back to the user's local clipboard (CBI → user). Some older docs use the opposite. Always verify in your specific tenant's portal copy before answering an interview question on this.

Your SaaS admin says "give me your 4 source IPs so I can whitelist them in our Salesforce IP restriction". Your tenant has 100,000 users behind Zscaler's elastic cloud. What's the right Zscaler feature to deploy?

Correct answer: SIPA — Source IP Anchoring — anchoring Salesforce traffic to a Dedicated Proxy pool. Correct: C. SIPA Dedicated Proxy gives the tenant a small, stable pool of egress IPs exactly so the SaaS admin can whitelist them. (A) CBI handles risky web rendering, not egress IPs; (B) ZPA is private apps, not public SaaS; (D) bypassing Zscaler loses inspection and policy.

Six months after a SIPA rollout, every user is locked out of Salesforce on Monday morning. Friday-night maintenance happened on the Zscaler side. What's the most likely root cause?

Correct answer: Traffic flipped to the SIPA failover pool, whose IPs were never added to the Salesforce allow-list. Correct: C. Classic SIPA failure mode — both primary and failover IPs must be on the SaaS allow-list. If only the primary was added, any maintenance event that swings traffic to failover blocks every user instantly. (A), (B), (D) don't explain a SaaS-specific lockout.

A user reports their CBI'd multi-tab Jira looks "logged out" the moment they click any link that opens in a new tab. Which behaviour are you seeing?

Correct answer: CBI session forking — each new tab spins up a separate disposable container with no shared cookie jar, so the second tab has no Jira session. Correct: B. Multi-tab webapps that rely on shared cookie state across tabs hit CBI's session-forking problem. The fix is either enable session continuity for that domain in the CBI profile, or exclude the app from CBI entirely (Jira shouldn't have been isolated in the first place). (A), (C), (D) don't fit a "every new tab is fresh" symptom.

Compliance requires that user web egress comes from your AWS Production VPC, not Zscaler's cloud. Which SIPA deployment model fits?

Correct answer: Customer-Owned NAT via Cloud Connector — traffic is forwarded to your Cloud Connector VM in AWS, NATs out via your Elastic IP. Correct: D. Customer-NAT via Cloud Connector is exactly the model where the egress IP the destination sees is yours, not Zscaler's. This is now the modern Zscaler-recommended SIPA path. (A) Dedicated Proxy IPs are Zscaler-owned, even though dedicated to your tenant; (B) App Connector is for ZPA private-app brokering, not for ZIA egress; (C) CBI is unrelated to egress IP ownership.

You want to confirm SIPA is actually firing for users in the policy. What's the fastest L3 check?

Correct answer: Open https://ip.zscaler.com from a SIPA-policied user and from a non-policied user; the reported IP should differ and match the dedicated pool for the policied user. Correct: D. ip.zscaler.com reports the public source IP the destination sees. Comparing a SIPA user vs a non-SIPA user proves the anchoring is working. (A), (B), (C) are made-up — there's no SIPA CLI test, no SIPA tray badge, no SIPA cert signing.

Security wants every CBI session to leave a forensic artefact so an insider can't quietly screenshot an isolated page and exfil via their personal phone. Which CBI control most directly addresses this?

Correct answer: Enable Watermark with username + timestamp + IP, optionally pair with Session Recording. Correct: C. Watermark bakes an identifying overlay into every rendered frame — any screenshot or analog-hole photograph carries the analyst's identity. Session Recording adds an auditable replay. (A) doesn't stop screenshots; (B) is irrelevant; (D) ZPA is for private apps.

Your CISO asks for a contractor-access architecture: contractors on personal devices need access to your corporate Workday (a SaaS that demands an IP allow-list). What's the right Zscaler stack?

Correct answer: CBI for the contractor's risky-device problem, stacked with SIPA so Workday's IP allow-list sees the dedicated egress pool. Both compose cleanly inside the ZIA tunnel. Correct: B. Two different problems → two different tools, composed. CBI handles the device-trust gap (no native code on the contractor's machine); SIPA handles the SaaS-trust gap (Workday sees your stable IP). (A) leaves the SaaS allow-list problem unsolved; (C) leaves the BYOD problem; (D) defeats the contractor-flexibility goal.

Insights → Web Insights shows zero "Isolated" hits for the M&A Research rule you built last week, even though analysts are clearly browsing the News category. Where's the most likely problem?

Correct answer: Another URL Filtering rule above yours is matching first with action ALLOW or BLOCK, so the isolate rule never gets evaluated. Check rule order. Correct: A. URL Filtering rules are evaluated top-down, first match wins. If a rule above your isolate rule already handles News with ALLOW or BLOCK, your rule never sees the traffic. Move the isolate rule above the conflicting rule. (B) is rare and would show as errors elsewhere; (C) is possible but would result in different symptoms (uncategorised hits); (D) SIPA doesn't pre-empt URL Filtering.

Cloud Browser Isolation & Source IP Anchoring — The Edge-Case Tools

Why this lesson matters — the two "yes-but" tools

After Lessons 1–11 you can wire up ZIA and ZPA end-to-end. Real production rollouts then hit two recurring walls that ZIA + ZPA on their own cannot answer cleanly:

Wall #1 — the BYOD/contractor problem. A contractor on a personal MacBook needs to read risky-category sites all day. You don't own the device, can't install Z-App, can't enforce EDR. The honest answers used to be "block the category" (business loses) or "allow and pray" (security loses). CBI is the third option — render the page in a disposable cloud browser, stream pixels to the user, never let executable code touch the laptop.

Wall #2 — the SaaS allow-list problem. Salesforce admin emails: "send me your 4 source IPs for IP-based login restriction". Your 100,000 users sit behind thousands of rotating Zscaler egress IPs — no admin will whitelist that. SIPA hands you a small, stable pool of dedicated egress IPs; you give those four to the SaaS admin and the allow-list works.

Neither feature appears on a marketing front page, but every enterprise rollout hits both within the first quarter. Walking into a Zscaler interview without these two in your pocket is the fast way to lose a senior offer.

CBI — what it actually does

Cloud Browser Isolation runs a single-use, throwaway Chromium inside Zscaler's cloud. When a user's request to a risky URL is matched by a URL Filtering rule with action ISOLATE, ZIA hands the session to a CBI farm. The CBI browser fetches the page, renders it in an ephemeral container, and streams the result back as HTML5 canvas + safe input events streamed over WSS (WebSocket Secure). The user's local browser is a thin viewport — it never receives HTML, JavaScript, images, fonts, downloads, or any active content.

Three things travel through CBI in normal use:

Down to the user — a video/canvas stream of the rendered page. Right-click → View source returns the wrapper page's HTML (the CBI viewport), not the origin's HTML. The origin's actual page content never leaves the CBI farm — only the rendered pixels reach the user.
Up from the user — keystrokes, mouse clicks, scroll, and (if policy permits) clipboard input. Translated into corresponding actions inside the CBI browser.
Out of the session — when the user closes the tab or hits the inactivity timeout, the container (cookies, cache, disk state) is destroyed. No persistence by design.

L3 mental model: CBI is an air-gap implemented in software. The risky page runs in a sandbox far from your user; only the painted result crosses. Any malicious payload that drops on the container dies with the container.

CBI policy modes — three flavours, three intents

CBI is invoked per URL Filtering rule. Three operating modes in the admin portal:

Always Isolate — every match is silently handed to CBI; no interstitial, the tab just renders. Best for "News & Media for our M&A team" — they don't need to know it's isolated, they just need to read.
Conditional Isolate — extends Always with device posture, location, time-of-day, user-group, or trust score. Common: "isolate Gambling only for unmanaged BYOD; managed laptops bypass". Same URL, different verdict per asker.
Interactive Isolate (Caution) — Zscaler-branded interstitial: "This site is risky. Click to open isolated." Educates the user about risk while keeping a path forward. Best for unknown-reputation where silent isolation might confuse them.

Contrast with BLOCK: block says no, isolate says yes, pixel-streamed. That single distinction makes CBI a productivity tool — analysts get information, security gets its air-gap.

Zscaler Troubleshooting Lab Cloud Connector (SIPA backhaul)

The whole CBI architecture on one page

CBI — pixel-streaming hand-off inside the ZIA tunnel

Solid blue arrows = the user's request path. Magenta arrows = page payload — note it terminates at the CBI farm. Only the dashed magenta pixel stream returns to the user.

CBI controls — what each toggle actually does

Inside a CBI profile (Policy → URL Filtering → Cloud Browser Isolation → Profiles) you'll see roughly the following knobs. They look small; they're the difference between CBI working and a tidal wave of helpdesk tickets.

Control	What it does	L3 recommendation
Clipboard	Bidirectional / Inbound only (user → CBI) / Outbound only (CBI → user) / Blocked	For risky-web isolation, Inbound only — user can type/paste passwords or notes into the isolated page, but cannot copy data out. Bidirectional defeats the data-protection point.
File Upload	Allow / Block uploads from the user's local disk into the isolated page	Block by default. Allow only for specific app-of-record patterns (e.g. an isolated submission portal).
File Download	Allow / Sandbox-then-deliver / Block	Sandbox-then-deliver: the file gets detonated in Zscaler Sandbox first, only the verdict-clean files reach the user. Pure Block annoys users; pure Allow defeats CBI.
Print	Allow / Block printing the rendered page	Block for data-sensitive isolation rules; allow for "make it usable" categories like news.
Screenshot / Watermark	Overlay a translucent watermark with username, timestamp, IP across every rendered frame	Always on for any analyst / research / M&A team. A screenshot of an M&A target's earnings page with "ravi.k@acme · 2026-05-23 14:22" splashed across it is a strong insider-threat deterrent.
Session Timeout	How long an idle CBI container stays alive before destruction	15 min for normal browsing, 5 min for high-sensitivity (financial, source-code-on-the-web), 60 min for long-form research where the user reads slowly.
Local Browser Sync	Inherit cookies / bookmarks / extensions from user's local Chrome profile	Off. The whole point of CBI is a clean disposable browser. Pulling in the user's extensions imports their attack surface.

CBI deep dive — what breaks, and why

Three categories fight CBI in the field. Recognise them on day-one:

Banking and OTP-paste apps. User gets SMS OTP on the phone, tries to paste into the bank's login — but if clipboard is Outbound-only, the paste fails silently and the user thinks "the bank is broken". Best fix: don't isolate the banking category at all; isolate only actual risky stuff.
Multi-tab webapps that fork sessions. Jira, Confluence, modern dashboards open links in new tabs expecting the same auth cookie to follow. CBI session forking is per-tab — each new tab can spin a separate container with no shared cookie jar. User looks "logged out" on tab two. Fix: enable session continuity for that domain in the CBI profile, or exclude the app from CBI entirely (it shouldn't have been isolated anyway).
Latency-sensitive and rich-media apps. Zoom, Teams, Webex, WebRTC, screen-share — anything sub-100ms or bandwidth-heavy — flies poorly because you're round-tripping a video stream through a remote Chromium. Voice and video should never be in an isolate rule. Heavy file-upload workflows (Drive, SharePoint, S3 console) degrade too; isolate only the read path if you can.

💰CBI cost — scope it tightly

CBI is a paid add-on with per-session metering in most tenants. Deploying "Isolate Social Media" for the entire company can blow a quarterly budget. Scope CBI to high-risk categories (Newly Registered Domains, Uncategorized, Suspected Phishing) — not Social Media.

SIPA — what it actually does

ZIA by default egresses each user's traffic from whichever Service Edge they hit — and Zscaler has hundreds of PoPs rotating through pools of egress IPs published in the cenr (Cloud Enforcement Node Range) list. From the SaaS's perspective your users come from any of ~5,000 IPs and the set drifts as Zscaler grows. No admin will ever whitelist 5,000 drifting IPs.

SIPA flips this. You pin specific traffic flows to a small, stable pool of egress IPs. The user still gets PoP proximity for the inbound leg, but the outbound leg — the IP the destination SaaS sees — comes from your dedicated pool. The SaaS admin gets a 4-IP allow-list that doesn't change for years.

SIPA is policy-driven, not a tenant-wide flag. Anchor only what needs it (Salesforce, Workday, Okta admin) and let the bulk of internet traffic ride the elastic pool — that keeps your paid dedicated capacity focused on flows that need it.

SIPA deployment models

Source IP Anchoring — Modern Path

The current Zscaler recommendation for SIPA is Cloud Connector: deploy Cloud Connector VMs in your AWS/Azure/GCP VPC. Outbound traffic egresses via your cloud's NAT Gateway / Internet Gateway / direct EIP — the SaaS endpoint sees your owned IP, not Zscaler's pool. Auditable, allow-listable, and the egress IP lives in your account.

Legacy: Dedicated Proxy / Dedicated PoP. Older Zscaler-hosted egress SKU where you got 2-8 reserved IPs on Zscaler infrastructure. Still supported for some tenants but no longer the preferred path for new deployments. Get both primary and failover IPs in the contract and add both to the SaaS allow-list (see Common Mistakes). If your tenant has it, fine — but new SIPA designs in 2026 should be Cloud Connector first.

3rd-party partner POPs: Some Zscaler partners (e.g. Aryaka, Equinix) offer their own egress IPs that integrate with ZIA forwarding. Niche; usually only relevant for specific compliance/geo needs.

Hybrid is where most large enterprises land. Modern path (Cloud Connector) for SaaS that demands "must come from our prod VPC", legacy Dedicated Proxy for tenants that still have it, bulk internet on elastic Zscaler egress. SIPA policy picks the right egress per destination.

SIPA request path — what the SaaS actually sees

SIPA — pinning egress to a stable IP for SaaS allow-lists

Sequence is left-to-right. Modern path: traffic goes ZIA Service Edge → customer Cloud Connector in VPC → AWS NAT Gateway → SaaS sees the customer's own EIP. The diagram shows the legacy Dedicated Proxy variant for simplicity; in 2026 prefer Cloud Connector so the egress IP is tenant-owned and lives in your account.

CBI + SIPA stack pattern — they compose cleanly

The common production pattern: a contractor on an unmanaged Mac needs access to your sanctioned SaaS. You want CBI on top (BYOD: no native code on the device, watermark, controlled clipboard) and SIPA underneath (your SaaS only allows your dedicated egress IPs).

They compose cleanly because they sit at different tunnel layers. CBI is invoked by URL Filtering after SSL inspection and before egress shaping; SIPA is invoked by Forwarding / Egress policy and runs after the response leaves CBI's container toward the destination. In a stacked rule the request leaves the contractor's local browser, hits ZIA, is handed to CBI; CBI fetches the destination, and CBI's fetch is then SIPA-anchored to your dedicated egress IP. SaaS sees your stable IP and allows login; contractor sees only pixels and cannot exfil.

This is the architecture you describe in a senior-engineer interview for "Zero Trust SASE for contractor access". Both halves needed: CBI handles the device-trust gap, SIPA handles the SaaS-trust gap.

CBI + SIPA Troubleshooting Cloud Connector NAT egress App Connector contrast

Quick configuration walkthrough

The admin portal lives at https://admin.zscaler.net (or your tenant's cloud variant). The two flows you'll execute most often:

CBI — wire up an Always-Isolate rule for risky news

1. Policy → URL & Cloud App Control → Cloud Browser Isolation → Profiles
   → Add Profile "M&A-Research"
     • Clipboard: Inbound only
     • Upload: Block · Download: Sandbox-then-deliver
     • Print: Block · Watermark: ON (Username + Timestamp + IP)
     • Session timeout: 60 min

2. Policy → URL & Cloud App Control → URL Filtering Policy
   → Add Rule "Isolate News for M&A Team"
     • Rule Order: 5 (above generic news rules)
     • URL Categories: News & Media, Newsgroups, Blogs
     • Users / Groups: ad-group "MA-Research"
     • Action: ISOLATE
     • Isolation Profile: M&A-Research
     • Logging: Full

3. Activate

SIPA — anchor Salesforce traffic to dedicated egress IPs

1. Administration → Source IP Anchoring → Dedicated Proxies
   → Verify the IPs allocated to your tenant (e.g. 203.0.113.10, .11
     primary; 198.51.100.20, .21 failover). Copy ALL four.

2. Email your SaaS admin: add all four IPs to the Salesforce
   "Trusted IP Ranges" / Login IP Range. Confirm in writing
   they added the failover pair too (this is where rollouts break).

3. Policy → Forwarding Control → SIPA Policy
   → Add Rule "Salesforce via Dedicated Egress"
     • Source: All users (or scoped AD group)
     • Destination: Cloud App = Salesforce
       (also try URL Category = Salesforce as belt-and-braces)
     • Action: Forward via Dedicated Proxy (primary pool A)
     • Failover: Dedicated Proxy (failover pool B)

4. Activate. Test from a user laptop:
     curl --resolve login.salesforce.com:443:<ip> -I https://login.salesforce.com
     Or just open Salesforce and confirm login succeeds; check Insights
     → Web → "Egress IP" column for that session.

✓Verify — prove both pieces are actually firing

CBI fired? Insights → Web Insights → filter Action = Isolated. Drill in: the per-request detail shows the CBI profile name and the disposable session ID. If you see zero hits, your URL Filtering rule probably has another rule above it with action ALLOW winning the match.
SIPA fired? From a SIPA-policied user's laptop, open https://ip.zscaler.com. The page reports the public IP that ip.zscaler.com saw — that should be one of your dedicated pool addresses. Open the same page from a user not in the SIPA policy and confirm it shows a different (elastic) IP. The difference is the proof.
SaaS allow-list integration end-to-end. Have the SaaS admin temporarily remove one dedicated IP from the allow-list and try login from a user that would have egressed via that IP — expected: SaaS rejects login with a "from an untrusted IP" error. Put the IP back, retry — login works. That round-trip proves the allow-list path is real, not just configured-and-forgotten.
CBI watermark visible. Open any isolated page, hit Cmd+Shift+4 / Snipping Tool, take a screenshot. The username + timestamp overlay should be baked into the pixels — if it isn't, your CBI profile has Watermark off.

⚠Common Mistakes — the seven that bite every rollout

CBI on Social Media for the entire company — endless "I can't upload my LinkedIn pic" / "my video won't play" tickets within hours. CBI is for risky content, not for categories users live in daily.
Allowing clipboard out of CBI defeats the data-protection point. An analyst pastes 50 lines from an isolated page into a Word doc — exactly the exfil channel CBI was meant to close. Outbound clipboard off by default.
SIPA failover IPs forgotten. Zscaler does Saturday maintenance, traffic flips to failover, those IPs were never on the SaaS allow-list, entire workforce locked out Monday. Always confirm in writing the SaaS admin whitelisted both primary and failover pairs.
SIPA enabled without telling the SaaS admin. If Zscaler rotates your dedicated pool IPs (rare but happens at SKU changes), the SaaS allow-list goes stale and users get blocked. Keep a written runbook + change-control process for IP changes from either side.
CBI watermarking off = an insider screenshots an isolated page and exfils via personal-phone photo (the analog-hole) without a trace. Watermark every sensitive CBI session — it's a strong deterrent and a forensic marker.
CBI applied to plugin-dependent apps (legacy Java applets, ActiveX, certain Citrix portals) — the disposable browser is plugin-free by design, so these apps won't work in isolation. Pilot first.
SIPA confused with ZPA. SIPA is ZIA — it controls the egress IP of outbound web traffic. ZPA brokers private apps; no egress IP to worry about. "Use ZPA to fix our Salesforce allow-list" = wrong tool.

💡Pro Tips — practitioner-only knowledge

For phishing-link clicks, pair CBI with the email gateway. Rewrite suspicious URLs in inbound mail so any user click goes through a CBI-isolate forwarder. A user clicks a credential-harvester from a phishing email → renders in CBI → keystrokes for the fake login still get logged by the harvester, but no payload, no cookie steal, no exfil path back to the user's device. Combined with watermark + session recording, you've also got a forensic artefact of exactly what the user did on the phish site.
Use SIPA selectively, not blanket. SIPA capacity is a paid SKU and dedicated pools are finite — every flow you SIPA-anchor consumes from the same pool. Anchor only what the SaaS allow-list requires (typically 4–8 SaaS apps), leave the long tail of internet traffic on the elastic Zscaler egress. This also keeps your dedicated pool unblemished — a single user hitting a category-blocked destination from a dedicated IP won't get the IP listed on a public threat feed.
CBI session recording for high-sensitivity rules. Some CBI profiles support recording the entire user session (the pixel stream gets archived). Don't enable it everywhere — privacy, storage cost, GDPR — but for "isolated access to crown-jewel SaaS by privileged users" it produces an auditable artefact that satisfies most compliance auditors who balk at "trust the watermark".

Real-world scenario — Acme's M&A research team

Setup. Acme's 50-person M&A team researches acquisition targets daily — 30+ articles across obscure financial-news outlets, regional sites, leaked-document repositories, pastebin tips. Many sites run sketchy ad-tech, malvertising, and watering-hole campaigns aimed at exactly the people who research deal flow.

Acme's baseline: managed laptops, Z-App enrolled, EDR running. Default URL policy blocks News & Media for the wider company. The M&A team needs the opposite — more news access, safely.

Rule design.

Profile MA-Research: Clipboard = Inbound only · Upload = Block · Download = Sandbox-then-deliver · Print = Block · Watermark = ON · Timeout = 60 min.
URL Filtering rule "M&A — Isolate News", ordered above the company-wide block rule. Categories: News & Media, Newsgroups, Blogs, File Sharing, Pastebin. Group: MA-Research-Team. Action: ISOLATE. Profile: MA-Research. Logging: Full + Session Recording.
Activate. A team member hits a previously-blocked news site — opens in CBI instead.

The malicious-news test. A week later an analyst clicks a tip-off link to a compromised regional financial blog hosting a drive-by exploit for a 14-day-old Chrome CVE. In the pre-CBI world, the laptop is owned, attacker laterals into SharePoint, deal-pipeline docs exfil. In the CBI world:

Page fetched and rendered by disposable Chromium in the CBI farm, far from the analyst's device.
Exploit fires inside the container, drops a payload — compromises the container only.
Analyst sees pixels: the painted article. Reads it, closes the tab.
On tab close the container (and the payload) is destroyed. No persistence.
Insights logs the session plus a Sandbox alert on the malicious script. Security gets the IOC, adds a tenant-wide block.

Net: research productivity preserved, security gets a forensic artefact + early-warning IOC, the laptop executed zero attacker code. That's the CBI story that wins this lesson in the interview room.

Quick reference card

CBI & SIPA — last-mile revision

CBI ≠ Block. Block says no. CBI says yes, pixel-streamed.
CBI streams pixels, not code. HTML / JS / files terminate at the CBI container, only the rendered video and safe input cross to the user.
BYOD / contractor / risky-category are the canonical CBI use cases. Don't isolate apps your users live in daily.
CBI controls: Clipboard · Upload · Download · Print · Watermark · Session timeout · Local-profile sync. Watermark = always on for sensitive rules.
SIPA = stable egress IP. Pinning outbound web traffic to a small, dedicated pool of IPs your SaaS admin can whitelist.
SIPA models: Dedicated Proxy (Zscaler-owned IPs) · Customer-NAT via Cloud Connector (your AWS / Azure IP) · Hybrid (per-app routing).
Failover IP gotcha. Always add BOTH primary and failover pools to the SaaS allow-list. Get it in writing.
CBI + SIPA compose in stacked rules — CBI inside the tunnel, SIPA at egress. The standard pattern for contractor → corporate-SaaS.
Verify path: ip.zscaler.com for SIPA · Insights → Web → Action = Isolated for CBI · screenshot test for watermark.
SIPA ≠ ZPA. SIPA is a ZIA egress construct. ZPA is private-app brokering. Different problems, different tools.

▶ QUICK LAB · ~15 MIN

Configure CBI + SIPA:

In ZIA Admin → URL Filtering → create a rule: Newly Registered Domains + Action = Isolate.
From a test laptop, browse a known-new domain (or use a CBI test URL from Zscaler). Verify the page renders inside the CBI viewport.
Try right-click → View Source. Confirm you see the wrapper, not the origin's HTML.
For SIPA: deploy a Cloud Connector VM in your AWS test VPC. Verify a SaaS request egresses via the Cloud Connector's EIP (not via Zscaler's pool).

What's next?

Module 13 takes you to the operational side — ZIA Insights, ZPA Diagnostics, NSS log streaming to your SIEM, ZDX user-experience monitoring, and the top 5 real troubleshooting patterns you'll diagnose in production.

Lesson 13 — Logs, ZDX & Troubleshooting → Practice on exam.techclick.in

CBI & SIPA — Browser Isolation & Stable Egress for SaaS