CDN Monitoring & Troubleshooting 4 — Questions and Answers
Question 1: A CDN-delivered API endpoint intermittently returns cached error responses (e.g., 500 errors) to clients. What configuration change would prevent this?
- Increase the CDN TTL for all responses
- Configure the CDN to not cache 5xx responses (negative caching prevention) (Correct answer)
- Enable HTTP/2 push for API responses
- Add Vary: Origin to response headers
Correct answer: Configure the CDN to not cache 5xx responses (negative caching prevention)
By default some CDNs may cache error responses; explicitly configuring the CDN to bypass cache for 5xx status codes prevents error responses from being served to subsequent users.
Question 2: What is the significance of monitoring the CDN's TLS handshake time separately from TTFB?
- TLS handshake time is always negligible for CDN deployments
- High TLS handshake time indicates edge proximity issues or misconfigured TLS session resumption (Correct answer)
- TLS metrics only matter for non-CDN traffic
- Monitoring TLS separately has no diagnostic value
Correct answer: High TLS handshake time indicates edge proximity issues or misconfigured TLS session resumption
TLS handshake time measures connection establishment overhead; if high, it may indicate users are connecting to distant edge nodes or TLS session tickets/resumption is not working.
Question 3: Which HTTP response header should a CDN operator monitor to detect when origin servers are setting excessively short cache TTLs that reduce offload efficiency?
- Content-Length
- Cache-Control: max-age directive value (Correct answer)
- X-Forwarded-For
- Accept-Ranges
Correct answer: Cache-Control: max-age directive value
The Cache-Control max-age value set by the origin determines how long the CDN caches objects; very low values cause frequent origin fetches and reduce offload ratio.
Question 4: A CDN log analysis shows that 30% of requests include 'If-None-Match' headers but the CDN is not returning 304 responses. What does this indicate?
- The CDN is correctly bypassing conditional request optimization
- The CDN is not storing or honoring ETags, causing full object re-delivery instead of 304 responses (Correct answer)
- Clients are using outdated browser caches
- The origin does not support HTTP/1.1
Correct answer: The CDN is not storing or honoring ETags, causing full object re-delivery instead of 304 responses
When CDN ignores ETags from conditional requests, it delivers full 200 responses instead of 304 Not Modified, wasting bandwidth that could be saved with proper ETag support.
Question 5: During a traffic spike, a CDN operator notices the origin shield is being bypassed by multiple edge POPs simultaneously. What configuration addresses this?
- Increase edge POP count globally
- Enable request coalescing (also called request collapsing) at the shield layer (Correct answer)
- Reduce origin connection pool size
- Disable keepalive connections to origin
Correct answer: Enable request coalescing (also called request collapsing) at the shield layer
Request coalescing at the origin shield ensures that simultaneous cache misses for the same object result in only one origin request, preventing thundering-herd overload.
Question 6: What does the CDN metric 'edge error rate' measure, and why is it distinct from 'origin error rate'?
- Both metrics measure the same thing — errors seen by end users
- Edge error rate includes errors generated by the CDN itself (e.g., routing failures, TLS errors), while origin error rate measures errors from the upstream server (Correct answer)
- Edge error rate only counts DNS failures
- Origin error rate includes client-side JavaScript errors
Correct answer: Edge error rate includes errors generated by the CDN itself (e.g., routing failures, TLS errors), while origin error rate measures errors from the upstream server
Edge errors originate within the CDN infrastructure (config errors, POP failures, TLS issues), while origin errors come from the upstream server — distinguishing them pinpoints where failures occur.
Question 7: A CDN operator wants to alert on potential DDoS amplification through the CDN. Which metric combination is most indicative?
- Increase in cache hit ratio combined with lower TTFB
- Sudden spike in request rate with high percentage of cache misses and traffic to a single URL (Correct answer)
- Gradual increase in unique visitors over 24 hours
- Decrease in origin response time with steady traffic
Correct answer: Sudden spike in request rate with high percentage of cache misses and traffic to a single URL
DDoS attacks often generate massive request spikes targeting specific URLs; high miss rates under that spike indicate the CDN is not absorbing the attack and origin is being overwhelmed.
CDN Monitoring & Troubleshooting 4
A CDN-delivered API endpoint intermittently returns cached error responses (e.g., 500 errors) to clients.
What configuration change would prevent this?