ZDTA common mistakes
ZDTA · Understand the traps and how to avoid them.
When a scenario asks how to give a remote contractor access to one internal application, the candidate answers with ZIA URL filtering, a Cloud Firewall rule, or an IPsec/VPN tunnel instead of a ZPA application segment plus an access policy.
ZIA and ZPA live in the same console and both expose 'policy' screens, so candidates memorise feature lists rather than which traffic path each product owns (internet/SaaS-bound vs. private-app-bound).
What to do instead
Classify every scenario by destination first: internet and SaaS traffic = ZIA, private application traffic = ZPA, endpoint experience = ZDX. Only after that choice, apply the Zero Trust mechanics (per-application access, identity + posture, no inbound exposure) to the selected path.
The candidate defines Zero Trust as 'trust nothing, so block everything' and then cannot answer items about least privilege, assume-breach, or why inline inspection of allowed traffic is still required.
Slogan-level recall of 'never trust, always verify' without the operational corollaries that the exam actually tests.
What to do instead
Learn Zero Trust as three operational moves and map products onto them: remove implicit trust (verify identity and device posture on each request), enforce least privilege (per-application, not per-network), assume breach (inspect even allowed traffic inline and log it). Then state which move each product implements.
The candidate assumes the most restrictive rule wins, or that a Block in one policy type (URL Filtering, Cloud App Control) automatically overrides an Allow in another policy type (Cloud Firewall, SSL Inspection).
Habit from firewall ACLs, where deny-any or numeric priorities dominate; ZIA instead evaluates each policy type as its own ordered list.
What to do instead
Memorise that each policy type is evaluated top-down with first-match-wins inside its own layer, and that layers chain (SSL Inspection decides whether content is decrypted before URL Filtering, Cloud App Control, and DLP can see it). Design rules so the intended outcome is explicit within each layer rather than relying on cross-policy precedence.
On SSL inspection items the candidate puts the Zscaler certificate on the ZIA cloud, or assumes HTTPS is decrypted by default so DLP and Cloud App Control always see payload content.
The certificate direction is easy to invert, and inspection is opt-in per SSL Inspection rule rather than a global default.
What to do instead
State the man-in-the-middle direction explicitly: ZIA presents a certificate signed by the Zscaler root CA to the endpoint, so the Zscaler root CA must be trusted on endpoints/browsers. Inspection happens only where an SSL Inspection rule matches; DLP, content-level URL filtering, and Cloud App Control only inspect plaintext inside inspected traffic.
The candidate claims App Connectors need a public IP, a DNS record, or inbound firewall openings so remote users can reach internal applications.
The VPN-concentrator mental model (inbound listener in a DMZ) carries over, while outbound-only connectivity is exactly the design point being tested.
What to do instead
Describe the flow as outbound-only: the App Connector initiates outbound TLS (443) to the ZPA Public Service Edge, and the endpoint's Client Connector connects to the same cloud, which brokers the inside leg. No inbound ports, no published DNS, no DMZ.
The candidate treats an application segment as a subnet/IP-range rule, places 'segmentation' in ZIA Cloud Firewall, or claims ZPA performs URL filtering and content inspection.
Network-centric segmentation habits conflict with ZPA's application-centric model, and both products are described as 'policy engines'.
What to do instead
Define segments by FQDN plus ports/protocols (IP-based definitions only where FQDN is impossible), group them into segment groups, and scope access policies to user/group plus device posture. ZPA brokers connections only; URL filtering, Cloud App Control, and DLP remain ZIA functions.
The candidate assumes ZDX ingests ZIA logs or needs a separate agent or packet capture installed, and treats the ZDX score as a security or allow/block verdict.
ZDX shares the console and the Client Connector with ZIA, so telemetry collection and policy enforcement get merged in the candidate's head.
What to do instead
State that ZDX telemetry comes from the Client Connector on endpoints plus synthetic probes from the Zscaler cloud, and that it reports hop-by-hop metrics (DNS, TCP, SSL, server response, page response) rolled into a user-experience score. It diagnoses experience; it does not block. Use ZIA/ZPA logs for enforcement questions and ZDX for 'why is it slow'.
The candidate assumes Client Connector always tunnels traffic, or that ZCC always sends traffic to ZIA regardless of configuration.
Default install behaviour is confused with policy-driven behaviour, and forwarding-profile precedence is fine print.
What to do instead
Recall that forwarding profiles (tunnel with ZIA, tunnel with ZPA, PAC-based, none) are assigned to users/groups/devices and evaluated by priority, and that the assigned profile decides what gets tunnelled; a PAC file only affects web-proxy traffic and never tunnels non-web protocols.
The candidate configures a location with a forwarding method or source IP that does not match reality, and then expects user-level policy to work over a GRE/IPsec tunnel without any identity mechanism.
Location-based forwarding is the common office deployment, and candidates forget that the location only identifies the site, not the user.
What to do instead
Match location configuration to the actual forwarding method (GRE, IPsec, PAC, Client Connector) and verify source IPs/NAT. For user-level policy, require identity to be forwarded by Client Connector or SAML/SCIM, with Surrogate IP as the fallback for non-Client-Connector devices.
The candidate expects real-time, indefinitely retained reporting inside the admin console, or answers a 'who changed this rule and when' question with a traffic report.
Log streaming, near-real-time logs, aggregated reports, and audit logs are conflated because they all appear under 'reporting'.
What to do instead
Separate the data sources: near-real-time logs and Nanolog streaming to SIEM for investigations, dashboards/reports for trends with aggregation delay and finite retention, and audit logs for configuration changes. Pair that with RBAC-scoped admin roles instead of sharing a super admin account.