Free ZDTA Practice Test Questions 2026

Explanation:

This question tests knowledge of Trusted Network Detection in Zscaler Client Connector. It helps determine if a device is on a corporate network to apply the appropriate forwarding profile, such as bypassing the Zscaler tunnel on trusted networks.

✅ Correct Option:

Option D:
DNS Search Domain, DNS Server, Hostname Resolution fits because Zscaler Client Connector uses these exact conditions. DNS Server verifies corporate DNS servers, DNS Search Domain checks primary domains on the active adapter, and Hostname Resolution matches expected IPs. These are the supported criteria, with static DNS options recommended for reliability.

❌ Incorrect options:

Option A:
Hostname Resolution, Network Adapter IP, Default Gateway does not satisfy the requirement. Default Gateway and Network Adapter IP are not standard conditions for Trusted Network Detection.

Option B:
DNS Servers, DNS Search Domain, Network Adapter IP does not satisfy the requirement. While it includes valid DNS elements, Network Adapter IP is not a supported condition.

Option C:
Hostname Resolution, DNS Servers, Geo Location does not satisfy the requirement. Geo Location is not used for Trusted Network Detection in Zscaler Client Connector.

🔧 Reference:
→ Configuring Trusted Networks for Zscaler Client Connector
Confirms the supported conditions: DNS Server, DNS Search Domains, and Hostname & IP.

Explanation:

This question tests your knowledge of the Botnet Protection features provided within Zscaler Internet Access (ZIA) under the Advanced Threat Protection (ATP) policy. It evaluates your ability to identify the precise technical mechanisms used by the platform to monitor, detect, and block malicious command-and-control communication channels.

✅ Correct Option:

B. Connections to known C&C servers, Command traffic (sending / receiving), Unknown C&C using AI/ML
The Advanced Threat Protection policy explicitly categorizes its Botnet Protection suite into three core layers. This architecture checks outbound requests against signature-based feeds of established Command & Control servers, evaluates raw command-and-control behavior (sending/receiving actions) to unclassified destinations, and deploys inline AI/ML models to catch heuristic variations or domain generation algorithms (DGA) used by unknown threat actors.

❌ Incorrect options:

A. Malicious file downloads, Command traffic (sending / receiving), Data exfiltration
Malicious file downloads are handled separately by the cloud-native Sandbox and Anti-Virus engines rather than the specialized Botnet configuration. Furthermore, Data exfiltration rules are managed under the Data Loss Prevention (DLP) policy framework, making this combination inaccurate for ATP botnet protection definitions.

C. Connections to known C&C servers, Detection of phishing sites, Access to spam sites
Detection of phishing sites and access to spam websites are distinct security boundaries within the Zscaler platform. While phishing detection can utilize ATP's AI capabilities, general site access control and classification for spam are fundamentally governed under URL Filtering and standard Anti-Phishing policies instead of the Botnet sub-category.

D. Vulnerabilities in web server applications, Unknown C&C using AI/ML, Vulnerable ActiveX controls
Vulnerabilities in web server applications and vulnerable ActiveX controls fall under the jurisdiction of Malicious Active Content Protection and the Intrusion Prevention System (IPS) Control policies. They do not represent components of the core Botnet Protection criteria designed specifically to disrupt communication with bot nodes.

🔧 Reference:
→ Zscaler Help Portal: Configuring the Advanced Threat Protection Policy outlines the specific configuration features under the Botnet Protection section, confirming options for Command & Control Servers, Command & Control Traffic, and AI-driven DGA domain blocks.

Explanation:

This question tests your understanding of deployment best practices for Zscaler Client Connector when location-based tunnels (GRE or IPSEC) are already in place. The goal is to avoid routing traffic through multiple tunnels, which can cause performance issues. The recommended combination is to disable the Client Connector tunnel when users are on the trusted corporate network and enable Z-Tunnel 2.0 when they are off the trusted network.

✔️ Correct Option:

C. None for on-trusted and tunnel v2.0 for off-trusted
When GRE or IPSEC tunnels are configured from locations, setting the forwarding profile to "None" for on-trusted networks prevents traffic from being double-encapsulated. This avoids performance degradation, as the existing location tunnel already handles traffic . For off-trusted networks, Z-Tunnel 2.0 provides optimal forwarding directly to the Zscaler cloud.

❌ Incorrect Options:

A. Tunnel v2.0 for on-trusted and tunnel v2.0 for off-trusted
This would cause traffic from trusted networks to be tunneled twice—first through the Zscaler Client Connector, then again through the location's GRE/IPSec tunnel—leading to unnecessary overhead and latency.

B. None for on-trusted and none for off-trusted
This would leave off-trusted users without any traffic forwarding to Zscaler, breaking security inspection for remote users, as the Client Connector would not tunnel their traffic.

D. Tunnel v2.0 for on-trusted and none for off-trusted
This is functionally backwards. Off-trusted users would have no forwarding method, while on-trusted users would suffer from double-tunneling. This contradicts Zscaler best practices for remote user security.

🔧 Reference:
→ Zscaler Reference Architecture: Secure Mobile Access with ZCC - Explicitly lists "On Trusted Network: None" and "Off Trusted Network: Tunnel" as the recommended profile action for ZIA.

→ Zscaler Help: About Forwarding Profiles - Explains network environments and default forwarding profile actions.

Explanation:


Zscaler Identity Threat Detection and Response (ITDR) gathers information about Active Directory (AD) environments to detect identity-related threats and security risks. It uses directory-based communication to collect details about users, groups, computers, and domain configurations without relying on network traffic analysis.

🟢 Correct Option: B. Running LDAP queries
Zscaler ITDR uses Lightweight Directory Access Protocol (LDAP) queries to securely retrieve information from Active Directory domains. Through LDAP, it collects details about users, groups, domain controllers, and security configurations required for identity threat analysis. This approach provides accurate visibility into the AD environment while supporting continuous monitoring and risk assessment.

🔴 Option A: Scanning network ports
This option is incorrect because port scanning is a network discovery technique used to identify open services on devices. Zscaler ITDR does not rely on port scanning to gather Active Directory information, as AD data is accessed directly through LDAP queries instead.

🔴 Option C: Analyzing firewall logs
This option is incorrect because firewall logs provide information about network traffic and security events rather than directory objects. Zscaler ITDR requires detailed Active Directory data, which cannot be obtained by analyzing firewall logs alone.

🔴 Option D: Packet sniffing
This option is incorrect because packet sniffing captures and analyzes network traffic but does not provide structured information about Active Directory users, groups, or domain configurations. Zscaler ITDR retrieves this information through authenticated LDAP communication instead of monitoring network packets.

🔧 Reference:
⇒ Zscaler Help – About Zscaler Identity Threat Detection and Response – Explains how Zscaler ITDR collects and analyzes identity information from Active Directory environments.

⇒ Zscaler Help – Configure LDAP Data Source – Describes how LDAP is used to connect to Active Directory and retrieve domain information for identity threat detection.

Explanation:

This question tests understanding of what XSS attacks actually accomplish once malicious scripts execute in a victim's browser. XSS is a client-side injection technique, and its real-world impact is measured by what an attacker can extract or manipulate through the browser session — not by network evasion or anonymization methods.

✅ C. Cookie Stealing
Cookie Stealing is a direct and well-documented outcome of XSS attacks. When malicious scripts execute within a trusted site's context, they gain access to the browser's document object, including session cookies. Attackers use this injected script to send cookies to an external server, enabling session hijacking. This is precisely why XSS is dangerous — it exploits the trust a browser places in a legitimate domain, letting attackers steal authentication tokens without needing credentials, making cookie theft one of the most common and impactful XSS payloads.

❌ A. Spyware Callback
This refers to spyware communicating with a remote command server after infection, which is a malware behavior rather than a script-injection technique. XSS operates within a browser session using legitimate site trust, not through installed spyware components performing periodic callbacks to attacker infrastructure.

❌ B. Anonymizers
Anonymizers are tools or services used to mask a user's identity or location while browsing, typically for privacy or bypassing restrictions. This is unrelated to script injection vulnerabilities; XSS exploits trust boundaries in web applications, not anonymization or proxy-based traffic routing techniques.

❌ D. IRC Tunneling
IRC tunneling involves routing command-and-control traffic through Internet Relay Chat channels, commonly seen in botnet communications. It is a network-layer evasion technique used by malware, not a consequence of client-side script injection like XSS, which targets browser sessions directly.

🔧 Reference:
→ Zscaler Advanced Threat Protection – XSS & Cookie Stealing — confirms that XSS attacks occur when a threat actor uses a web app to send malicious code to a different end user, and that cookie stealing occurs when bad actors harvest session cookies to gain access to sensitive data.

Explanation:

This question tests knowledge of data privacy considerations for enabling TLS/SSL inspection in Zscaler Internet Access (ZIA). Inspection involves decrypting traffic, so privacy agreements are critical.

✅ Correct Option:

Option D:
Zscaler Data Processing Agreement fits because when you subscribe to ZIA, you enter into this agreement. It defines Zscaler’s role as a data processor, details what data is accessed during inspection, and outlines how it is handled to support compliance with privacy regulations like GDPR.

❌ Incorrect options:

Option A:
Zscaler Compliance Policy does not satisfy the requirement. It is not the specific agreement entered into upon ZIA subscription for TLS/SSL inspection privacy.

Option B:
Zscaler Privacy Policy does not satisfy the requirement. While it provides general information on data practices, the binding agreement for processing during inspection is the DPA.

Option C:
Acceptable Use Policy does not satisfy the requirement. It governs user behavior and content rules, not data processing or privacy for TLS/SSL inspection.

🔧 Reference:
→ TLS/SSL Inspection with Zscaler Internet Access
Confirms that upon subscribing to ZIA, you enter into the Zscaler Data Processing Agreement (DPA) for data privacy related to inspection.

Explanation:

This question tests your understanding of Zscaler's secure web access solutions for untrusted content. The core challenge is balancing user access to a wide variety of untrusted URLs with robust security. Browser Isolation addresses this by executing all web content in a remote, air-gapped cloud container, preventing any active threats from reaching the user's endpoint.

✔️ Correct Option:

A. Browser Isolation
Cloud Browser Isolation detonates web content and isolates zero-day threats in a remote, air-gapped container. It streams a safe, graphical representation to the user's browser without active content, scripts, or code, effectively rendering any URL safe to visit regardless of its trustworthiness . With Turbo Mode, it delivers a native-like user experience with up to 50 frames-per-second, ensuring productivity isn't sacrificed for security .

❌ Incorrect Options:

B. App Connector
App Connector is a lightweight VM deployed in a data center to connect users to private internal applications via Zscaler Private Access (ZPA) . It does not handle internet traffic or secure access to untrusted public URLs.

C. Zscaler Private Access
ZPA is designed to provide secure access to internal, private applications, not to enable safe browsing of untrusted public internet URLs . It is a VPN alternative, not a web security tool for public content .

D. Zscaler Client Connector
While the Client Connector forwards internet traffic to Zscaler for inspection via ZIA, it doesn't by itself render untrusted URLs safe. It typically enables access to private apps via ZPA and is not the specific safe browsing feature for untrusted public websites . The security comes from ZIA policies, not the connector itself.

🔧 Reference:
→ Zscaler Blog: Strengthen your enterprise security posture with Cloud Browser Isolation - Confirms Cloud Browser Isolation detonates web content and isolates threats in an air-gapped container.

→ Zscaler Blog: Productivity and Security On Any Device - Details how Turbo Mode in Browser Isolation provides a near-native web experience while maintaining security.

Explanation:

This question tests your understanding of the security exception scope within Zscaler Internet Access (ZIA). Specifically, it checks your knowledge of how an administrative allowlist configured under the Advanced Threat Protection (ATP) policy propagates horizontally across other Zscaler threat prevention engines.

✅ Correct Option:

A. Sandbox
When an administrator adds URLs to the "Do Not Scan Content from these URLs" list within the Security Exceptions tab of the Advanced Threat Protection policy, this specific allowlist dynamically propagates to both the Malware Protection and Sandbox policies. This centralized administrative design ensures that trusted partner domains bypass advanced scanning and dynamic behavioral sandbox analysis simultaneously, minimizing latency without requiring redundant exception lists across each individual security policy page.

❌ Incorrect options:

B. URL Filtering
URL Filtering is managed under an entirely separate policy layer that controls internet access based on website categorization and corporate usage compliance. Security exceptions created under ATP do not automatically permit access through URL Filtering; to allowlist a site there, administrators must explicitly define a custom URL category and pair it with a dedicated high-priority URL Filtering allow rule.

C. File Type Control
File Type Control governs the transmission of specific document types, extensions, or multi-media formats across web sessions. ATP security exceptions only exempt underlying sites from malicious behavioral or signature scanning engines, meaning any separate configurations or restrictions enforced by the File Type Control policy will remain fully active regardless of ATP allowlist status.

D. IPS Control
IPS Control provides structural protocol-level inspections and guards against network-layer vulnerabilities or unexpected traffic behaviors. While ATP rules are evaluated prior to IPS rules in the core Zscaler traffic enforcement order, adding a web address to the ATP security exceptions list does not carry over to or automatically alter the localized rule signatures of the Intrusion Prevention System framework.

🔧 Reference:
→ Zscaler Help Portal: Configuring Security Exceptions for the Advanced Threat Protection Policy explicitly states that the ATP security exceptions allowlist also automatically applies to the Malware Protection and Sandbox policies.

Explanation:

Zscaler offers both URL Filtering and Cloud Application policies to control user access to web resources. While URL Filtering works with website URLs and categories, Cloud Application policies provide more granular control over SaaS applications by recognizing the application itself and the actions users perform within it.

🟢 Correct Option: A. Cloud Application policies provide better access control.
Cloud Application policies provide deeper visibility and control than URL Filtering because they identify cloud applications instead of relying only on URLs. Administrators can allow, block, or control specific applications and user activities based on application attributes, user identity, and risk. This granular approach makes Cloud Application policies the preferred option when managing access to SaaS and cloud services.

🔴 Option B: URL filtering policies provide better access control.
This option is incorrect because URL Filtering primarily evaluates websites based on URLs and predefined categories. It cannot provide the same level of application-aware control or activity-based enforcement available through Cloud Application policies.

🔴 Option C: Wherever possible URL policies are recommended.
This option is incorrect because Zscaler recommends using Cloud Application policies when controlling access to cloud applications. URL Filtering remains useful for general web browsing but is not the preferred method for managing SaaS application access.

🔴 Option D: Both provide the same filtering capabilities.
This option is incorrect because the two policy types serve different purposes. URL Filtering focuses on website access, while Cloud Application policies provide application-aware controls with more granular visibility and enforcement for cloud services.

🔧 Reference:
⇒ Zscaler Help – About Cloud Application Control – Explains how Cloud Application policies provide granular, application-aware access control for SaaS applications.

⇒ Zscaler Help – About URL Filtering Policies – Describes how URL Filtering policies control access based on URLs and web categories, highlighting their role compared to Cloud Application policies.

Explanation

This question tests your understanding of the reconnaissance and planning phase of a cyber attack. In that phase, attackers identify what systems, services, and entry points they can target, which is commonly referred to the “attack surface.”

✔️ Correct Option: Find Attack Surface
Finding the attack surface is a core step in the reconnaissance phase of a cyber attack. Attackers scan for Internet-facing services, open ports, vulnerable applications, and exposed interfaces to identify where they can initiate an intrusion. This aligns with standard attack lifecycle models (e.g., reconnaissance, initial compromise, command & control, lateral movement) where the first action is mapping and understanding the target’s attack surface.

❌ Incorrect Option: Find Cash Safe
“Find Cash Safe” describes a physical theft scenario, not a standard step in a cyber attack lifecycle. Cyber attacks focus on digital systems, networks, and data, not physically locating cash safes. While attackers may eventually target financial data, the initial cyber attack steps are about discovering and exploiting digital vulnerabilities, not physical assets like safes.

❌ Incorrect Option: Find Email Addresses
Finding email addresses can be part of reconnaissance, especially for phishing campaigns, but it is not typically listed as one of the “four main steps” of a cyber attack. It is a specific tactic within the broader “find attack surface” or reconnaissance phase. The foundational step is identifying the overall attack surface, not just collecting email addresses in isolation.

❌ Incorrect Option: Find Least Secure Office Building
“Find least secure office building” is a physical security concern, not a core step in a cyber attack lifecycle. Cyber attacks target digital infrastructure, services, and data, not the physical security posture of office buildings. While physical access can enable cyber compromises, it is not one of the standard four steps used to describe how a cyber attack unfolds.

🔧 Reference:
→ Zscaler – What is an Incident in an Attack Lifecycle –
Describes the malicious attack lifecycle and how attackers identify and exploit vulnerabilities to gain access, consistent with finding the attack surface.

→ Zscaler – Attack Surface Definition
Defines attack surface as all vulnerabilities and entry points attackers can exploit, which attackers must find during reconnaissance.

Explanation:

This question tests knowledge of the underlying transport architecture behind Z-Tunnel 2.0, one of the two forwarding mechanisms used by Zscaler Client Connector. Understanding how Tunnel 2.0 differs from Tunnel 1.0 in terms of protocol support and encapsulation method is a core concept for deployment and troubleshooting.

✅ C. Zscaler Client Connector will encapsulate the user's traffic in dTLS/TLS tunnels to the ZTE.
Z-Tunnel 2.0 uses a tunneling architecture built on DTLS or TLS to forward packets to the Zscaler Zero Trust Exchange. DTLS operates over UDP port 443, while TLS operates over TCP port 443, with DTLS typically set as the primary transport and TLS available as a fallback. This design allows Tunnel 2.0 to support all ports and protocols, unlike the proxy-based Tunnel 1.0, making it the modern, flexible transport mechanism for full traffic forwarding to the cloud.

❌ A. GRE Tunnels
GRE tunnels are used for site-to-site forwarding from network locations such as branch offices or data centers to the Zscaler service, not for Client Connector traffic. This mechanism applies to network-level forwarding configurations, not endpoint-based Tunnel 2.0 transport, which relies on DTLS/TLS instead.

❌ B. IPSec Tunnels
IPSec tunnels are another site-to-site forwarding method, typically used by branch locations without GRE support to connect to the Zscaler cloud. Like GRE, this applies to network appliances rather than the Zscaler Client Connector, which uses DTLS or TLS encapsulation for Tunnel 2.0 traffic instead.

❌ D. HTTP Connect Tunnels
HTTP CONNECT tunneling is associated with traditional proxy-based forwarding, closer to how Z-Tunnel 1.0 operates for web traffic only. It does not describe Tunnel 2.0's transport mechanism, which uses DTLS/TLS encapsulation to support all ports and protocols beyond simple web-based connections.

🔧 Reference:
→ Configuring Forwarding Profiles for Zscaler Client Connector — confirms that DTLS uses UDP over port 443 and TLS uses TCP over port 443 as the primary transport options for Z-Tunnel 2.0.

Explanation:

This question tests knowledge of Zscaler Risk360’s key focus areas. Risk360 quantifies risk across four attack stages using data from Zscaler platforms and ThreatLabz research.

✅ Correct Option:

Option B:
Prevent Compromise fits the requirement. This focus area observes a broad range of events, security configurations, and traffic flow attributes to calculate the likelihood of compromise, including risks from malicious files, patient-zero exposures, and signs of infection.

❌ Incorrect options:

Option A:
External Attack Surface does not satisfy the requirement. It focuses on publicly discoverable variables like exposed servers and ASNs to identify internet-facing assets.

Option C:
Data Loss does not satisfy the requirement. It analyzes sensitive data attributes to assess potential leakage risks.

Option D:
Lateral Propagation does not satisfy the requirement. It evaluates private access configurations and metrics to compute risks of internal movement.

🔧 Reference:
→ Zscaler help: What Is Risk360?
Confirms Prevent Compromise analyzes events, security configurations, and traffic flow attributes for compromise likelihood.