Learning objectives
- How would you protect a publisher without caching private checkout responses?
- How would you explain DNS-only versus proxied DNS to a CTO?
- Apply Proxy status to a customer decision and defend the tradeoff.
The mental model
Begin with the request your customer wants to protect, rather than a list of product logos. DNS answers where a name points. A CDN can serve eligible content closer to users. A web application firewall evaluates HTTP requests for suspicious patterns or configured policy violations. DDoS protection addresses attacks intended to exhaust resources. These functions overlap operationally but solve different problems. A faster static image does not prove that checkout is reliable, and a successful DNS lookup does not prove that traffic passes through application protections. Draw the origin, public entry points, administrative access, and exceptions before recommending a service combination.
How it works
Cloudflare authoritative DNS and its HTTP reverse proxy are separate architectural decisions. A DNS-only record can resolve correctly while its application traffic goes directly to the origin. For proxied traffic, consider the client-to-edge and edge-to-origin connections separately; certificate validation, host routing, cache eligibility, and origin authorization all require deliberate configuration. CDN caching reduces repeated origin work when the cache key and freshness policy match the application's semantics. Personalized responses require special care because a shared cache can cross a privacy boundary.
The WAF evaluates requests at the application layer; DDoS mitigation operates across attack classes and network layers. Neither eliminates vulnerable application logic or guarantees unlimited origin capacity. A useful proof plan includes a permitted request, a representative blocked request, an uncached dynamic request, an origin timeout, and an attempted bypass of the intended ingress. Capture request identifiers and corresponding origin observations. Compare user-visible outcomes, not only dashboard totals. Price and feature availability must be checked for the actual plan; avoid claiming that a rule, log dataset, retention period, or security feature exists identically on every subscription.
For a practical cache test, request the same public asset twice and inspect response headers alongside origin access logs. Then request two authenticated accounts with deliberately different content and confirm that neither receives the other's response. Repeat after a cache rule change. This distinguishes performance validation from privacy validation. For security testing, use approved benign test payloads and scoped rules; a rise in blocked-request counts alone cannot distinguish successful attack prevention from disruption of legitimate customers.
Applied example · hypothetical
Hypothetical scenario: a WordPress publisher complains that a campaign makes both images and payment callbacks slow. You separate cacheable public assets from authenticated checkout and webhook paths. A CDN pilot measures asset hit ratio and origin load, while application telemetry follows callback latency independently. A narrowly scoped WAF rule is tested against legitimate payment payloads before enforcement. The publisher accepts a rollback condition if valid callbacks fail. Any reduction in latency, incident frequency, or cost remains an outcome to verify with baseline and pilot data.
In a customer engagement
In a customer engagement, ask which hostnames are public, which records are proxied, how the origin authenticates inbound traffic, and which responses contain user information. Agree on separate success criteria for asset delivery and transaction reliability. Present a staged change with an origin bypass test, a cache privacy test, and a named rollback owner so operations can support the recommendation.
Interview relevance
In an architecture interview, explain the request path before naming DNS, CDN, WAF, and DDoS products. Give one example each of a problem these services can address and a problem left to the application. A strong answer makes the trust boundaries and testing plan visible instead of promising that an edge layer fixes every failure.
Common mistakes
- Caching all HTML indiscriminately
- Treating WAF as an application patch
- Claiming DNS-only traffic receives HTTP WAF checks
Key terminology
Proxy status — Whether an eligible DNS record routes application traffic through Cloudflare's proxy or only publishes DNS answers.
Cache eligibility — The policy decision determining whether a response may be stored and reused.
Origin bypass — A path that reaches an origin without traversing the intended ingress controls.
Explain it without the page
- How would you protect a publisher without caching private checkout responses?
- How would you explain DNS-only versus proxied DNS to a CTO?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.