An enterprise e-commerce platform hosted on Google Cloud is protected by an external Application Load Balancer and Google Cloud Armor. During high-traffic promotional events, the authentication and checkout APIs experience distributed brute-force and credential stuffing attacks from automated bots. The security engineering team needs to enforce the following defensive requirements: Track request rates per client using an application session cookie named sid. If any client exceeds 100 requests within a 60-second window, ban that client from sending requests for 600 seconds (10 minutes) and return an HTTP 429 Too Many Requests status code. Seamlessly assess automated traffic and block automated bots scoring below 0.5 using reCAPTCHA Enterprise integration before requests reach backend services. Which configuration strategy in Google Cloud Armor satisfies these requirements?

Configure a Cloud Armor security policy with a rate-based rule using the `rate_based_ban` action, setting `enforce_on_key` to `HTTP_COOKIE` with `enforce_on_key_name` as `sid`, `rate_limit_threshold` to 100 requests per 60s, `ban_duration_sec` to 600s, `exceed_action` to `deny(429)`, and add a reCAPTCHA assessment rule denying requests where the bot score is below 0.5.: What Cloud Armor Rate-Based Bans and reCAPTCHA Enterprise Are Google Cloud Armor rate limiting rules allow administrators to control request volume by client keys and apply granular throttling or banning actions. A rate-based ban (rate_based_ban) temporarily blocks all further traffic from a client identifier once request thresholds are exceeded, rather than merely clipping excess traffic. reCAPTCHA Enterprise integration evaluates user interaction risk scores (from 0.0 to 1.0) directly at the Cloud Armor perimeter layer. How it meets the requirements Client tracking via cookie: Setting enforce_on_key to HTTP_COOKIE with enforce_on_key_name configured as sid ensures that rate counting is uniquely tracked against individual user sessions rather than shared NAT IP addresses. Rate threshold and ban duration: Configuring rate_limit_threshold with a count of 100 and interval_sec of 60, combined with action: rate_based_ban and ban_duration_sec: 600, enforces a strict 10-minute ban once the limit is breached. Custom HTTP status: Configuring exceed_action to deny(429) explicitly returns the standard 429 Too Many Requests HTTP error code to offending clients. Bot management with reCAPTCHA: Cloud Armor's reCAPTCHA Enterprise rule evaluation checks token scores and executes a deny action whenever the score is below the 0.5 threshold, filtering out automated credential-stuffing bots. Key advantages and capabilities Session-level granularity: Differentiates clients behind corporate proxies and mobile carrier NAT gateways using session cookies. DDoS and abuse mitigation: Prevents botnets from exhausting backend compute or performing brute-force enumeration attacks. WAF-layer offloading: Evaluates bot risk scores and rate limits at the Google Cloud edge before application pods or instances spend CPU cycles processing payloads. Why this is optimal Using native rate_based_ban alongside reCAPTCHA token evaluation provides full perimeter defense at the global load balancer, minimizing backend resource consumption without requiring custom application middleware.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Armor Rate Limit Ban Recaptcha

Section: Configuring web application firewalls (e.g., Google Cloud Armor).

An enterprise e-commerce platform hosted on Google Cloud is protected by an external Application Load Balancer and Google Cloud Armor. During high-traffic promotional events, the authentication and checkout APIs experience distributed brute-force and credential stuffing attacks from automated bots.

The security engineering team needs to enforce the following defensive requirements:

Track request rates per client using an application session cookie named sid.
If any client exceeds 100 requests within a 60-second window, ban that client from sending requests for 600 seconds (10 minutes) and return an HTTP 429 Too Many Requests status code.
Seamlessly assess automated traffic and block automated bots scoring below 0.5 using reCAPTCHA Enterprise integration before requests reach backend services.

Which configuration strategy in Google Cloud Armor satisfies these requirements?

Configure a Cloud Armor security policy with a rate-based rule using the throttle action, setting enforce_on_key to IP, rate_limit_threshold to 100 requests per 60s, conform_action to allow, and exceed_action to redirect to an external reCAPTCHA verification URL.

Configure a Cloud Armor security policy with a rate-based rule using the rate_based_ban action, setting enforce_on_key to HTTP_COOKIE with enforce_on_key_name as sid, rate_limit_threshold to 100 requests per 60s, ban_duration_sec to 600s, exceed_action to deny(429), and add a reCAPTCHA assessment rule denying requests where the bot score is below 0.5.

Configure VPC Service Controls around the Load Balancer backend service, set up an Event Threat Detection rule for BRUTE_FORCE_SSH, and trigger a Cloud Run function to blacklist offending client IP addresses.

Configure Cloud Armor edge security policies with an allow rule for traffic matching request.headers['User-Agent'], set enforce_on_key to ALL, and configure Cloud Logging alerts to export logs to Google Security Operations for retroactive deduplication.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Armor Rate Limit Ban Recaptcha

Section: Configuring web application firewalls (e.g., Google Cloud Armor).

The security engineering team needs to enforce the following defensive requirements:

Track request rates per client using an application session cookie named sid.
If any client exceeds 100 requests within a 60-second window, ban that client from sending requests for 600 seconds (10 minutes) and return an HTTP 429 Too Many Requests status code.
Seamlessly assess automated traffic and block automated bots scoring below 0.5 using reCAPTCHA Enterprise integration before requests reach backend services.

Which configuration strategy in Google Cloud Armor satisfies these requirements?

Explanations

What Cloud Armor Rate-Based Bans and reCAPTCHA Enterprise Are

Google Cloud Armor rate limiting rules allow administrators to control request volume by client keys and apply granular throttling or banning actions. A rate-based ban (rate_based_ban) temporarily blocks all further traffic from a client identifier once request thresholds are exceeded, rather than merely clipping excess traffic. reCAPTCHA Enterprise integration evaluates user interaction risk scores (from 0.0 to 1.0) directly at the Cloud Armor perimeter layer.

How it meets the requirements

Client tracking via cookie: Setting enforce_on_key to HTTP_COOKIE with enforce_on_key_name configured as sid ensures that rate counting is uniquely tracked against individual user sessions rather than shared NAT IP addresses.
Rate threshold and ban duration: Configuring rate_limit_threshold with a count of 100 and interval_sec of 60, combined with action: rate_based_ban and ban_duration_sec: 600, enforces a strict 10-minute ban once the limit is breached.
Custom HTTP status: Configuring exceed_action to deny(429) explicitly returns the standard 429 Too Many Requests HTTP error code to offending clients.
Bot management with reCAPTCHA: Cloud Armor's reCAPTCHA Enterprise rule evaluation checks token scores and executes a deny action whenever the score is below the 0.5 threshold, filtering out automated credential-stuffing bots.

Key advantages and capabilities

Session-level granularity: Differentiates clients behind corporate proxies and mobile carrier NAT gateways using session cookies.
DDoS and abuse mitigation: Prevents botnets from exhausting backend compute or performing brute-force enumeration attacks.
WAF-layer offloading: Evaluates bot risk scores and rate limits at the Google Cloud edge before application pods or instances spend CPU cycles processing payloads.

Why this is optimal

Using native rate_based_ban alongside reCAPTCHA token evaluation provides full perimeter defense at the global load balancer, minimizing backend resource consumption without requiring custom application middleware.

View source documentation

Professional Cloud Security Engineer

Cloud Armor Rate Limit Ban Recaptcha

Professional Cloud Security Engineer

Cloud Armor Rate Limit Ban Recaptcha

What Cloud Armor Rate-Based Bans and reCAPTCHA Enterprise Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Related questions