Cloudflare Zero Trust study plan
Cloudflare Zero Trust · Give each week a clear focus.
8 weeks · About 6 hours per week
ZTNA
Map the ZTNA architecture end to end: explain how a user request reaches a private application through the Cloudflare edge, the connector, and the identity provider, and draw that path from memory.
Define the roles of the IdP, the Cloudflare One Client, the tunnel connector, and the access policy engine, and state which component makes the allow or deny decision at each hop.
Compare ZTNA with a traditional VPN on at least five concrete dimensions (attack surface, per-application authorization, lateral movement, user experience, and auditability).
Configure a working test setup: one identity provider, one connector to a private host, and one Access application reachable by a test user.
Write down the exact order of evaluation for an Access policy and identify where device posture and identity checks enter that order.
Your checkpoint
A one-page architecture diagram plus a working lab where a test user reaches a private app through a connector and is denied when removed from the IdP group.
ZTNA
Build Access policies using identity groups, email domains, IP ranges, and country rules, and predict allow or deny for ten crafted test users before testing them.
Implement device posture checks and explain which posture signals are available and what happens when a device fails a check.
Configure a service token and use it to authenticate a non-interactive client, then explain when a service token is preferable to a user identity.
Set up a self-hosted application with a short session duration and verify re-authentication behavior after the session expires.
Diagnose three common connector failures (tunnel down, route missing, DNS not resolving) using logs and status output.
Your checkpoint
A policy test matrix of at least ten cases with predicted versus actual outcomes, including one posture-based deny and one service-token success.
SWG
Describe how traffic is steered to the Cloudflare edge for web filtering, and identify the client, proxy, and DNS resolution options available for different device types.
Configure DNS filtering policies and explain how DNS-layer blocking differs from HTTP-layer blocking in what it can and cannot inspect.
Create HTTP policies using host, URL path, category, and identity criteria, and order them so that a broad block does not shadow a narrow allow.
Explain TLS inspection: when it is needed, what breaks without it, and how certificate trust is distributed to endpoints.
Identify the categories of threats SWG addresses (malware, phishing, shadow IT, data exfiltration to unsanctioned apps) and the control that mitigates each.
Your checkpoint
A working filtering ruleset with at least one DNS rule, one HTTP allow exception, and one category block, plus a written explanation of rule precedence.
SWG
Configure a block page and a bypass scenario, and verify that a user can reach an approved destination that would otherwise be caught by a broad rule.
Explain how identity is attached to web traffic for both client-based and clientless paths, and where identity is unavailable.
Trace a single blocked request through logs to show the policy that matched and the reason it matched.
Compare SWG enforcement on managed versus unmanaged devices and state the tradeoffs of each approach.
Document how SWG and ZTNA policies interact when a user reaches a private app that also makes outbound calls.
Your checkpoint
A log-based incident walkthrough for one blocked and one allowed request, each traced to the exact matching rule.
Milestones
Week 2: You can explain the full ZTNA request path from memory and your lab demonstrably denies a user who fails an identity or posture check.
Week 4: You can predict the outcome of a web request against a multi-rule policy set before testing, and you have traced real log entries to the matching rule.