The Final Granularity: reCAPTCHA, Cache Invalidation & IPv6 Load Balancing

Every exam has a handful of questions that test extremely specific, granular features. These are not the “big concept” questions—they are the ones that separate a score of 75% from 90%. This article covers the niche details that are easy to overlook but appear with surprising regularity on the PCNE exam.

reCAPTCHA Enterprise with Cloud Armor

Cloud Armor’s bot management integrates with reCAPTCHA Enterprise, but the integration model is specific:

  1. reCAPTCHA Action Tokens: Embedded in the user’s browser, these tokens carry a risk score (0.0 = likely bot, 1.0 = likely human).
  2. Cloud Armor Evaluation: You create a Cloud Armor rule that evaluates the reCAPTCHA token score:
    • Score ≥ 0.7 → Allow.
    • Score < 0.3 → Block.
    • Score between 0.3 and 0.7 → Redirect to a CAPTCHA challenge.
  3. No Backend Changes: The token is evaluated at the Google edge by Cloud Armor. Your backend application does not need to call the reCAPTCHA API—it is already handled.

This is the exam-critical distinction: reCAPTCHA with Cloud Armor is evaluated at the edge (before the request reaches your backend), not at the application layer.

Cloud CDN Cache Invalidation: The Details
Invalidation Scope
  1. Path-specific: Invalidate /static/logo.png.
  2. Wildcard: Invalidate /static/* (all objects under the path).
  3. Host-specific: Invalidate all content served for cdn.example.com.
Invalidation Limits
  1. You can issue invalidation requests at a limited rate (typically one per minute per URL pattern).
  2. Invalidation propagates asynchronously—it is not instant across all PoPs. Expect propagation within a few minutes.
The Alternative: Versioned URLs

Instead of invalidating cached content, many teams use versioned URLs:

  • /static/logo-v2.png instead of /static/logo.png.
  • The new URL is a new cache key, so it is fetched fresh. The old URL expires naturally based on its TTL.

This approach avoids invalidation entirely and is the recommended best practice for frequently changing assets.

IPv6 Load Balancing

Google Cloud load balancers support dual-stack (IPv4 + IPv6) configurations:

  1. External HTTP(S) LB: You can assign both an IPv4 and an IPv6 address to the forwarding rule. IPv6 clients connect via the IPv6 address; IPv4 clients use the IPv4 address.
  2. Backends remain IPv4: Even if clients connect via IPv6, the load balancer can proxy the connection to IPv4 backends. The LB handles the translation.
  3. IPv6 health checks: Health check probes can be sent over IPv6 if the backend supports it.
The Subnet Requirement

To enable IPv6 on a load balancer, the subnet must be configured with IPV4_IPV6 stack type. You cannot retroactively add IPv6 to an IPv4-only subnet—you must recreate it or create a new one.

DNS Integration with External DNS Operator for GKE

For GKE clusters that need to automatically register Kubernetes Services and Ingresses in Cloud DNS, the external-dns operator watches for Kubernetes resources and creates corresponding DNS records in Cloud DNS zones.

  1. Deploy external-dns as a Kubernetes Deployment.
  2. Configure it to watch for Ingress and Service resources with specific annotations.
  3. It creates A records in your Cloud DNS Managed Zone automatically.

This eliminates manual DNS record management for dynamic GKE environments.

Putting it Together: A Pro-Engineer View

Imagine your e-commerce platform needs bot protection on the checkout page, instant content updates for flash sales, and IPv6 support for mobile users. You integrate reCAPTCHA Enterprise with Cloud Armor—bots are filtered at the edge with zero backend overhead. You use versioned URLs for product images (/img/product-v3.jpg) so CDN cache is always fresh without invalidation delays. Your Global LB has dual-stack addressing, so mobile users on IPv6-only carriers can reach your site. And external-dns in your GKE cluster automatically publishes DNS records for every new microservice. Every granular feature, precisely applied.

Related Posts