Cloudflare Network Security common mistakes
Cloudflare Network Security · Understand the traps and how to avoid them.
Treating a Cloudflare WAF custom rule as if it applied to all traffic by default, forgetting that the rule action only fires on requests that match the expression, and that unmatched requests fall through to managed rules and other layers.
Candidates conflate 'I created a rule' with 'I blocked the attack'; they test by sending one matching request and one non-matching request but never verify the default path for unmatched traffic, so they misdiagnose gaps as rule failures.
What to do instead
For every scenario, trace a request through each layer explicitly: edge DDoS, IP Access Rules, WAF custom rules in order, managed rulesets, rate limiting, then origin. State which layer matches and which action wins. Practice by writing the expected outcome for a matching and a non-matching request before answering.
Mixing up WAF custom rule actions (Block, Managed Challenge, JS Challenge, Log) with the effect of the rule's expression, and choosing 'Block' for traffic that should have been challenged or logged during rollout.
The actions sound interchangeable and the exam tests operational judgment; candidates pick the strongest action reflexively instead of reasoning about false positives and staged deployment.
What to do instead
Memorize what each action does to the client and to the origin: Block returns an edge response and never reaches origin; Managed Challenge issues an interactive challenge; JS Challenge runs a non-interactive JS check; Log only records. Default to Log or Managed Challenge when tuning, and reserve Block for confirmed bad signatures.
Assuming rate limiting counts by IP address only, ignoring that the counting characteristic can be based on other fields (such as a header, cookie, or path) and that the mitigation timeout and counting period interact.
Candidates carry over intuition from generic rate limiters and forget Cloudflare rate limiting rules are defined by a counting characteristic plus a period and a threshold, so they miscompute when a client is actually blocked.
What to do instead
When a question gives a threshold, period, and timeout, compute the window explicitly: requests within the period are counted per characteristic value; exceeding the threshold triggers the action for the mitigation timeout. Also check whether the characteristic is IP or a custom value before concluding a bot evades or is caught.
Confusing Cloudflare's proxy status (orange cloud vs grey cloud / DNS-only) with security features, and expecting WAF, DDoS, or TLS settings to apply to records that are not proxied.
The DNS record is the switch for whether traffic flows through Cloudflare's edge; candidates answer security questions without checking whether the hostname is proxied, so they expect edge protections on direct-to-origin traffic.
What to do instead
Before answering any 'will the WAF block this' question, confirm the record is proxied. If it is DNS-only, edge features do not apply and the origin is exposed; the fix is to enable the proxy and lock the origin to Cloudflare IPs or use Tunnel/Authenticated Origin Pulls.
Misreading the order of evaluation and assuming a later layer can override an earlier Block, or that an Allow in one layer guarantees the request reaches the origin.
Candidates treat the security stack as a single decision rather than a pipeline where a terminal action at an earlier stage ends evaluation; they answer based on the 'most specific' rule rather than the actual sequence.
What to do instead
Learn the pipeline order and where evaluation terminates: a Block at any layer stops the request; an Allow at one layer does not bypass a Block at another. For each scenario, identify the first layer that produces a terminal action and stop there.
Treating Bot Management scores and verified bot status as binary, and assuming a high bot score always means block or that a verified bot is always safe.
The score is a probability-like signal and verified bots can still be abused or spoofed; candidates reach for a simple rule of thumb instead of reasoning about thresholds, detection IDs, and verification.
What to do instead
Reason in terms of thresholds and trade-offs: a bot score cutoff trades false positives against false negatives, verified bot status depends on validation of the bot's identity, and spoofed user agents do not confer verified status. Choose challenge actions for uncertain scores and reserve block for high-confidence malicious signals.
Assuming TLS/SSL settings like 'Full (strict)' and 'Flexible' are interchangeable, and not recognizing that Flexible terminates TLS at the edge and connects to the origin over plain HTTP, creating a redirect loop or downgrade risk.
The mode names do not describe behavior; candidates pick the mode that 'sounds secure' without tracing where TLS terminates and what protocol reaches the origin.
What to do instead
Map each mode to its origin connection: Off (HTTP), Flexible (HTTP to origin), Full (HTTPS, any cert), Full strict (HTTPS, valid cert). If a question mentions redirect loops or mixed content, check whether Flexible is in play; recommend Full strict with a valid origin certificate.
Confusing Always Use HTTPS, Automatic HTTPS Rewrites, and HSTS as if they do the same thing, and expecting one to fix all mixed-content or downgrade issues.
All three touch HTTPS behavior but operate at different points: redirecting requests, rewriting page links, and instructing browsers to enforce HTTPS. Candidates collapse them into 'the HTTPS setting'.
What to do instead
Separate them by function: Always Use HTTPS redirects HTTP requests at the edge; Automatic HTTPS Rewrites changes same-zone HTTP subresource URLs in HTML; HSTS is a browser-enforced policy delivered via header. Match the symptom (redirect, mixed content, browser enforcement) to the right control.
Ignoring that Access (Zero Trust) policies apply to specific applications and paths, and assuming enabling Access for one hostname protects the whole zone or that a bypass policy is harmless.
Access is application-scoped and evaluated per request path; candidates generalize from 'Access is on' to 'everything is protected' and overlook bypass rules that open specific paths.
What to do instead
For each scenario, identify the Access application's domain and path, the policy action (Allow, Block, Bypass), and the identity conditions. Check for Bypass policies on sensitive paths and confirm the origin is locked so direct access cannot skip Access.
Treating IP Access Rules, firewall rules, and WAF custom rules as one feature, and picking the wrong tool for the job, such as using an IP rule for a path-based condition or a WAF rule for a country block.
The tools overlap in appearance but differ in scope and matchable fields; candidates choose whichever they remember first instead of the one that supports the required fields and action.
What to do instead
Build a decision table: IP Access Rules match IP, IP range, country, or ASN; WAF custom rules match rich request fields (URI, headers, body, JA3, etc.) with actions including Block, Challenge, Log; rate limiting adds thresholds over time. Select the tool whose matchable fields cover the condition, then confirm the action.