Professional Cloud Network Engineer
Cloud CDN accelerates web performance by caching content at Google's global edge points of presence (PoPs) close to end users. Cloud CDN attaches to backend services managed by a global or regional external Application Load Balancer. The load balancer routes incoming requests using a URL map to select a target backend service, which then distributes requests across supported origin types, including managed instance groups (MIGs), Cloud Storage buckets, and Cloud Run services. Network engineers enable edge caching on a backend service using the command line flag --enable-cdn alongside a specified cache mode. Secure delivery is managed at the target HTTP(S) proxy using SSL certificates, custom SSL policies, HTTP/2, HTTP/3, and TLS 1.3 early data.
Cache policies define how Cloud CDN identifies cached assets and determines how long they remain valid before revalidating with the origin. The default cache key contains the full request URL, but engineers can configure custom cache keys to exclude irrelevant query parameters, protocol schemes, or host headers to prevent cache sharding. Origin time-to-live (TTL) settings are controlled via HTTP Cache-Control headers, where max-age sets client and shared cache durations and s-maxage specifically overrides the duration for shared edge caches like Cloud CDN. For Cloud Storage buckets, TTLs are set directly through object metadata, whereas MIGs and Cloud Run define TTLs within application logic. Negative caching allows administrators to cache error responses, such as HTTP 404 or 5xx status codes, for a defined interval to protect origins from traffic spikes during application failures.
Origin authentication and security controls prevent unauthorized clients from accessing origin infrastructure directly and ensure only verified requests receive cached content. For private Cloud Storage buckets, Cloud CDN authenticates requests using an Identity and Access Management (IAM) service account rather than requiring public bucket permissions. Origin firewalls can be configured with IP allowlisting to accept traffic exclusively from Cloud CDN IPv4 (136.124.4.0/22) and IPv6 (2001:4860:4864:a::/64) address ranges. For client-side access restrictions, Cloud CDN evaluates signed URLs and signed cookies to grant time-limited or user-specific access before serving content from the cache. Google Cloud Armor integrates with Cloud CDN in a strict order: edge security policies evaluate requests first, allowed cache hits are served directly, and cache misses pass through backend security policies before reaching origin services.
Cloud Monitoring and Cloud Logging provide operational visibility into edge cache efficiency, network latency, and request resolution states. Cloud Logging captures cache lookups within the HttpRequest payload alongside jsonPayload.cacheId, which identifies the airport-coded edge location fulfilling the request. Network administrators query jsonPayload.statusDetails to evaluate cache performance across three primary states:
StudyCerts
StudyCertsresponse_from_cache or byte_range_caching, where httpRequest.cacheHit=true and content is served directly from edge storage without origin contact.response_from_cache_validated, where the edge cache verifies freshness with the origin using validation headers before serving the response.response_sent_by_backend, where the edge location fetches content directly from the origin backend because no valid cached copy exists.Clients can also inspect the delivery status of individual responses by checking the cdn_cache_status custom response header configured on the load balancer backend.
An internet network endpoint group (NEG) allows an external Application Load Balancer and Cloud CDN to route traffic to endpoints located outside Google Cloud. These external origins include third-party object storage providers such as Amazon Web Services (AWS) S3 or Microsoft Azure Blob Storage, as well as on-premises web servers. The internet NEG configuration defines the fully qualified domain name (FQDN) or public IP address of the external host and communicates using HTTP, HTTPS, or HTTP/2 protocols. When a client request produces a cache miss at an edge PoP, Cloud CDN establishes a connection across the public internet to the external endpoint, retrieves the object, and populates the edge cache for subsequent requests.
Cache modes govern whether Cloud CDN follows origin response headers or applies static caching rules across external backend traffic. Administrators select from three primary cache modes based on workload requirements:
USE_ORIGIN_HEADERS: Instructs Cloud CDN to strictly respect the Cache-Control directives sent by the external backend, avoiding caching when headers are absent.CACHE_ALL_STATIC: Automatically caches static content files even if the origin omits explicit cache headers, making it ideal for standard object storage buckets.FORCE_CACHE_ALL: Caches all responses unconditionally, overriding origin headers that would otherwise prevent caching dynamic data.Custom cache keys optimize caching for external storage by stripping tracking query parameters or domain names that would otherwise divide identical resources into separate cache entries.
Connecting Cloud CDN to third-party storage endpoints requires configuring vendor-specific authentication and cross-origin resource sharing (CORS) rules at the origin. Cloud CDN uses AWS Signature Version 4 (SigV4) to sign requests to private AWS S3 buckets using configured access keys, ensuring the storage bucket rejects requests that do not originate from the CDN. For Azure Blob Storage, access is authenticated using Shared Access Signatures (SAS) or storage account keys. Because Cloud CDN passes origin response headers directly to clients, CORS directives such as Access-Control-Allow-Origin and Access-Control-Allow-Methods must be configured directly on the third-party bucket settings to prevent browser-level security blocks.
Google Cloud Armor applies security filtering to internet NEG traffic using a layered evaluation model that protects external origins from unnecessary load. Edge security policies screen incoming client requests at Google's global edge before Cloud CDN performs a cache lookup, blocking malicious traffic before it reaches cached assets. Backend security policies apply exclusively to dynamic requests and cache misses that pass through edge filtering and require origin retrieval. This two-tier architecture blocks unauthorized requests at the perimeter, preventing malicious traffic from consuming third-party egress bandwidth or compute capacity.
Cache invalidation forces Cloud CDN edge locations to remove cached content before its configured time-to-live expires, whereas content versioning updates assets by changing their identifiers. Invalidation operates under eventual consistency across global edge locations and is subject to rate limits, making it suitable primarily for emergency updates or legal takedowns. Content versioning is the preferred method for standard deployments and involves embedding version strings into paths (such as /v2/app.js), filenames, or cache-key-included query parameters. When a versioned URL is deployed, Cloud CDN treats it as a new cache key, fetching the updated resource immediately without requiring manual cache flushes. When modifying files on an origin that keep the same name, operators should upload the new asset under a temporary name and perform an atomic rename to prevent edge nodes from caching partially uploaded files.
The scope of an invalidation request directly affects origin backend load and edge retrieval performance. Serving content from an edge PoP cache yields low latency (often around 18 milliseconds), while a cache miss requires an origin cache fill that can take hundreds of milliseconds (such as 844 milliseconds). Targeted invalidation clears specific resource URLs, ensuring that only modified files trigger cache fills while unrelated static assets remain cached. In contrast, broad wildcard invalidations or full namespace purges mark extensive directory structures as stale simultaneously. This causes concurrent cache misses across all global edge locations, resulting in traffic surges that can overwhelm backend capacity.
Resilience configurations determine how edge caching nodes manage origin connectivity failures during a cache fill operation. An edge deployment can be configured with primary and failover origins, allowing the system to retry requests when encountering specific error conditions like CONNECT_FAILURE, HTTP_5xx, or NOT_FOUND. Edge caching services attempt up to three retries against the primary origin before failing over to a secondary origin, with a maximum limit of four total attempts across all backends before returning an HTTP 502 (Bad Gateway) or 504 (Gateway Timeout) error. Edge nodes can also be configured with redirectConditions to automatically follow HTTP redirects (such as status codes 301, 302, 303, 307, and 308) from trusted origins, caching the destination content rather than returning the redirect response directly to the client.
136.124.4.0/22) and IPv6 (2001:4860:4864:a::/64) CIDR blocks.USE_ORIGIN_HEADERS to respect origin directives, CACHE_ALL_STATIC to automatically cache static files, and FORCE_CACHE_ALL to cache all content unconditionally.A cache hit (response_from_cache) delivers the requested content directly from the edge PoP without contacting the backend. A validated cache hit (response_from_cache_validated) occurs when the edge node contacts the origin to verify that its cached copy is still fresh using conditional HTTP headers before serving the response to the client.
Cloud CDN uses AWS Signature Version 4 (SigV4) to authenticate against private AWS S3 origins attached via internet NEGs. Network administrators configure AWS access keys within the backend origin settings, and Cloud CDN uses these credentials to generate signed authorization headers for origin requests during cache fills.
Content versioning is preferred because it avoids the rate limits and eventual consistency delays associated with manual cache invalidation. Changing the URL, path, or query parameter creates a unique cache key that instantly fetches new content while allowing older assets to expire naturally without risking cache-wide origin overload.
Prepare and test your skills
Prepare and test your skills