Memory hook: Protocol, exposure, scope, backend.
Must remember
- Choose load balancing by application versus network protocol, proxy versus passthrough, internal versus external, and regional versus global scope. These choices determine supported backend and traffic behavior.
- Application Load Balancers use HTTP-aware routing such as URL maps, host/path rules, redirects and supported traffic splitting/mirroring. Network load balancers address transport-level needs; passthrough preserves different connection properties than a proxy.
- Backend services reference supported managed instance groups or network endpoint groups. Health checks, firewall allowances, balancing capacity, timeouts, draining and session affinity must all agree.
- GKE Gateway/Ingress controllers create managed traffic resources from Kubernetes configuration; container-native NEGs can route to Pod endpoints. Debug both Kubernetes objects and cloud backend health.
- Cloud CDN caches supported origins, including backend buckets and compatible services/NEGs. Cache keys, TTLs, signed access and invalidation determine correctness; never cache personalized content under a shared key accidentally.
- Cloud DNS public zones require registrar delegation; private zones need authorized networks. Forwarding, peering zones, inbound policies and cross-project bindings solve hybrid resolution; avoid forwarding loops and verify return routes.
Review details
Cloud DNS routing policies include supported weighted, geolocation and failover choices. They influence DNS answers, while resolvers cache by TTL and existing sessions can persist. DNSSEC signs authoritative data to support authenticity/integrity validation; it does not encrypt DNS. Correct parent DS records are part of the trust chain; an incorrect DS during migration can cause validation failure even when ordinary records look right.
The external-dns controller can reconcile supported DNS records from Kubernetes resources; use scoped DNS permissions and a clear ownership policy to avoid competing controllers. DNS peering shares resolution from another network; it is not the same as VPC Network Peering exchanging packet routes.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Route /api and /images to different backends | An Application Load Balancer with URL-map rules. |
| On-premises clients need private cloud names | A planned hybrid DNS forwarding path and reachable inbound resolver endpoints. |
Traps
- A DNS zone existing in a project does not mean every VPC can resolve it.
- Session affinity is a performance/behavior setting, not durable state storage.
Active recall
1. Why can a backend stay unhealthy?
Wrong port/path, failed application readiness, missing health-check access or incompatible backend configuration.
2. What should a cache key include?
The request attributes that actually change the response, without unnecessary fragmentation.
3. What does CDN invalidation do?
Removes selected cached content; it does not repair an incorrect origin response.
4. What proves public DNS delegation?
The parent/registrar points to the authoritative nameservers for the zone.
5. Why inspect draining on rollout?
Existing connections need a controlled opportunity to finish before backends disappear.