Zero Trust Architecture and the Zscaler Zero Trust Exchange
From perimeter to identity-defined boundary
Zero Trust replaces the assumption that inside the network equals trusted with continuous verification of user, device, and application context on every request. Name the design principles explicitly: verify explicitly, grant least privilege, assume breach. In Zscaler's model these map to an inline, cloud-delivered enforcement fabric - the Zero Trust Exchange - rather than appliances stacked in a data center.
What the Exchange is made of
Know the service names and what each does: ZIA for internet and SaaS security, ZPA for private application access, ZDX for experience monitoring, plus workload-to-workload and branch connectivity services. Architecturally, traffic is steered to the nearest Zscaler Enforcement Node (ZEN), inspected once in a single pass, and forwarded. The control plane (admin portal, policy distribution, logging) is logically separate from the data plane (the ZENs that process packets) - a favourite exam distinction.
Traps
- 'Zero Trust means no firewalls.' Wrong: trust is no longer implied by network location, but segmentation and inspection still exist.
- Confusing ZPA with a VPN. VPNs place a device on the network; ZPA brokers per-application tunnels and connectors make outbound-only connections.
- Assuming all traffic is content-inspected by ZIA. ZPA application traffic is brokered, not inspected.
- Believing Zero Trust requires on-premises hardware. It is cloud-delivered; appliances only forward traffic.
Rule of thumb
If an answer's fix is 'add a VPN concentrator, a DMZ segment, or a backhaul to HQ,' it is probably the pre-Zero-Trust distractor. The Zero Trust answer moves enforcement closer to the user and narrows access to the specific resource.