Google ACE Practice Question: A Cloud CDN cache is serving stale content after…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Wait for the CDN TTL to expire — cached content automatically refreshes

  Why it's wrong here

  Waiting for the TTL to expire is technically a valid way to refresh cached content, but it is inherently passive and unpredictable. Cloud CDN honors the Cache-Control headers set by the origin (Cloud Storage), so if the bucket's TTL is set to a long duration, users could continue to receive stale content for hours or days. This approach is acceptable only when the content change can tolerate the full TTL window; for immediate freshness, you must actively purge the cache. Cache invalidation overrides TTL by removing matching cached objects so the next request is forwarded to the origin for a fresh fetch.

• ✓

  Run a CDN cache invalidation for the affected URL paths

  Why this is correct

  Running a CDN cache invalidation is the correct and intended way to immediately refresh stale content. Use the gcloud command `gcloud compute url-maps invalidate-cdn-cache [URL_MAP] --path=[PATH_PATTERN]` to purge all matching cached objects from Cloud CDN's edge caches. After invalidation, the next request for that path is forwarded to the Cloud Storage origin, which returns the fresh content and repopulates the cache. This approach is non-destructive, immediate, and highly targeted, allowing you to refresh only the URLs that changed while preserving cached responses for all other paths. Keep in mind that invalidation propagates across edge locations in a few seconds, so it is the best choice when time-sensitive content must be updated without origin disruption or unnecessary cost.

• ✗

  Delete and recreate the Cloud Storage bucket — CDN will detect the new bucket as a fresh origin

  Why it's wrong here

  Deleting and recreating the Cloud Storage bucket is both destructive and completely ineffective for CDN cache refresh. The CDN cache key is based on the URL path, not the origin bucket's identity or name, so a new bucket will not clear existing cached entries—the edge nodes would still serve the old content from the previous bucket. Furthermore, globally unique bucket names may not be immediately reusable, and deleting a bucket that is actively being served will cause 404 errors and downtime. The intended, non-disruptive method is to run a CDN cache invalidation, which purges only the affected paths without touching the origin.

• ✗

  Disable Cloud CDN temporarily — all users will hit the origin until CDN is re-enabled

  Why it's wrong here

  Disabling Cloud CDN temporarily means all requests will bypass the cache and go directly to Cloud Storage, causing a sudden spike in origin load, latency, and egress costs. This also changes the backend service configuration, and when CDN is re-enabled, previously cached entries may still be served if their TTL hasn't expired—disabling the service does not automatically clear the cache. Moreover, you loose the performance benefits of CDN for all other content, not just the affected paths. A targeted cache invalidation is surgically scoped to the URL paths that changed, so only those objects are refreshed while the rest of the cache continues to serve requests efficiently.

Go deeper

Related to this question