Cloudflare Zero Trust common mistakes
Cloudflare Zero Trust · Understand the traps and how to avoid them.
Treating Cloudflare's ZTNA as a classic VPN concentrator and answering that all traffic must hairpin through a central edge before reaching a private app.
Candidates carry over mental models from traditional remote-access VPNs and from other SASE vendors where traffic is backhauled to a PoP. Cloudflare's model instead uses a lightweight client (WARP) and connectors that establish outbound-only tunnels from the private network, so the app is reached through the closest path without exposing inbound ports.
What to do instead
Study the split between the client, the Cloudflare network, and the connector. Be able to explain that connectors dial out to Cloudflare (no inbound firewall holes), that the client routes only the configured private CIDRs or hostnames, and that policy is evaluated per request at the edge. Practice drawing the packet path for a user hitting an internal app and for a user hitting a public SaaS app, and note where they diverge.
Assuming a user who passes the IdP login is automatically authorised to a private application, and omitting device posture or group conditions from the Access policy.
Identity-only thinking is the default habit from SSO deployments. In Zero Trust, authentication (who you are) and authorisation (whether this device and context may reach this app) are separate decisions, and Access policies can require posture checks, specific IdP groups, or session context before granting the application.
What to do instead
Memorise the Access policy building blocks: include, require, and exclude rules, plus IdP group selectors, device posture attributes, and the difference between an allow and a block/bypass outcome. Be able to read a scenario such as 'contractors on unmanaged laptops must reach an internal wiki but not the finance app' and construct the include/require/exclude combination that satisfies it, including what happens when no policy matches.
Confusing Gateway DNS filtering with Gateway network (L4) and HTTP (L7) policies, and applying a policy at the wrong layer so it silently does nothing.
Gateway exposes several policy types that look similar in the dashboard but inspect different traffic. A DNS policy can only see the queried domain, an L4 policy sees IP and port, and an HTTP policy can see full URLs, methods, and file content. Candidates pick whichever policy page they remember and expect URL-path matching to work at the DNS layer.
What to do instead
Build a table mapping each Gateway policy type to what it can inspect and what it cannot. Then practise selecting the correct layer for goals like 'block this domain entirely', 'block only the /uploads path', and 'block this IP range on port 22'. Remember that DNS filtering requires the device to use Gateway as its resolver, and that HTTP inspection requires the traffic to traverse the proxy, so a policy at the wrong layer is a common source of 'it did not block' answers.
Answering that enabling a Gateway block policy is enough to enforce it on roaming users, without accounting for how the device sends DNS and HTTP traffic to Cloudflare.
Policies only act on traffic that actually reaches Gateway. If the endpoint is not running the client, or the client is in a mode that does not proxy the relevant traffic, the policy is bypassed. Candidates forget the deployment dependency and choose an answer that assumes enforcement is automatic.
What to do instead
Learn the client modes and what each one does with DNS and with HTTP/HTTPS, and know which mode is needed for full L7 inspection versus DNS-only filtering. For each policy scenario, ask 'what makes this traffic visible to Gateway?' and verify the client mode, the resolver configuration, and whether the destination is excluded from tunnelling. Also know how to check that a device is actually enrolled and reporting.
Treating DEX as a network-monitoring tool that only reports on Cloudflare's own edge, and selecting answers that ignore the endpoint agent.
The name suggests infrastructure monitoring, so candidates picture dashboards of PoP health. In practice DEX is largely about the end-user experience: endpoint metrics, application and network tests, and visibility into the device and its connectivity, which requires the agent on the endpoint.
What to do instead
Study what DEX collects and from where: device health and resource metrics, network path and connectivity tests, and application-specific probes configured as tests. Be clear on the difference between fleet-wide trend views and per-device troubleshooting views, and on how a synthetic test differs from passive observation. Practise diagnosing 'users in one office report slow access to one app' by naming which DEX data you would inspect first.
Assuming a CASB finding automatically remediates the SaaS issue, or that API-mode CASB sees the same things as inline proxy mode.
CASB in Cloudflare can operate through API integrations with SaaS providers and through inline traffic inspection, and the two have different visibility and enforcement capabilities. Candidates conflate detection with enforcement and expect a posture finding to block an action in real time, or expect API mode to inspect unsanctioned shadow IT that never touches an integrated app.
What to do instead
Map each CASB capability to its mode: API integrations give deep visibility into sanctioned apps (users, files, sharing settings, posture checks) but act after the fact through the provider's API, while inline inspection sees traffic to any destination but only what traverses the proxy. For a scenario, decide whether the requirement is 'find and fix misconfigured sharing in our sanctioned suite' or 'stop uploads to an unsanctioned service', and choose the mode accordingly.
Designing DLP rules that match on a single generic pattern and expecting them to catch real sensitive data without excessive false positives.
Candidates reach for a simple regex or a built-in detection profile and stop there. Real DLP accuracy comes from combining detection entries, validation (such as checksums or keyword proximity), and counting thresholds, and from scoping rules to the right traffic and destinations. A bare pattern either misses variants or floods reviewers.
What to do instead
Learn the anatomy of a DLP profile: detection entries, the difference between pattern matching and validation, match counts, and how profiles are attached to rules that specify scope and action (allow, block, log). Practise tuning a rule for a specific data type by adding context conditions and a count threshold, and be ready to explain how you would reduce false positives on a test group before enforcing block.
Mixing up the roles of the identity provider, the Cloudflare dashboard configuration, and the on-device client when troubleshooting an access failure, and blaming the wrong component.
A single failed request crosses several systems: the IdP assertion, the Access application and policy, the connector or client path, and the Gateway or DLP rules that may also apply. Candidates latch onto the first component they recognise and pick an answer that fixes the wrong layer, such as changing an IdP group when the real issue is a missing connector or a client that is not enrolled.
What to do instead
Adopt a layered troubleshooting order: confirm identity and IdP group membership, then confirm the Access application and policy match, then confirm the connector is healthy and the private route exists, then confirm client enrolment and mode, then check Gateway/DLP rules for an unintended block. For each layer, name the specific log or dashboard view you would check. Practise with scenarios where the symptom is identical but the root cause sits at a different layer.
Treating the four domains as separate products and missing questions that require combining them, such as a DLP rule that depends on Gateway inspection or an Access policy that depends on device posture from the client.
Study plans often go domain by domain, so candidates learn each feature in isolation and freeze when a question spans two. The exam frequently tests integration points because real deployments rely on them, and the correct answer often depends on which component must be deployed for another to function.
What to do instead
Build a dependency map: which features require the endpoint client, which require a connector, which require an IdP integration, and which require a SaaS API connection. Then write short cross-domain scenarios, for example 'block uploads of customer records to personal cloud storage from unmanaged devices', and trace every component needed to enforce it end to end. Reviewing these chains is the fastest way to handle integrated questions.
Memorising product names and menu locations instead of the decision logic, so answers that sound plausible but invert a default behaviour are chosen.
Cloudflare's admin surface changes frequently, and question writers test behaviour and defaults rather than where a toggle lives. Candidates who memorise navigation paths cannot reason about an unfamiliar scenario, and they misjudge defaults such as what happens when no policy matches, whether logging is on by default, or how a block action differs from an isolate or a bypass.
What to do instead
For every control, learn the default state, the possible actions, and the observable effect. Make flashcards of the form 'if no rule matches, then ...' and 'action X does Y to the session'. When practising, justify each answer by the behaviour it produces rather than by the menu it lives in, and flag any behaviour you are unsure about for verification in current documentation rather than guessing.