Within the ZIA Cloud Firewall and broader Zscaler Internet Access architecture, Public Service Edges (PSEs) are the core policy enforcement points. User traffic is steered (via tunnels, PAC files, or agents) to the nearest PSE, where Zscaler performs security inspection and policy evaluation. At this point, the Cloud Firewall, URL filtering, SSL inspection, IPS, sandboxing, and other security engines are applied according to the user's identity, group, location, and defined policies.
Although the PSEs naturally participate in traffic distribution across the global Zscaler cloud, their primary purpose is not generic load balancing or network transit; rather, they host the full security stack and make real- time allow/deny/log decisions. They also enforce bandwidth controls, application rules, and advanced threat protections before forwarding allowed traffic to the internet.
They are not responsible for managing endpoint security updates or providing general cloud storage. Instead, they serve as inline security gateways that enforce Zero Trust access and granular firewall rules at scale.
Therefore, the correct description of their role in the Cloud Firewall architecture is that they act as key policy enforcement engines.

The ZDTE study content groups Private Service Edge under Advanced Platform Services, explaining that PSEs host the same Zero Trust Exchange policy and inspection engines, but run as customer-managed service edges inside data centers or large offices. They are designed to give on-premises users a "local on-ramp" to ZIA and ZPA services while still enforcing full zero-trust policy.
The documentation emphasizes that PSEs do not replace App Connectors for ZPA; connectors are still required to establish inside-out application connectivity. Nor do PSEs remove the need for ZTNA policies- those policies remain central and are simply enforced closer to the user. Encryption is also preserved end-to- end; there is no "unencrypted fast path" described in the reference architecture.
Instead, the primary benefit highlighted is performance and user experience: by enforcing ZIA/ZPA policies at a local PSE rather than a distant public service edge, organizations reduce round-trip latency and keep traffic on optimal paths while maintaining identical security and access controls.

Zscaler design guidance for GRE connectivity emphasizes three key principles: terminate GRE on border (edge) devices, avoid NAT on GRE source addresses, and scale bandwidth by using multiple tunnels. In Zscaler documentation and engineering training, each GRE tunnel is typically sized for up to about 1 Gbps of throughput. For a 2 Gbps requirement, customers are advised to deploy at least two primary GRE tunnels, with two additional backup tunnels for redundancy and failover.
These tunnels should terminate on border routers that own public IP addresses, ensuring optimal routing and simplifying troubleshooting. Zscaler specifically recommends that the public source IPs used for GRE must not be translated by NAT, because the Zscaler cloud must see the original, registered public IP to associate tunnels with the correct organization and enforce policy. Enabling NAT on GRE traffic can break tunnel establishment and lead to asymmetric or unpredictable routing.
Using internal routers introduces extra hops and complexity and often requires NAT or policy-based routing, which goes against recommended best practices. Similarly, any architecture with NAT enabled on GRE traffic conflicts with Zscaler's published requirements. Therefore, the ideal and recommended design for 2 Gbps via GRE is two primary and two backup GRE tunnels from border routers with NAT disabled.

In a typical enterprise authentication setup, Zscaler functions as the Service Provider (SP) within the SAML authentication framework. This aligns with Zscaler's architectural principle that identity verification is delegated to an external authoritative Identity Provider (IdP) such as Azure AD, Okta, Ping, or ADFS. Zscaler does not authenticate user credentials directly. Instead, it relies on the IdP to validate the user and then deliver a signed SAML assertion back to Zscaler.
When a user attempts to access the Zscaler service, the authentication request is redirected to the enterprise IdP. The IdP performs credential verification and returns a SAML assertion containing the authenticated user identity and associated attributes. Zscaler, acting as the SP, consumes and validates this assertion, then maps the identity to its internal user records or SCIM-synchronized directory objects. This identity becomes the basis for all ZIA/ZPA policy evaluation, including URL filtering, CASB controls, DLP policies, firewall rules, and access-control enforcement.
Since Zscaler depends on the IdP for primary identity verification and only consumes assertions, Zscaler's role is clearly defined as the Service Provider in a standard authentication configuration.

Zscaler OneAPI provides a unified, programmatic interface to automate configuration and operations across the Zscaler platform, including ZIA, ZPA, and Zscaler Client Connector. Zscaler's OneAPI documentation clearly states that OneAPI uses the OAuth 2.0 authorization framework to secure access to these APIs.
In practice, administrators or automation platforms register an API client in ZIdentity, obtain OAuth 2.0 access tokens, and then use those tokens to call OneAPI endpoints. The use of OAuth 2.0 ensures standardized flows for client authentication, token issuance, and scope-based authorization, aligning with modern security best practices and making it easier to control and audit API access. Zscaler also highlights OAuth 2.0 as one of the three architectural pillars of OneAPI, along with a common endpoint and tight integration with ZIdentity.
While JSON Web Tokens (JWTs) can be used as a token format inside OAuth 2.0, they are not, by themselves, the authorization framework. SAML is typically used for browser-based SSO, not for securing REST APIs in this context. API Keys are simpler credential schemes and are not what Zscaler prescribes for OneAPI. As a result, OAuth 2.0 is the correct and exam-relevant answer.