T Techclick All lessons
Zscaler · Cloud & Branch Connector · Branch Connector

Zscaler Branch Connector Zero-Touch SASE for Every Branch

Branch IT shouldn't need a CCNP and six hours to bring a new shop online. Zscaler Branch Connector replaces GRE/IPsec config with a TPM-signed appliance that activates the moment you plug it in — and the whole onboarding, forwarding, and troubleshooting story lives in a browser.

📅 2026-05-24 · ⏱ 16 min read · 🏷 10-question assessment included
🎯 By the end of this lesson, you'll be able to

💡 The DTH set-top box analogy

Remember the first time a Tata Play / Airtel DTH technician installed a set-top box at your home? He plugged it into power, pointed the dish, and the box knew which account it belonged to — because a tiny smart-card inside was paired to your subscription at the factory. No CLI, no IP plan, no SSH session.

Zscaler Branch Connector is the DTH set-top box of the SASE world. A small appliance (or a VM you spin up in 90 seconds) arrives with a TPM 2.0 chip already signed for your Zscaler tenant. Plug in power and an Ethernet cable, and the branch shows up in your admin console ready to be assigned a location and a forwarding policy. That's it. The cloud is doing the heavy lifting.

Why this matters in production (and in interviews)

Branch onboarding is one of those problems that looks solved on the slide deck — "just terminate an IPsec tunnel to ZIA" — and falls apart the moment you have 200 stores opening on the same Diwali rush. Every interview for a Network Security L2/L3 role at Flipkart, Reliance Retail, HDFC, or any large Indian retail/BFSI player will hit you with at least one of these questions:

If you can answer these three with structure, you'll separate yourself from 80% of the resumes in the pile. This lesson hands you that structure.

Core concept: what Branch Connector actually is

Zscaler Branch Connector (BC) is a dedicated forwarding appliance — either a small hardware box or a virtual machine — that sits at the edge of a branch LAN and steers all branch traffic to the nearest ZIA Service Edge over a DTLS tunnel, with a TLS fallback if UDP is blocked.

What it replaces:

What it doesn't replace: laptops still get the Zscaler Client Connector (ZCC) agent for roaming protection — Branch Connector is for traffic inside the branch and for devices that can't run an agent.

Infographic 1 of 4 — The big picture
Branch LAN devices feed a Branch Connector appliance, which builds a DTLS tunnel to ZIA Service Edge and a TLS tunnel to ZPA Public Service Edge, both reachable from any branch over plain internet. Branch LAN — Lucknow Store Staff laptops (ZCC agent) PoS terminals (no agent) IP cameras (IoT) Printer / BACnet (OT) Zscaler Branch Connector Public Internet (no static IP needed) DTLS / UDP 443 ZIA Service Edge SSL inspection, URL filter, FW, DLP, Sandbox Internet-bound traffic ZPA Public Service Edge Brokered private-app access (ZTNA) Internal-app traffic
Every device behind the BC — agent or no agent — gets cloud-inspected without a per-device tunnel. ZIA handles north-south, ZPA handles private-app brokering.
👩‍💻 Scenario · Sneha at Reliance Retail, Lucknow

Sneha is the regional NetSec engineer for Reliance Retail's North zone. A new SMART Bazaar opens at Hazratganj on Saturday. The store has 15 cashier PoS terminals, 8 IP cameras, 1 printer, and 6 staff laptops — and the only person on-site is the store manager, who knows how to operate a CCTV DVR but has never seen a CLI. Sneha needs to ship a box that the store manager can plug in, and have traffic flowing through ZIA by store opening at 09:00.

Hardware models and VM platforms

Branch Connector ships as both physical appliances and virtual machines. Pick by branch size (concurrent users + throughput needs).

Model Throughput CPU / RAM / Storage Ports Fits
ZT-400 200 Mbps 4-core / 16 GB / 256 GB 4 × 1 GbE RJ45, 1 × USB 3.1 Small shop, 15–25 devices
ZT-600 500 Mbps 4-core / 16 GB / 256 GB 6 × 1 GbE RJ45, 2 × USB 2.0 Medium branch, 50–100 devices
ZT-800 1 Gbps 8-core / 32 GB / 512 GB 6 × 1 GbE RJ45 + 2 × 1 Gb SFP fiber, 2 × USB 3.0 Large branch / regional HQ, 200+ devices
VM image Scales to host Min 4 vCPU / 8 GB / 40 GB vNIC(s) per hypervisor Data centre, warehouse already running ESXi/KVM, or AWS/Azure

Supported VM platforms: VMware ESXi, KVM, Microsoft Hyper-V, AWS EC2, Azure VM, GCP Compute Engine. All four hardware models embed a TPM 2.0 chip whose certificate is mapped to the device serial during manufacturing — that's the magic that makes zero-touch possible.

👉 So far: BC is a small appliance/VM, DTLS to ZIA, no static IP needed, four sizes. Next we'll walk through the actual onboarding flow.

Zero-Touch Provisioning, step by step

ZTP is the headline feature. Here's what happens between the courier dropping the box and traffic flowing:

  1. Pre-stage in the admin portal. The Zscaler admin (Sneha) logs into the Cloud & Branch Connector admin console and creates a Branch Provisioning Template — name, location, time-zone, sub-cloud, default forwarding profile. She attaches the device serial (visible on the box label) to the template.
  2. Ship the box. Courier delivers to the store. No firmware preload, no PSK in a sealed envelope.
  3. Plug-in. Store manager connects a WAN cable to WAN1 and AC power. The box boots, the ZTP agent comes up, and it sends a DHCP request to grab a public-side IP.
  4. TPM-signed handshake. The ZTP agent uses the TPM 2.0 certificate (factory-bound to the serial) to authenticate to Zscaler's cloud. Zscaler matches the serial to the tenant — and only to that tenant. A device shipped to Tenant-A will not register to Tenant-B even if someone tries.
  5. Provisioning template download. The cloud sends the configuration the admin pre-staged: location, sub-cloud, forwarding profile, allowed VLANs, optional static routes.
  6. DTLS tunnel build. The BC opens a DTLS connection (UDP/443) to the closest ZTE Service Edge. If UDP 443 is blocked outbound, it falls back to TLS over TCP/443. ZPA uses a parallel TLS connection.
  7. Status flips to Active. The admin sees a green dot in the console. Cameras, PoS, laptops behind the BC start hitting ZIA right away.

End-to-end timing in a well-prepared branch: 5–8 minutes. If a tech on-site has done it before, under 4.

Infographic 2 of 4 — The ZTP flow (left to right)
Six-step left-to-right flow: power on, TPM-signed authentication, template download, DTLS handshake, traffic flowing. 1 Plug in WAN + power. DHCP gets IP. 2 TPM auth Cert signed at manufacture 3 Template pull Loc + fwd profile 4 DTLS up UDP 443 → Service Edge 5 Status: Active Green in admin console 5–8 minutes end-to-end
Sneha's end-state: a green dot in the console means the DTLS tunnel is live and the BC is steering branch traffic to the nearest Service Edge.

Configuration walkthrough

Below is the admin-portal flow you'd show in an interview as your "day in the life of a Zscaler admin". All paths are inside the Cloud & Branch Connector admin portal (the URL Sneha bookmarks: https://connector.zscalerthree.net for the .net cloud, or your tenant's sub-cloud).

Step 1 — Create a Branch Provisioning Template

Admin portal path 
Administration  →  Provisioning & Configuration  →  Branch Provisioning Templates  →  + Add Template

  Template Name:         BPT-LKO-SmartBazaar-North
  Sub-cloud:             zscalerthree.net
  Default Location:      LKO-SmartBazaar-Hazratganj
  Time Zone:             Asia/Kolkata (UTC+05:30)
  Default Fwd Profile:   ZTunnel-2.0-Branch (created in step 3)
  Optional VLANs:        10 (Staff), 20 (PoS), 30 (IoT-Camera)
  Save → Template ID generated: BPT-00042
✓Expected output

Template appears in the list with status Ready. A "Devices Attached: 0" counter on the right will tick up to 1 when Sneha attaches the serial in the next step.

Step 2 — Attach the device serial

Admin portal path 
Administration  →  Branch Connector Devices  →  + Add Device

  Device Type:           ZT-400
  Serial Number:         ZT400-IN-7K2X-9281     (printed on box label)
  Provisioning Template: BPT-LKO-SmartBazaar-North
  Friendly Name:         BC-LKO-Hazratganj-01
  Save
✓Expected output

Device shows up with status Awaiting Provisioning. Will transition to Installed SMEDGE when the box boots, then to Active when DTLS comes up. (If it stalls at Installed SMEDGE — see Common Mistakes.)

Step 3 — Define the Forwarding Profile

The forwarding profile tells the BC which traffic goes to ZIA, which to ZPA, which to bypass. You can have rules for source subnet, app, destination, and time-of-day.

Admin portal path 
Policy  →  Forwarding Control  →  Forwarding Profiles  →  + Add Profile

  Profile Name:    ZTunnel-2.0-Branch
  Tunnel Type:     Tunnel 2.0   (app-aware, dynamic steering)

  Rule 1 — Steer to ZIA
    Source IP:    10.50.0.0/24   (staff laptops VLAN 10)
    Source IP:    10.50.20.0/24  (PoS VLAN 20)
    Destination:  ANY
    Action:       Forward to ZIA

  Rule 2 — Steer to ZPA
    Source IP:    10.50.0.0/24
    Destination:  app.internal.reliance-retail.in (ZPA-segmented)
    Action:       Forward to ZPA

  Rule 3 — Local bypass
    Source IP:    10.50.20.0/24 (PoS)
    Destination:  payments-gateway.razorpay.com
    Action:       Bypass (direct internet)
    Reason:       PCI / latency-sensitive
  Save
💡Pro tip — start with Tunnel 2.0

If you're building a new branch from scratch in 2026, choose Tunnel 2.0 unless you have a specific reason for legacy 1.0 (very old hardware, single-flow throughput needs). 2.0 lets ZIA do app-aware dynamic steering and gives you per-app bypass rules without re-tunneling.

👉 So far: pre-stage template → attach serial → forwarding profile. Three clicks on the admin side. Next, what to do when the cool-looking flow stops cool-looking.

The forwarding-profile decision

This is one of the most common interview questions: "When do you choose Branch Connector versus a GRE tunnel versus IPsec versus Zscaler Client Connector?" Here's the decision tree.

Infographic 3 of 4 — Branch onboarding decision tree
Five-question decision tree starting with branch device type and ending with the recommended forwarding method. Q1: Roaming user, or branch? (Where is the device located today?) Q2: Has existing SD-WAN / router? (Cisco SD-WAN, Versa, Aruba, etc.) Roaming → Zscaler Client Connector (ZCC) No router → Branch Connector (ZT-400/600/800) Has router Q3: Static public IP? (or only NAT'd dynamic?) Static → GRE tunnel (lowest overhead) Dynamic → IPsec tunnel (IKEv2, NAT-T) Override: any IoT / OT / agentless devices on-site? → Branch Connector wins, even if a router exists. Agentless segmentation only it provides.
Decision tree the architect runs in their head. The bottom pink override is the most common 2026 reason to pick BC even when SD-WAN is in place: PCI-scope PoS, IP cameras, building-management sensors.
Hands-on labs to cement these concepts: Subnetting practice Firewall policy sim Packet tracker

Verification — "how do I know it's working?"

Three telemetry views you should know cold for any interview.

View 1 — Admin Console dashboard

Admin portal path 
Dashboard  →  Branch Connectors  →  BC-LKO-Hazratganj-01

  Status:                Active ●
  Service Edge:          mum1.sme.zscalerthree.net  (Mumbai)
  Tunnel:                DTLS  (UDP/443)  established 04m 27s ago
  Throughput (now):      18.3 Mbps in / 4.1 Mbps out
  Sessions (now):        612
  Last config push:      2026-05-24 08:11:42 IST

View 2 — Branch Connector CLI (over serial / SSH)

CLI commands on the BC appliance 
admin@bc-lko-01:~$ show system status
  Hostname:        bc-lko-hazratganj-01
  Serial:          ZT400-IN-7K2X-9281
  TPM Status:      Healthy
  WAN1:            UP   10.10.5.42/24 (DHCP, lease 23h 12m)
  LAN1:            UP   10.50.0.1/24
  Cloud State:     Connected (DTLS to mum1.sme.zscalerthree.net)
  ZTP Stage:       Active
  Uptime:          0d 04h 27m

admin@bc-lko-01:~$ show tunnel status
  Tunnel ID:   1
  Type:        DTLS
  Peer:        mum1.sme.zscalerthree.net (52.66.x.x)
  State:       UP
  RTT:         18 ms
  Pkts in/out: 1,284,901 / 412,338
  Bytes in/out:2.3 GB / 712 MB
  Last error:  -

View 3 — Per-branch insights (logs)

Admin portal path 
Analytics  →  Insights  →  Cloud & Branch Connector  →  Filter:
   Location = LKO-SmartBazaar-Hazratganj
   Time     = Last 1 hour

  → Top apps:        Slack (38%), Office365 (22%), WhatsApp Web (11%)
  → Top blocked:     1 (Pirated streaming - Category: Streaming)
  → Threats stopped: 0
  → DLP events:      0
💡Pro tip — bookmark the Mumbai SME page

For Indian branches, the Mumbai (mum1.sme) and Chennai (maa1.sme) Service Edges are typically the closest. Bookmark trust.zscaler.com — that's where Zscaler posts incidents for every Service Edge. Half of all "BC offline" tickets resolve themselves with a single trust.zscaler.com check.

Common Mistakes — what blows up in production

These are the five fires you'll fight in your first six months. Memorise the symptom-first, not the cause-first — that's how you'll recognise them at 2am.

!Mistake 1 — "Stuck at Installed SMEDGE"

Symptom: Device boots, status flips from Awaiting Provisioning to Installed SMEDGE, then never moves to Active. Sits there for 30+ minutes.

Root cause: Cloud-side service edge can't complete the provisioning handshake. Confirmed by the Zscaler community thread "Branch connectors inactive" — Zscaler periodically posts a global incident when this affects multiple tenants.

Fix: (a) Check trust.zscaler.com for an active incident on your sub-cloud's SME edge. (b) If no incident, open a Sev-2 ticket — include the BC serial, sub-cloud, and the timestamp of the stuck status. Reboot won't help; it's a cloud-side state.

!Mistake 2 — "Branch shows offline, WAN is up"

Symptom: show system status on the BC shows WAN1 UP with a valid DHCP lease. The admin console still shows the BC as Offline. Pings to 8.8.8.8 from the BC work.

Root cause: Branch firewall (often a budget Sophos / SonicWall the store IT installed last month) is blocking outbound UDP/443. DTLS handshake never completes, and TLS fallback also fails if 443/TCP is also blocked or proxied.

Fix: Allow outbound UDP/443 and TCP/443 to the Zscaler sub-cloud IP ranges (publish at config.zscaler.com). Bypass any deep-packet-inspection on those flows — DTLS doesn't play nice with explicit-proxy SSL bumps.

!Mistake 3 — "Wrong forwarding profile attached"

Symptom: BC is Active, but staff laptops with the ZCC agent are double-tunneling — visible as 100% CPU on the BC at ~30 Mbps, with users complaining of high latency on Teams calls.

Root cause: The default forwarding profile is steering laptop subnet (10.50.0.0/24) into the BC tunnel, but those laptops are also running ZCC which has its own tunnel. Two tunnels for the same flow = wasted CPU and double-encryption.

Fix: Add a Bypass rule for the laptop subnet on the BC's forwarding profile — let ZCC handle managed laptops, let BC handle agentless devices.

!Mistake 4 — "PoS terminal can't reach payment gateway"

Symptom: Cashiers report "card declined" or 30-second timeouts on Razorpay/CCAvenue swipes after BC went live.

Root cause: Default forwarding profile is steering PoS subnet into ZIA, which is doing SSL Inspection on payment-gateway certificates. The PoS app is pinned to the gateway's real cert and rejects the Zscaler-issued one.

Fix: Add a forwarding-profile Bypass rule for the PoS subnet → payment-gateway hostnames. Or, in ZIA, add the gateway to the SSL exemption list. PCI compliance often requires the bypass approach anyway.

!Mistake 5 — "TPM serial mismatch"

Symptom: Replacement RMA device arrives, plugged in, status sits at Awaiting Provisioning forever.

Root cause: The new device's TPM serial is different from the one Sneha attached to the template. The cloud sees an "unknown" serial and refuses to provision it to your tenant — by design (that's how cross-tenant theft is prevented).

Fix: Detach the old serial in Branch Connector Devices, attach the new RMA serial to the same template. Provisioning resumes in seconds.

Pro tips from the field

💡Tip 1 — Pre-stage everything before shipping the box

Create the location, the forwarding profile, and the template before the courier moves the appliance. The store manager only has to plug in two cables; if anything else needs to happen on-site, your ZTP promise just broke.

💡Tip 2 — Always order one HA pair for stores > 100 devices

The ZT-400 has no internal redundancy. For any store doing > 100 devices or handling payments, ship two BCs (active + standby) and a small managed switch with two uplinks. The cost delta is < ₹40,000 and saves you the next Diwali outage.

💡Tip 3 — Use the "LAN segmentation" feature for IoT

BC can act as a Layer-3 gateway for multiple LAN segments (VLAN 10 staff, VLAN 20 PoS, VLAN 30 cameras). Combined with ZIA firewall rules, you get east-west microsegmentation without buying a separate NAC product. This is the killer feature versus a plain GRE tunnel.

End-to-end scenario walkthrough — Sneha's Saturday

🎬 Full incident replay — Reliance SMART Bazaar, Hazratganj

Friday 18:00 IST. Sneha pre-stages: location LKO-SmartBazaar-Hazratganj, forwarding profile ZTunnel-2.0-Branch with three rules (staff → ZIA, PoS → ZIA + bypass for Razorpay, IoT cameras → ZIA + block egress to anything except DVR cloud). Attaches device serial ZT400-IN-7K2X-9281 to template BPT-LKO-SmartBazaar-North. Courier picks up the BC at 18:30.

Saturday 07:55 IST. Store manager Mr. Verma calls Sneha: "Madam, dabba aa gaya, kya karu?" Sneha: "WAN cable lagao, power on karo." 08:00 device powered.

08:02. Sneha sees Installed SMEDGE in the console. 08:03 → Active. Green dot. DTLS up to mum1.sme.zscalerthree.net, RTT 22 ms.

08:07. First cashier swipes a test card. Bypass rule sends it direct to Razorpay — 1.2-second auth. ✅ Pass.

08:10. IP cameras come online, traffic flows through ZIA with a firewall rule that allows only the camera-DVR cloud destinations. Anything else gets blocked at the Service Edge. ✅ Microsegmentation in action.

09:00. Store opens. By the time Mr. Verma sells the first sari, every flow in the store is being inspected by ZIA — and Sneha is back home eating breakfast.

The user journey — what you actually do

Infographic 4 of 4 — Sneha's onboarding timeline (Friday → Saturday)
Five-event timeline from pre-staging on Friday evening to traffic flowing on Saturday morning. 1 Fri 18:00 Pre-stage template + serial 2 Fri 18:30 Courier ships box to Lucknow 3 Sat 08:00 Mr Verma plugs in 4 Sat 08:03 DTLS up, status Active 5 Sat 09:00 Store opens, all traffic inspected Total time on-site: under 5 minutes. Total CLI on-site: zero.
The whole point: shift the work from on-site IT to a cloud-driven, pre-staged template. The store opens on time even if the technician misses the train to Lucknow.

Glossary — the words you'll hear on every Zscaler call

TPM 2.0
Trusted Platform Module v2.0 — a tamper-resistant chip that stores cryptographic identity bound to the device serial at manufacture. The foundation of Zscaler's zero-touch trust model.
ZTP (Zero Touch Provisioning)
The flow where a device, on first boot, auto-registers to the right cloud tenant without any technician CLI. Branch Connector and Cloud Connector both use ZTP.
DTLS
Datagram TLS — TLS encryption running over UDP instead of TCP. Lower latency, no TCP retransmission stalls. Branch Connector's default tunnel protocol (UDP/443).
Service Edge (formerly ZEN)
A Zscaler datacentre POP that terminates tunnels, inspects traffic, and enforces policy. SME = Service Edge Mumbai, MAA1 = Chennai, etc.
Forwarding Profile
The set of rules on the BC that decides which traffic goes to ZIA, ZPA, or bypasses directly to the internet. Supports source/destination/app/time-of-day matches.
Z-tunnel 1.0 vs Tunnel 2.0
Two generations of Zscaler's forwarding tunnel. 1.0 = simple HTTP CONNECT-based. 2.0 = app-aware, dynamic steering. Default for new builds = 2.0.
SMEDGE
Service-Mediated Edge — the intermediate provisioning state a BC passes through after install. If it stays here too long, something is wrong on the cloud side.
ZTE (Zero Trust Exchange)
Zscaler's umbrella term for its global fabric of Service Edges — the "cloud" in "cloud security".

📋 Quick reference — print this before your interview

Sources cited:
  1. Zscaler Help — What Is Zscaler Branch Connector? (help.zscaler.com/cloud-branch-connector/what-zscaler-branch-connector)
  2. Zscaler Help — Cloud & Branch Connector Troubleshooting (help.zscaler.com/cloud-branch-connector/troubleshooting)
  3. Zscaler Help — Branch Connector Reference Architecture (help.zscaler.com/cloud-branch-connector/reference-architecture)
  4. Zscaler Community — Branch connectors inactive thread (community.zscaler.com/s/question/0D5PJ00000pQS8S0AW)
  5. Zscaler Trust — Security advisories & the Feb 12, 2026 release (CVE-2026-22568 / CVE-2026-22569) (trust.zscaler.com)
  6. Zscaler Blog — Introducing Zero Touch Branch Connectivity (zscaler.com/blogs/product-insights/introducing-zero-touch-branch-connectivity)
  7. Avantec technical update 2024–25 — third-party SE deep dives

📝 Check your understanding

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

Q1

What is the default tunnel protocol and port a Zscaler Branch Connector uses to reach the ZIA Service Edge?

Correct: A. Branch Connector defaults to DTLS over UDP/443 — TLS-grade encryption with UDP's low latency. If UDP/443 outbound is blocked, it falls back to TLS over TCP/443. GRE and IPsec are the legacy options BC replaces. QUIC is not used by BC.
Q2

Sneha at Reliance Retail is opening a new SMART Bazaar in Hazratganj with 15 PoS terminals, 8 IP cameras, 1 printer, and 6 staff laptops. The only person on-site is the store manager, who has never seen a CLI. The store opens Saturday at 09:00. Best onboarding choice?

Correct: C. ZT-400 is sized exactly for this profile (200 Mbps, 30 devices), supports agentless IoT/OT (cameras and printers can't run ZCC — eliminates B), needs no on-site CLI (eliminates A), and avoids MPLS latency (eliminates D). The TPM-based ZTP is purpose-built for this scenario.
Q3

A mid-size HDFC warehouse already has a Cisco Catalyst SD-WAN router terminating the WAN, the public IP is static, and there are no IoT devices to onboard. Best forwarding method to ZIA?

Correct: B. Zscaler explicitly recommends GRE from fixed locations with a static public IP — it has the least overhead (no encryption headers, no IKE rekey). IPsec is the right choice when the public IP is dynamic, but here it's static (D is wrong). BC is overkill when an SD-WAN edge is already in place and there's no agentless device need (A wastes hardware). PAC files don't cover non-browser traffic (C).
Q4

Rahul at Flipkart needs to deploy a Branch Connector inside an Azure VNet for a virtual branch hosting their seller-dashboard servers in Mumbai. Which deployment option is correct?

Correct: D. Zscaler publishes official VM images for VMware, KVM, Hyper-V, AWS, Azure, and GCP — Azure's is in the Marketplace. Hardware shipped to a public-cloud DC is absurd (A). BC is not container-packaged (B). Side-loading the hardware ISO is unsupported and will fail TPM checks because the cloud VM has no physical TPM (C — the VM image uses a software-bound identity instead).
Q5

Sneha's newly-shipped BC has been stuck at Installed SMEDGE status for 45 minutes. The store manager confirmed the device boots up and WAN1 LED is green. Ping from the BC CLI to 8.8.8.8 works. What's the right next step?

Correct: A. SMEDGE-stuck is a cloud-side provisioning failure — the device has nothing to do; the Service Edge needs to complete the handshake on its side. Zscaler periodically posts global incidents for this on trust.zscaler.com. Reboot is harmless but won't help (B). "Cold reattach" is not a documented fix (C). USB reflash is for total-bricks, not for state transitions (D).
Q6

A BC at an L&T factory in Pune shows Offline in the admin console. show system status on the BC reports WAN1 UP with a DHCP lease, and pings to 8.8.8.8 succeed. First diagnosis step?

Correct: B. ICMP works but DTLS uses UDP/443 — many branch firewalls (Sophos / SonicWall / FortiGate at small sites) block non-standard UDP traffic by default. This is the single most common "BC offline but internet works" cause. A is premature escalation. C is layer-1 paranoia when symptoms clearly point higher. D is destructive.
Q7

After upgrading BC firmware, staff laptops behind a BC at TCS Mumbai report 30% slower Office 365 + Teams performance. The BC's CPU is 92%. The forwarding profile is set to Tunnel 1.0 for all subnets. Which feature should you tune?

Correct: C. Tunnel 1.0 forces every flow through the same encapsulation, and laptops running ZCC are double-tunneling — that's the CPU spike + latency. Tunnel 2.0 + a Bypass for the managed-laptop subnet removes the double-tunnel and lets ZIA do app-aware optimisation. A is throwing money at a config problem. B disables security. D will break PMTU on the internet path (jumbo frames are not internet-safe).
Q8

A BC at an AIIMS Hospital in Delhi works perfectly for staff laptops, but the production-floor PLC controller (10.50.30.5) cannot reach its vendor cloud — symptom: TCP RST returned within 1 second of any outbound connection. Most likely cause?

Correct: D. Forwarding profiles have an implicit deny: any traffic that doesn't match a rule is dropped. The text says only camera traffic is allowed for VLAN 30 — that's correct microsegmentation but it breaks the PLC's vendor-cloud access. Fix: add a specific rule allowing the PLC to reach its vendor cloud hostnames. A is similar but states "no rule at all" — the scenario describes a partial rule which is actually worse (the segmentation is doing its job too aggressively). B is fictional; ZIA doesn't sandbox PLC protocols by default. C: PLCs don't speak DTLS — the BC does; the PLC just sends regular TCP/UDP.
Q9

A 200-store retailer needs a 60% OPEX reduction versus their current branch stack (SD-WAN router + on-prem UTM firewall + per-site CCNP-engineer truck-roll for changes). Which Zscaler-based architecture would you recommend?

Correct: B. The OPEX win for BC isn't the appliance cost — it's eliminating the truck roll. Cloud-managed policy changes from a central console means a single engineer can push to 200 stores in 30 seconds. A still requires UTM hardware refresh and ignores IoT (PCI risk). C keeps every OPEX line you wanted to cut. D destroys WAN economics and latency. Zero Trust Branch is the published Zscaler reference architecture for exactly this scenario.
Q10

Priya at Apollo Hospital needs to connect a 12-year-old MRI machine (no agent possible, vendor pinned firmware) and modern nurses' laptops to ZIA, while preventing the MRI from being reachable from the nurses' VLAN — east-west microsegmentation is mandatory for HIPAA-like compliance. Best architecture?

Correct: C. The architecture you want is published as "Zero Trust Branch": BC handles north-south (MRI → vendor cloud), ZCC handles laptops, and Zscaler device segmentation handles east-west (MRI ↔ nurse VLAN) without needing a separate on-prem firewall or NAC product. A leaves you maintaining a legacy firewall — the OPEX you're trying to kill. B violates the segmentation requirement entirely. D is operationally absurd in a 2026 hospital.
Lesson complete — saved to your profile.
Almost! Review the sections above and try again — you need 70% (7 of 10) to mark this lesson complete.

What's next?

You've nailed the on-premise side of Zscaler's zero-touch story. Now flip the script: how do you forward traffic from cloud workloads (AWS / Azure / GCP) to ZIA without a Branch Connector? That's the Cloud Connector lesson — same TPM-style trust, very different deployment pattern.

Cloud Connector deep-dive → Practice on exam.techclick.in