What's changed: Created Professional Cloud Network Engineer Chapter 3 (Domain 3 "Managed services": load balancing selection internal/external-regional/global-L7/L4, backend services/MIG/NEG/balancing mode/session affinity/health checks/URL maps/global access, GKE Gateway/Ingress, traffic splitting/mirroring/URL rewrites, Cloud CDN origins (MIG/GCS/Cloud Run/internet NEG)/cache invalidation, Cloud DNS public/private zones/split-horizon/geolocation-failover policies/DNSSEC/forwarding zones-server policies/DNS peering/cross-project binding/external-DNS).
3.2Cloud CDN and Cloud DNS
Understand Cloud CDN (supported origins = MIG/Cloud Storage buckets/Cloud Run, external backends (internet NEGs)/third-party storage, cache invalidation) and Cloud DNS (zones/records, migration, routing policies (geolocation/failover), DNSSEC, self-hosted DNS integration (forwarding/server policies), public/private zones and split-horizon, cross-project binding/DNS peering, external-DNS for GKE).
Configure faster content delivery and robust name resolution. CDN reduces latency and load with edge caching; Cloud DNS raises availability and security.
3.2.1Cloud CDN
Enable Cloud CDN on an external Application LB backend to cache content at Google's edge. Origins include managed instance groups, Cloud Storage buckets, and Cloud Run, plus external backends (internet NEGs) and third-party object storage. Control caching with cache modes and TTLs, and on updates drop stale content with cache invalidation. Map "speed up public HTTP delivery = external ALB + Cloud CDN."
3.2.2Cloud DNS
In Cloud DNS, manage records in public zones (internet-facing) and private zones (VPC-internal), and build split-horizon DNS resolving the same name differently inside/outside. For availability/geo optimization, use routing policies: geolocation (respond by source region) or failover (back up when primary fails). Enable DNSSEC to prevent tampering. Integrate on-prem with forwarding zones (cloud→self-hosted DNS) and DNS server policies (inbound/outbound forwarding), and expose private zones to other projects' VPCs with cross-project binding or DNS peering. On GKE, the external-DNS operator auto-manages records from Services/Ingress.
Common: requirement → means. E.g., "speed up public HTTP delivery" = external ALB + Cloud CDN; "drop stale cached content immediately" = cache invalidation; "resolve the same name differently inside/outside" = split-horizon (public/private zones); "respond by source region" = geolocation routing policy; "fail over to backup on primary failure" = failover; "prevent DNS tampering" = DNSSEC; "forward to on-prem DNS" = forwarding zone.
Watch the mix-ups: (1) Forwarding zones (cloud→on-prem queries) vs inbound server policy (on-prem→resolve cloud) are opposite directions. (2) DNS peering (reference a zone from another VPC) vs VPC peering (network connectivity) are different. (3) DNSSEC prevents tampering of public zones—it is not confidentiality.
3.2.3Section summary
- Cloud CDN = edge cache on external ALB backends (MIG/GCS/Cloud Run/internet NEG); updates via invalidation
- Cloud DNS = public/private zones + split-horizon; availability via failover/geolocation policies
- Anti-tamper = DNSSEC; on-prem integration = forwarding zones/server policies; to other VPCs = DNS peering/cross-project binding
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To cache a public HTTPS site's static content at Google's edge to cut latency and origin load, which is best?
Q2. To resolve the same domain to an internal IP from the corporate VPC and a public IP from the internet, which means?
Q3. To switch resolution automatically to a backup endpoint when the primary becomes unhealthy, which Cloud DNS feature?
Q4. To make public-zone DNS responses verifiable against tampering via signatures, which do you enable?
Q5. To forward queries for a specific domain from in-VPC Cloud DNS to an on-prem self-hosted DNS server, which do you use?