ZDTA Practice Questions

Zscaler PageRisk is a proprietary dynamic threat assessment technology embedded in Zscaler Internet Access (ZIA). PageRisk dynamically computes a real-time risk score (ranging from 1 to 100) for web pages as users navigate to them. It calculates risk attributes dynamically by analyzing page components, domain age, structural characteristics, suspicious obfuscated JavaScript, external references, and threat signals on the page. By assigning a dynamic PageRisk score, Zscaler allows administrators to enforce granular access policies, enforce browser isolation, or block access to web pages exhibiting high-risk characteristics before actual malicious payloads execute.

A. Third-Party Sandbox sends suspicious files to external sandboxing environments rather than calculating dynamic web page risk scores inline.

C. Browser Isolation Feedback Form is not a threat calculation technology; it relates to user interface feedback during isolation sessions.

D. Deception Controller manages decoys and lures for internal network threat detection, not dynamic website PageRisk scoring.

- Zscaler Documentation: "About PageRisk", Zscaler Help Portal. https://help.zscaler.com/zia/about-pagerisk

- Zscaler Technical Whitepaper: "Zscaler Internet Access Security Architecture", Zscaler Inc. https://www.zscaler.com/resources/security-evaluations/tech-preview-pagerisk.pdf

Zscaler Client Connector Tunnel 2.0 is designed to forward all user traffic securely to the Zero Trust Exchange using DTLS or TLS transport encapsulation. By default, Tunnel 2.0 establishes a primary DTLS (Datagram Transport Layer Security) tunnel to achieve optimal performance for real-time traffic such as voice and video, avoiding TCP-in-TCP head-of-line blocking. If DTLS traffic is blocked or degraded by network firewalls, Client Connector automatically falls back to a standard TLS (Transport Layer Security) tunnel over TCP port 443. This dual-tunneling transport mechanism guarantees resilient connectivity and complete IP-layer encapsulation for enterprise applications without relying on legacy GRE or IPSec client-to-cloud mechanisms.

A. Tunnel 2.0 utilizes client-initiated DTLS/TLS encapsulation, whereas GRE is used for router-based or edge-location network forwarding.

B. IPSec is an edge/router site-to-site tunneling protocol, not the transport layer protocol leveraged by Client Connector Tunnel 2.0.

D. HTTP Connect tunnels are utilized in Tunnel 1.0 architecture, whereas Tunnel 2.0 relies exclusively on DTLS/TLS encapsulation.

- Zscaler Documentation: "About Zscaler Tunnel 1.0 and Tunnel 2.0", Zscaler Client Connector Help, Section: "Tunnel 2.0 Transport Protocols". https://help.zscaler.com/client-connector/about-zscaler-tunnel-1.0-and-tunnel-2.0

- Zscaler Documentation: "Choosing the Best Traffic Forwarding Method", Zscaler Architecture Series, Section: "Client Connector Forwarding Modes". https://help.zscaler.com/zia/choosing-traffic-forwarding-option

A significant portion of web traffic and potential threat delivery occurs within encrypted HTTPS tunnels. To inspect traffic within these secure connections, the Zscaler Zero Trust Exchange utilizes TLS Inspection. TLS Inspection acts as an inline proxy that decrypts SSL/TLS traffic, allowing inline security modules—such as Malware Protection, Advanced Threat Protection, and Cloud Antivirus—to analyze payload contents and evaluate files against known threat signatures and heuristics. Without TLS Inspection, encrypted malware downloads and command-and-control communications would pass through uninspected. Once decrypted and inspected, the traffic is re-encrypted before being delivered to the destination, ensuring comprehensive threat prevention while maintaining protocol security.

Option A: Deception technology uses decoys to detect lateral movement inside networks, not inline malware protection within user HTTPS web sessions.

Option B: Application Segmentation controls access to private applications via ZPA, but does not perform content-level malware signature inspection inside HTTPS streams.

Option D: Data Loss Protection prevents unauthorized data exfiltration and sensitive data leaks, rather than identifying and blocking incoming malware threats.

- Zscaler Documentation: "About SSL Inspection", Zscaler Help Portal, Section: "TLS/SSL Decryption and Malware Protection".

- Zscaler Documentation: "Malware Protection Policy Settings", Zscaler Help Portal, Section: "Inspecting Encrypted HTTPS Traffic".

In Zscaler's URL Filtering policy, the Caution action presents an End-User Notification (EUN) page warning users about potentially risky destination websites before granting access. Because presenting an interactive HTML warning page and processing a user's click-through response requires safe, standard web request methods, Zscaler restricts the Caution action specifically to the CONNECT, GET, and HEAD HTTP request methods. Methods such as POST, PUT, DELETE, and TRACE involve uploading payloads, modifying resources, or diagnostic tracing where inserting an interactive EUN page could break application logic or result in unsafe data submissions. Therefore, configuring Caution is only supported for the standard retrieval and tunnel setup methods: CONNECT, GET, and HEAD.

Option B: OPTIONS, DELETE, and PUT methods perform state-changing or capability query operations where interactive End-User Notification caution pages cannot be safely rendered.

Option C: TRACE and DELETE request methods do not support interactive user browser prompting required for the Caution action EUN display.

Option D: POST and PUT methods carry request payloads that could be prematurely transmitted or broken when intercepted by an interactive caution page.

- Zscaler Documentation: "Configuring URL Filtering Policy", Zscaler Help Portal, Section: "URL Filtering Policy Actions and HTTP Request Methods".

- Zscaler Documentation: "URL Filtering Policy Settings", Section: "Actions - Caution".

Inline Data Protection inspects web traffic and data in motion in real time as it flows through the security cloud gateway. Blocking the attachment of a sensitive document in a webmail application is a classic example of inline Data Loss Prevention (DLP). As the user attempts to upload or send the file over HTTP/HTTPS, Zscaler Internet Access (ZIA) inspects the payload inline, detects sensitive content using configured DLP engines and dictionaries, and actively blocks the transaction before the sensitive data leaves the network boundary. This real-time enforcement prevents data exfiltration over the web.

A. Preventing USB file copying is managed by Endpoint DLP or host-based security solutions, not inline network data protection.

B. Preventing document sharing within OneDrive relies on API-based Out-of-Band Cloud Access Security Broker (CASB) scanning at rest.

C. Analyzing tenant security configurations represents SaaS Security Posture Management (SSPM) rather than inline data inspection.

- Zscaler Documentation: "About Data Loss Prevention", Zscaler Help Portal. https://help.zscaler.com/zia/about-data-loss-prevention

- Zscaler Documentation: "Configuring Inline DLP Policies", Zscaler Help Portal. https://help.zscaler.com/zia/configuring-inline-dlp-policies

In the SAML authentication flow within Zscaler architecture, the Identity Provider (IdP) generates a signed SAML assertion containing user and device attributes after successful user authentication. This assertion is sent back via the browser to Zscaler acting as the SAML Service Provider (SP). The Zscaler SAML SP is the initial Zscaler component that ingests, decrypts, and validates the incoming SAML assertion. It extracts the embedded device attributes and identity mappings, passing them downstream to the policy management framework and enforcement nodes. Because the Zscaler SAML SP acts as the single entry point for processing SAML metadata, it consumes these attributes first to enable policy definitions before traffic evaluation occurs across the Zero Trust Exchange.

A. Enforcement nodes consume policy directives derived from attributes, but do not directly ingest or process the raw SAML assertion first during authentication.

C. The Mobile Admin Portal is used by administrators to configure policies; it does not process live authentication SAML assertions directly from the IdP.

D. The Zero Trust Exchange encompasses the entire platform architecture, whereas the SAML SP is the specific sub-component that first ingests the SAML assertion.

1. Zscaler Config & Deployment Guide: "Configuring SAML for Zscaler Service Provider", Section: SAML Assertion Attribute Ingestion, Zscaler Help Portal.

2. Zscaler Technical Architecture Whitepaper: "Zero Trust Architecture and Identity Federation", Section: Identity Integration and SAML SP Processing.

Within the Zscaler Internet Access (ZIA) Admin Portal, the Security Dashboard provides granular visibility into active organizational cyber threats. The Security Alerts section specifically includes a dedicated graphical widget titled "Top 5 Threats by Systems Impacted." This visualization aggregates security incident telemetry from across the enterprise network, highlighting the five most severe malware and threat vector instances based on the total number of unique client systems or endpoints compromised or targeted. By presenting this data, security administrators can rapidly prioritize response efforts, isolate affected host systems, and adjust security filtering policies in real time to prevent further lateral spread or enterprise-wide exposure to critical threats.

A. Top 5 Malware Programs Detected: While malware detection is tracked in analytics, this specific named graph in the Security Alerts dashboard focuses on system impact rather than program count.

B. Top 5 Viruses by Region: Threat location data is tracked in regional traffic analytics dashboards, not as a primary default widget in the Security Alerts section.

D. Top 5 Unified Threat Yara Options: YARA rules are used for customized binary threat matching in Sandbox policies, not as a standard widget in the Security Alerts graph.

- Zscaler Help Portal: "About the Security Dashboard", Analytics & Reporting Section, Subsection: Security Alerts & Threat Widgets.

- Zscaler ZIA Administrator Guide: "Monitoring Threats and Security Alerts", Chapter: Analytics and Real-time Visibility.

During SAML 2.0 Web Browser SSO authentication for accessing private applications via Zscaler Private Access (ZPA), the user is first redirected to the SAML Identity Provider (IdP) for credential verification. Once authenticated, the IdP generates an HTML document containing an embedded SAML assertion and an automated JavaScript form. The user's web browser processes this document and automatically performs a Form POST request to the Assertion Consumer Service (ACS) endpoint of the Service Provider (SP). This standard HTTP POST mechanism securely delivers the SAML assertion payload directly from the client browser to the SP without requiring direct back-channel API connections between the IdP and SP.

A. HTTP Redirect is used to send the user from the SP to the IdP, but cannot carry large SAML assertions due to URL length restrictions.

B. SAML browser SSO relies on front-channel browser redirects and HTTP POST requests rather than direct back-channel API request/response sequences between systems.

C. While Zscaler Client Connector facilitates transport, standard SAML assertions in web application SSO are delivered to the SP via the browser's HTTP Form POST.

1. OASIS SAML v2.0 Standard: "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", Section 3.5: Web Browser SSO Profile.

2. Zscaler Private Access (ZPA) Documentation: "SAML Single Sign-On Deployment Guide", Section: SAML Authentication Workflow.

Zscaler Cloud Firewall incorporates advanced Deep Packet Inspection (DPI) alongside signature-based and behavioral analysis to identify applications regardless of port, protocol, or evasion attempt. When an application attempts to evade security controls by communicating over non-standard ports (such as SSH running over port 80 or HTTP over non-standard high ports), the Cloud Firewall's DPI engine inspects payload headers and characteristics. Upon identifying the true application layer protocol, it dynamically categorizes the traffic and routes it to the corresponding policy and inspection engines, such as the ZIA proxy engine or Cloud IPS, ensuring full control and preventing evasion.

B. Endpoint firewalls and ZCC route traffic, but detection of network protocol evasion on active traffic flows is handled centrally by Zscaler Cloud Firewall's DPI.

C. On-premise firewalls do not normalize or correct traffic protocols for cloud forwarding; Zscaler inspects all arriving traffic independently in the cloud.

D. The Cloud Firewall does not blindly block all non-standard traffic via IPS; it inspects and routes identified traffic to specific policy engines for handling.

1. Zscaler Help Portal: "About Cloud Firewall", Section "Deep Packet Inspection and Application Identification", https://help.zscaler.com/zia/about-cloud-firewall

2. Zscaler Technical Reference: "Zscaler Internet Access Architecture: Firewall and IPS Engines", Section "Protocol Evasion Detection", https://help.zscaler.com/zia/firewall-control

Zscaler Private Access (ZPA) allows administrators to create Access Policy rules based on multiple conditions to enforce zero-trust access control. Valid criteria for ZPA Access Policy rules include identity criteria such as SAML/SCIM group membership, risk-based posture criteria including ZIA User Risk Score, and endpoint device posture profile criteria such as Domain Joined status and Certificate Trust. Device posture checks verify whether the client endpoint meets specific security requirements before granting access to private applications. Combining group membership, device posture profiles, and risk scores ensures that access is granted dynamically based on user identity, context, and endpoint security hygiene. Therefore, Option A correctly lists valid criteria used in ZPA Access Policies.

Option B: Password is not evaluated as an access policy rule criterion directly within ZPA policy criteria, as authentication is delegated to the Identity Provider.

Option C: Time of Day and Country Code are criteria used in ZIA policy evaluation, not standard ZPA Access Policy rule conditions.

Option D: SNI (Server Name Indication) is a TLS header parameter rather than a valid ZPA Access Policy rule criterion.

- Zscaler Documentation: "Configuring Access Policies", ZPA Help Portal, 2023, Section: Policy Criteria.

- Zscaler Documentation: "Evaluating Device Posture Profiles", ZPA Help Portal, 2023, Section: Posture Types.