Cloud CDN Study Notes
Cloud CDN accelerates delivery of web content by caching responses at Google's global edge locations close to users, reducing origin load and latency. It works as a feature of the global Application Load Balancer rather than a standalone product you provision separately, which shapes how exam questions describe its setup.
Key facts
- Cloud CDN is enabled on the backend service of a global external Application Load Balancer; there is no separate CDN instance to create or manage.
- Cacheable content is typically static assets such as images, video, JavaScript, and CSS, identified by cacheability rules, Cache-Control headers, and the configured cache mode.
- Cache modes include caching static content automatically, using origin headers to decide cacheability, or forcing all content to be cached regardless of origin directives within limits.
- Default, minimum, and maximum TTL settings on the backend service control how long edge caches hold content before revalidating with the origin.
- Origins can be Compute Engine instance groups, GKE network endpoint groups, or Cloud Storage buckets configured as backend buckets behind the load balancer.
- Cache invalidation removes specific objects or path prefixes from the edge before their TTL expires, useful after publishing corrected or updated content urgently.
- Signed URLs and signed cookies grant time-limited access to private cached content, letting Cloud CDN serve restricted media without making the origin bucket public.
- Negative caching stores error responses such as 404 for short periods, protecting the origin from repeated requests for missing objects during traffic spikes.
- Cloud CDN cache keys can include query strings, headers, and cookies, but including too many dimensions fragments the cache and lowers the hit ratio significantly.
What the exam expects you to know
- Know Cloud CDN requires an Application Load Balancer backend service or backend bucket; it cannot be attached directly to a standalone VM or bucket URL.
- Choose Cloud CDN when the scenario mentions static content, global users, high latency, or origin offload for repeated reads of the same objects.
- Identify cache invalidation as the answer when updated content must appear immediately rather than waiting for the configured TTL to expire naturally.
- Recognise signed URLs as the mechanism for serving private or paid content through the CDN without exposing the origin to unauthenticated users.
- Understand that dynamic, personalised, or uncacheable API responses gain little from Cloud CDN and should not be forced into the cache.
- Remember enabling Cloud CDN is a backend setting, so troubleshooting starts at the load balancer configuration, not at a separate CDN console page.
Cloud CDN vs Cloud Storage Regional Bucket Alone: when to use which
Use Cloud CDN in front of a Cloud Storage backend bucket when users are globally distributed and request the same objects repeatedly, because edge caching cuts latency and origin egress dramatically. Serve directly from a regional bucket when users are concentrated in one region, content changes constantly, or traffic is low enough that cache management adds needless complexity. For the exam, global audience plus static media plus repeated downloads is the classic Cloud CDN pattern, while a single-region internal file share gains nothing from a worldwide edge cache layer. See also the Cloud Storage Regional Bucket Alone notes.
Useful gcloud commands
gcloud compute backend-services update my-backend --enable-cdn --global
gcloud compute backend-buckets create my-bucket-backend --gcs-bucket-name=my-bucket --enable-cdn
gcloud compute url-maps invalidate-cdn-cache my-url-map --path="/images/logo.png"
gcloud compute backend-services describe my-backend --globalCommon exam traps
- Trap: Expecting Cloud CDN to cache dynamic personalised pages effectively. Per-user content fragments the cache and can risk serving one user's data to another if configured carelessly.
- Trap: Forgetting invalidation after an urgent content fix. Without invalidation or a short TTL, users keep receiving the old cached object until it expires.
- Trap: Trying to enable Cloud CDN without a load balancer. A public Cloud Storage URL alone has no Cloud CDN toggle; a backend bucket is required.
- Trap: Making cache keys include every query parameter by default. Uncontrolled query strings destroy hit ratios because each variation is cached as a separate object.
Frequently asked questions
How is Cloud CDN enabled in Google Cloud?
Cloud CDN is enabled as a setting on a backend service or backend bucket of a global external Application Load Balancer. You do not create a standalone CDN resource. Once enabled, cacheable responses passing through that load balancer are stored at Google edge locations and served to subsequent users from cache until the TTL expires or the object is invalidated.
What content benefits most from Cloud CDN?
Static, widely shared content benefits most: images, videos, downloads, JavaScript, and CSS files requested repeatedly by many users in different locations. Highly dynamic or personalised responses benefit least because they cannot be safely reused between users. Exam scenarios pair Cloud CDN with media delivery, software downloads, and static websites rather than transactional APIs or per-user dashboards.
How do signed URLs work with Cloud CDN?
A signed URL contains an expiration time and a cryptographic signature generated with a key configured on the backend service or bucket. Cloud CDN validates the signature at the edge and serves the cached object only until the expiry, without exposing the origin. This pattern delivers private or paid content efficiently while keeping the underlying Cloud Storage bucket non-public.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.