ZDX Green While the Service Desk Is Red
A software company with 250 users across London, Austin, Manila and Bangalore has ZDX deployed on its Windows and macOS laptops. The Manila service desk reports the CRM is unusable every afternoon. Manila's overall ZDX score is 88; the CRM application score for Manila is 41; the same CRM scores 78–85 in the other three offices. The network team says the Manila ISP circuit is unchanged and the ZDX cloud path shows 0.3% packet loss to the Singapore enforcement node. Six of the complainants are contractors on unmanaged BYOD devices with no Client Connector installed. Leadership has seen the 88 and is questioning whether the complaints are real.
1. Reconcile the two scores for leadership and explain what the CRM application score is actually measuring.
Read the worked answer
They measure different things. The office/device score is a composite of experience across the sites and users in that group - device health, Wi-Fi, local network, general web reachability. The application score is specific to that application's probes. 88 vs 41 means the Manila laptops, local access network and last mile are broadly healthy, while something specific to CRM is not. One score cannot be read as a verdict on the other.
Break the CRM score into its probe components: DNS resolution, TCP connect, TLS handshake, server response/first byte, and subsequent latency and packet loss along the cloud path. Compare each component with the other three offices. If DNS, TCP and TLS are normal but server response is seconds only in the afternoon, the backend or the path after Zscaler is the suspect, not the office. Check whether the degradation is time-correlated - 'every afternoon' in Manila is peak hours in another region, or a batch job, and that pattern alone often points away from the local ISP.
2. Describe how you would localise the fault: is it the Manila last mile, the Zscaler egress path, or the CRM backend?
Read the worked answer
Work outward in layers, using comparisons to eliminate rather than guess:
- Same app, other offices, same time. If all offices degrade, it is the app or a shared egress region. Here they do not, so the problem is path- or region-specific.
- Other apps, same office, same time. If only CRM degrades while other SaaS is fine, the Manila ISP is exonerated.
- Cloud path, hop by hop. Loss or latency on the first hops points at local Wi-Fi or the ISP; a step change after the Zscaler enforcement node points at PoP selection or the Zscaler-to-app internet path. The reported 0.3% loss to Singapore only covers the first half of the journey.
- Which enforcement node Manila egresses from, and where CRM is hosted. A tunnel, forwarding-profile or location change can move egress; a user cohort tunnelling to Singapore to reach an app in the US is a design problem, not a fault.
- Deep trace on a live affected session during the afternoon window, compared against a working office at the same moment. Correlate with ZIA logs if CRM is inspected - a new inspection or app-control policy shows up as added latency, and the timing of the complaint is evidence for or against it.
The answer to leadership is a ranked hypothesis with evidence per layer, not a score.
3. What is the visibility gap created by the BYOD users, and how do you close it without changing their security posture?
Read the worked answer
ZDX is endpoint-based: no Client Connector, no probes, no score. Those six users are invisible, which means the 88 is an average over only the instrumented devices - a subset that excludes the people complaining. Averages computed over a biased sample are not evidence.
Close the gap:
- Deploy Client Connector on managed or enrolled BYOD devices with a profile that runs ZDX probes even where full tunnelling is not required, so you gain monitoring without altering how their traffic is handled. Confirm the profile combination with your account team before rollout.
- Until then, use ZIA web logs for that cohort if they traverse ZIA at all, plus the SaaS vendor's own regional latency/RUM data and the vendor's status page for the afternoon window.
- Treat unmanaged devices as a standing blind spot in any score you present, and label the population behind each number.
Do not close the ticket on the office score. The defensible statement is: instrumented Manila devices show CRM-specific degradation while general experience is normal, and the uninstrumented complainants are a known gap currently being covered by proxy and vendor data.