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.

Cloud Armor Rate Limit Ban Recaptcha | Professional Cloud Security Engineer

Cloud Armor Rate Limit Ban Recaptcha

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

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 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.

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 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 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.

Professional Cloud Security Engineer

Cloud Armor Rate Limit Ban Recaptcha

Related questions