This chapter covers Cloud CDN (Content Delivery Network) and how it leverages Google's global network to accelerate content delivery. For the GCDL exam, this topic appears in roughly 8-12% of questions under Infrastructure (Objective 2.4). You will need to understand how Cloud CDN caches content at Google's edge locations, reduces latency, and offloads origin servers. We will explore the underlying mechanisms, default behaviors, key configuration parameters, and common pitfalls tested on the exam.
Jump to a section
Imagine a central library in New York City that holds every book ever published. A patron in Tokyo wants a specific cookbook. Without Cloud CDN, that request travels across the Pacific Ocean to NYC, the book is retrieved, scanned, and the scan travels back — a round trip of over 200 milliseconds. With Cloud CDN, it's like having small branch libraries in Tokyo, London, São Paulo, and Sydney. Each branch doesn't hold every book — only the most popular ones. When a patron in Tokyo requests the cookbook, the Tokyo branch checks its shelves. If the book is there (cache hit), the patron gets it instantly. If not (cache miss), the Tokyo branch sends a request to the central library, but instead of sending the entire book back to the patron, the central library sends a copy to the Tokyo branch, which then serves it to the patron and keeps a copy for future requests. The branch also has a policy: if a book hasn't been borrowed in 24 hours (TTL), it is returned to the central library to free shelf space. This system reduces the load on the central library and dramatically speeds up delivery for patrons worldwide. The key mechanism: the branch library does not need to know the entire catalog — it only stores content that is actually requested, and it respects expiry policies to ensure freshness.
What is Cloud CDN and Why Does It Exist?
Cloud CDN is a global content delivery network that uses Google's distributed edge caches to accelerate content delivery for web applications, streaming media, and API responses. It is built on Google's global network, which spans over 200+ countries and territories, with over 170 edge points of presence (PoPs) as of 2025. The primary purpose is to reduce latency by serving content from a location geographically closer to the end user, rather than from the origin server. This also reduces load on the origin server and lowers bandwidth costs.
How Cloud CDN Works Internally
Cloud CDN operates as a reverse proxy cache. When a user requests a resource (e.g., an image or API response), the request is routed to the nearest edge PoP via Google's global network. The edge cache checks if it has a valid (non-expired) copy of the resource. If yes, it serves the cached copy directly — this is a cache hit. If no, the edge cache forwards the request to the origin server (which could be a Cloud Storage bucket, an HTTP(S) load balancer, or an external server). The origin responds, and the edge cache stores a copy based on caching rules before sending it to the user. This is a cache miss.
Key components: - Cache key: The identifier used to look up cached content. By default, it includes the request URL, but can be customized to include query parameters, headers, or protocol. - Time-to-Live (TTL): Determines how long a cached object is considered fresh. Default TTL for Cloud CDN is 1 hour (3600 seconds) if the origin does not provide Cache-Control headers. You can set minimum and maximum TTLs. - Cache modes: Cloud CDN supports three cache modes: FORCE_CACHE_ALL (cache all responses regardless of Cache-Control), USE_ORIGIN_HEADERS (respect Cache-Control from origin), and CACHE_ALL_STATIC (cache static content based on file extension). - Negative caching: Cloud CDN can cache error responses (e.g., 404, 500) for a configurable duration to reduce load on the origin. Default is 600 seconds (10 minutes) for 404s. - Signed URLs and signed cookies: Used to restrict access to cached content, allowing only authorized users to access private content.
Default Values and Timers
Default TTL: 3600 seconds (1 hour) for cacheable responses when no Cache-Control is present.
Maximum TTL: Can be set up to 365 days (31536000 seconds).
Minimum TTL: Can be set as low as 0 seconds (no caching).
Error TTL (negative caching): Default 600 seconds for 404, 10 seconds for 502/503/504.
Cache invalidation: You can invalidate cached content by URL prefix or exact path. Invalidation is not instantaneous — it can take up to 5 minutes to propagate globally.
Edge cache size: Not directly configurable; Google manages cache storage automatically.
Configuration and Verification
Cloud CDN is enabled on a backend bucket or backend service associated with an HTTP(S) load balancer. Example gcloud command to create a backend bucket with Cloud CDN enabled:
gcloud compute backend-buckets create my-backend-bucket \
--gcs-bucket-name=my-bucket \
--enable-cdn \
--cache-mode=CACHE_ALL_STATIC \
--default-ttl=3600 \
--max-ttl=86400To verify CDN behavior, you can check response headers:
- Age: How many seconds the object has been in the cache.
- Via: Indicates that the request went through a proxy (e.g., "1.1 google").
- X-Cache: May show "HIT" or "MISS" (though this is not always present).
Interactions with Related Technologies
HTTP(S) Load Balancer: Cloud CDN is tightly integrated with Google's external HTTP(S) load balancer. CDN is configured at the backend service or backend bucket level.
Cloud Storage: Cloud CDN can serve content directly from Cloud Storage buckets, reducing load on Cloud Storage and improving latency.
Cloud Armor: Can be used with Cloud CDN to provide DDoS protection and WAF capabilities. Cloud Armor policies are evaluated at the edge before caching.
Cloud Functions / App Engine: These can serve as origins for Cloud CDN, but caching behavior depends on Cache-Control headers.
Important Exam Concepts
Cloud CDN is only available with external HTTP(S) load balancers (classic or global). It is not available for internal load balancers or TCP/UDP load balancers.
Caching is at the edge — not at the origin. The origin never sees requests that are cache hits.
Cache invalidation is a manual process; you cannot automatically invalidate based on content update.
Signed URLs and signed cookies are used for private content; they are generated using a shared secret key stored in Cloud CDN.
Cloud CDN supports both HTTP and HTTPS, but HTTPS is recommended.
Edge Cases and Exam Traps
Cache-Control: private — This directive tells caches not to cache the response. Cloud CDN respects this unless FORCE_CACHE_ALL is used.
Cache-Control: no-store — Similar, prevents caching.
Set-Cookie header: Responses with Set-Cookie are not cached by default, unless you configure cache keys to ignore cookies.
Query parameters: By default, each unique query string creates a separate cache entry. You can use cache key include/exclude lists to normalize.
Compression: Cloud CDN can cache compressed content, but must ensure consistency (e.g., serve gzip only if client accepts it).
User requests a resource
A user in Tokyo types a URL in their browser. The DNS resolution points to the IP address of the nearest Google edge PoP (e.g., Tokyo). The HTTP request is sent over the internet to that PoP. The request includes headers like Accept-Encoding, Cache-Control, and potentially cookies. The edge server receives the request and begins processing.
Edge cache lookup
The edge PoP computes the cache key based on the request URL and any configured cache key parameters (e.g., query strings, headers). It checks its local cache storage. If a matching object exists and its TTL has not expired, the edge returns the cached object with a 200 status. This is a cache hit. If not, it proceeds to step 3.
Forward request to origin
On a cache miss, the edge PoP forwards the request to the origin server (e.g., a Cloud Storage bucket or a backend service). The origin processes the request and returns a response with headers including Cache-Control, ETag, Last-Modified, and optionally Set-Cookie. The edge PoP receives this response.
Cache the response
The edge PoP evaluates the response headers against the cache mode. If caching is allowed (e.g., Cache-Control: public, max-age=3600), the edge stores the response in its local cache, associating it with the cache key. It sets an expiration time based on the TTL (from Cache-Control or default). The response is then sent to the user.
Serve cached content until expiry
For subsequent requests for the same resource within the TTL, the edge PoP serves the cached copy directly, bypassing the origin. This reduces latency and origin load. If the TTL expires, the edge may revalidate with the origin using If-Modified-Since or If-None-Match headers. If the origin returns 304 Not Modified, the cache is refreshed without downloading the full object.
Scenario 1: Global E-commerce Platform
A large e-commerce company serves product images, CSS, and JavaScript from a Cloud Storage bucket behind an HTTP(S) load balancer with Cloud CDN. The origin is in us-central1, but users are worldwide. Without CDN, a user in Australia experiences 300ms latency for every asset. With Cloud CDN, cache hits occur at the Sydney edge, reducing latency to under 20ms. The company sets cache TTL to 1 hour for images and 1 day for static assets. They use signed URLs for private product PDFs. A common misconfiguration: not setting proper Cache-Control headers on dynamic content like cart status, causing it to be cached and served stale. The fix: use Cache-Control: no-store for dynamic endpoints. In production, they monitor cache hit ratio (target >90%) and use Cloud Monitoring alerts for sudden drops. They also use cache invalidation during product launches to force refresh of new images — but they learned that invalidation takes up to 5 minutes, so they plan updates accordingly.
Scenario 2: Video Streaming Platform
A video streaming service uses Cloud CDN to deliver video segments (HLS/DASH). They enable Cloud CDN on a backend bucket containing video files. They set a very long TTL (30 days) because video content rarely changes. They use signed cookies to authenticate premium users. A common issue: when they update a video's metadata (e.g., title), the old metadata remains cached. They use cache invalidation by prefix (e.g., /videos/123/). They also discovered that Cloud CDN does not support byte-range caching efficiently for large files — it caches entire objects. For large videos, they use a separate CDN specialized for streaming. They monitor bandwidth savings: origin traffic reduced by 80% after CDN implementation.
Scenario 3: API Acceleration
A SaaS company exposes REST APIs behind Cloud CDN to reduce latency for global users. They use cache keys that include the API key header to isolate tenants. They set TTL to 60 seconds for frequently accessed endpoints. They learned that responses with Set-Cookie are not cached by default, so they moved session tokens to headers. They also use Cloud Armor to block malicious traffic before it reaches the cache. A pitfall: they initially forgot to enable Cloud CDN on the backend service, so all traffic went directly to the origin. They now verify CDN status using the gcloud command gcloud compute backend-services describe my-backend-service --global | grep cdn.
What the GCDL Exam Tests (Objective 2.4)
The exam focuses on understanding Cloud CDN's role in reducing latency and offloading origins, its integration with HTTP(S) load balancers, and basic caching behavior. You will NOT be asked to write gcloud commands, but you should recognize the effects of cache modes, TTLs, and invalidation. Key objective codes: 2.4.1 (benefits of CDN), 2.4.2 (caching mechanisms), 2.4.3 (signed URLs/cookies).
Common Wrong Answers and Why Candidates Choose Them
"Cloud CDN can be used with any load balancer." — Wrong. Only external HTTP(S) load balancers (classic or global) support Cloud CDN. Internal LBs and TCP/UDP LBs do not. Candidates confuse 'load balancer' generically.
"Cache invalidation is instantaneous." — Wrong. It takes up to 5 minutes to propagate. Candidates think 'invalidation' means immediate removal.
"Cloud CDN caches responses with Set-Cookie headers by default." — Wrong. By default, responses with Set-Cookie are not cached to avoid serving stale session data. Candidates miss this nuance.
"You can set cache TTL to unlimited." — Wrong. Maximum TTL is 365 days. Candidates assume unlimited.
Specific Numbers and Terms That Appear on the Exam
Default TTL: 3600 seconds (1 hour)
Maximum TTL: 365 days (31536000 seconds)
Negative caching default: 600 seconds for 404
Cache invalidation propagation: up to 5 minutes
Edge locations: 170+ PoPs
Cache modes: FORCE_CACHE_ALL, USE_ORIGIN_HEADERS, CACHE_ALL_STATIC
Edge Cases and Exceptions the Exam Loves
Cache-Control: private — The exam may test that Cloud CDN respects this and does not cache unless forced.
Query parameters — Each unique query string creates a separate cache entry, which can lead to many cache misses. Candidates should know to normalize cache keys.
Signed URLs vs Signed Cookies — Signed URLs are for specific resources; signed cookies are for broader access (e.g., entire directory).
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see an answer that claims Cloud CDN reduces latency by 'compressing data' — that's not the primary mechanism; compression is separate. The primary mechanism is caching at edge. If an answer says 'caches at the origin' — that's wrong; caching is at the edge. If an answer says 'works with TCP load balancer' — eliminate it immediately. Always ask: does this match the reverse-proxy cache model?
Cloud CDN is only available with external HTTP(S) load balancers (global or classic).
Default TTL is 3600 seconds (1 hour) when no Cache-Control header is present.
Maximum TTL is 365 days (31536000 seconds).
Cache invalidation can take up to 5 minutes to propagate globally.
Responses with Set-Cookie are not cached by default.
Cloud CDN has 170+ edge PoPs worldwide.
Use signed URLs for individual resource access control, signed cookies for broader access.
Cache modes: FORCE_CACHE_ALL, USE_ORIGIN_HEADERS, CACHE_ALL_STATIC.
Negative caching caches error responses (default 600s for 404).
Cloud Armor can be used with Cloud CDN for DDoS protection at the edge.
These come up on the exam all the time. Here's how to tell them apart.
Cloud CDN
Integrated with Google Cloud HTTP(S) Load Balancer and Cloud Storage.
Uses Google's global network for edge PoPs.
No additional licensing; pay-as-you-go per GB served.
Cache invalidation via gcloud or API; up to 5 min propagation.
Supports signed URLs and signed cookies natively.
Third-Party CDN (e.g., Akamai)
Requires separate configuration and DNS changes.
May have more PoPs in certain regions (e.g., Akamai has 4,100+).
Often requires contractual minimums or commitment.
Instant cache purge available (often <1 second).
May have more advanced security features (e.g., bot management).
Mistake
Cloud CDN caches all content by default.
Correct
Cloud CDN only caches content that is cacheable according to HTTP rules. Responses with Cache-Control: private, no-store, or Set-Cookie are not cached by default. You must explicitly set cache mode to FORCE_CACHE_ALL to override.
Mistake
Cache invalidation removes content from all edge caches instantly.
Correct
Invalidation requests propagate globally, but it can take up to 5 minutes for all edge caches to purge the content. During that window, stale content may still be served.
Mistake
Cloud CDN works with any Google Cloud load balancer.
Correct
Cloud CDN is only supported on external HTTP(S) load balancers (global and classic). It does not work with internal load balancers, TCP/UDP load balancers, or SSL proxy load balancers.
Mistake
Cloud CDN reduces latency by using faster servers at the origin.
Correct
Cloud CDN reduces latency by serving content from edge locations closer to the user, not by speeding up the origin. The origin may be far away, but the edge cache serves from nearby.
Mistake
You can set TTL to 0 to disable caching for specific content.
Correct
Setting TTL to 0 means the content is still cached but expires immediately, causing revalidation on every request. To truly disable caching, use Cache-Control: no-store or set cache mode to not cache that content.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You enable Cloud CDN by creating a backend bucket that references the Cloud Storage bucket and enabling CDN on that backend bucket. Then associate the backend bucket with an HTTP(S) load balancer. Use gcloud: `gcloud compute backend-buckets create BACKEND_BUCKET_NAME --gcs-bucket-name=BUCKET_NAME --enable-cdn`. The load balancer must be external.
Signed URLs grant access to a specific resource (e.g., a single video file) for a limited time. Signed cookies grant access to multiple resources matching a URL prefix (e.g., all files under /videos/). Signed URLs are simpler for one-off access; signed cookies are better for protecting entire directories. Both use a shared secret key configured in Cloud CDN.
Yes. You configure a custom domain on the HTTP(S) load balancer that is fronting the CDN. You need to create an SSL certificate and map the domain to the load balancer's IP. Cloud CDN then serves content for that domain from edge caches.
Check the response headers. The `Age` header indicates how many seconds the object has been in the cache. The `Via` header includes 'google' if it went through Google's proxy. Some CDN configurations also add a custom header like `X-Cache: HIT` or `X-Cache: MISS` if you configure it.
When the TTL expires, the edge cache marks the object as stale. On the next request, the edge will revalidate with the origin using conditional headers (If-Modified-Since or If-None-Match). If the origin returns 304 Not Modified, the cache refreshes the TTL without downloading the full object. If the origin returns a new object, it replaces the cache.
Yes, Cloud CDN supports HTTP/2 and HTTP/3 (QUIC) for communication between clients and edge PoPs. This improves performance, especially for mobile users. The origin can use HTTP/1.1 or HTTP/2.
Yes. Cloud CDN can be configured with an external backend (e.g., an on-premises server) by using an Internet Network Endpoint Group (NEG) or a serverless NEG. The origin must be reachable from Google's network. However, latency benefits may be less if the origin is far from Google's edge.
You've just covered Cloud CDN and Google's Global Network — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?