This chapter covers Cloud Armor, Google Cloud's Web Application Firewall (WAF) and DDoS protection service. For the ACE exam, you must understand how Cloud Armor secures HTTP(S) load-balanced applications, its rule language, preconfigured WAF rules, and integration with Cloud CDN and load balancing. This topic typically appears in 5-8% of exam questions, often as part of security scenario questions. You will be tested on configuration, rule evaluation order, and common use cases.
Jump to a section
Imagine a large hotel with a single main entrance. The hotel has a security checkpoint at the door that checks every person entering: is this a registered guest? Does this person have a legitimate reason to be here? This is Cloud Armor's WAF functionality—it inspects each request (person) for malicious intent, like SQL injection (someone trying to pick the lock) or XSS (someone trying to sneak in with a forged ID). Additionally, the hotel has a crowd control system: if too many people try to enter at once (a DDoS attack), the security team can limit the number of people allowed in per minute, or block entire groups from a suspicious bus. This is rate limiting and IP blacklisting. The hotel also keeps a list of known troublemakers (preconfigured rules) and can quickly add new ones based on recent incidents (adaptive protection). Behind the scenes, the hotel's security system logs every entry attempt and sends alerts to the manager (Cloud Logging and Monitoring). If a guest is denied, they get a clear reason (HTTP response code). The hotel's security policies are applied consistently to all entrances (load balancers) and can be updated globally without changing the doors.
What is Cloud Armor?
Cloud Armor is a managed security service that provides WAF and DDoS protection for applications behind Google Cloud external HTTP(S) load balancers or SSL proxy load balancers. It operates at the edge of Google's network, inspecting incoming traffic before it reaches your backend instances. Cloud Armor uses a rule-based engine to allow or deny requests based on conditions such as IP addresses, geographic regions, request headers, and URI paths. It includes preconfigured WAF rules for OWASP Top 10 threats like SQL injection (SQLi) and cross-site scripting (XSS). Additionally, it offers rate limiting and adaptive protection to mitigate DDoS attacks.
How Cloud Armor Works Internally
Cloud Armor is integrated directly into the Google Front End (GFE), which terminates TLS connections and load balances traffic. When a request arrives at a load balancer, Cloud Armor evaluates the request against a set of security policies attached to the backend service or load balancer. The evaluation follows these steps: 1. The request is parsed and attributes like source IP, user-agent, URI, headers, and body are extracted. 2. Each rule in the policy is evaluated in order of priority (lowest number = highest priority). Rules can match on IP ranges, geographic location (geo), or custom expressions using the Common Expression Language (CEL). 3. If a rule matches, its action (allow, deny, or redirect) is applied. Deny actions can return configurable HTTP status codes (e.g., 403, 404, 429). 4. If no rule matches, the default action (allow or deny) is applied. The default is allow by default. 5. For WAF rules, Cloud Armor uses ModSecurity Core Rule Set (CRS) version 3.x to detect malicious payloads. These rules can be configured to block, log, or skip based on sensitivity levels.
Key Components and Defaults
Security Policy: A set of rules attached to a backend service or load balancer. You can have up to 100 rules per policy (soft limit).
Rule Priority: Integers from 0 to 65535. Lower numbers have higher precedence. Gaps in priority are allowed.
Action: allow, deny(status_code), or redirect. Redirect action is used for challenge-based mitigation (e.g., reCAPTCHA).
Preconfigured WAF Rules: Cloud Armor offers rule sets for SQLi, XSS, Local File Inclusion (LFI), Remote File Inclusion (RFI), Remote Code Execution (RCE), and others. These are based on ModSecurity CRS and are updated automatically.
Rate Limiting: You can define rate limits per IP or per IP range using the rateLimit() expression. The default rate limit window is 1 minute. You can also use enforcePerSecondRateLimit() for per-second enforcement.
Adaptive Protection: A machine learning-based feature that learns normal traffic patterns and generates custom rules to block anomalous requests. It requires a training period (typically 24 hours).
Logging: Cloud Armor logs are sent to Cloud Logging. You can enable logging per policy. Logs include rule action, matched rule name, and request metadata.
Configuration and Verification Commands
Cloud Armor is configured via gcloud commands, REST API, or Terraform. Key gcloud commands:
# Create a security policy
gcloud compute security-policies create my-policy --description "My WAF policy"
# Add a rule to deny traffic from a specific IP range
gcloud compute security-policies rules create 1000 \
--action deny-403 \
--src-ip-ranges 203.0.113.0/24 \
--security-policy my-policy
# Add a rule to allow traffic only from certain countries
gcloud compute security-policies rules create 2000 \
--action allow \
--expression "origin.region_code == 'US'" \
--security-policy my-policy
# Attach policy to backend service
gcloud compute backend-services update my-backend-service \
--security-policy my-policy
# Enable logging
gcloud compute security-policies update my-policy --enable-logging
# Verify policy
gcloud compute security-policies describe my-policyInteraction with Related Technologies
Cloud CDN: Cloud Armor policies apply to requests that are served from the CDN cache if the policy is attached to the backend service. However, if a request hits a cached object, Cloud Armor does not re-evaluate it unless the cache entry is stale.
Cloud Load Balancing: Cloud Armor works only with external HTTP(S) load balancers and SSL proxy load balancers. It does not work with internal load balancers or network load balancers.
Cloud NAT and VM-level firewalls: Cloud Armor operates at the edge, before traffic reaches VPC firewall rules. It complements VPC firewall rules but does not replace them.
Identity-Aware Proxy (IAP): Cloud Armor can be used in conjunction with IAP. IAP authenticates users before Cloud Armor evaluation if the load balancer is configured with IAP. Typically, Cloud Armor is used first to block malicious traffic, then IAP verifies identity.
Preconfigured WAF Rules Details
Preconfigured WAF rules are organized into rule sets. Each rule set has a sensitivity level (1-4) that controls how aggressively it blocks. Level 4 is the most sensitive and may cause false positives. You can also use evaluatePreconfiguredWaf() expression to selectively apply rules. For example:
gcloud compute security-policies rules create 3000 \
--action deny-403 \
--expression "evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2})" \
--security-policy my-policyThe rule sets available include:
- sqli-v33-stable (SQL injection)
- xss-v33-stable (cross-site scripting)
- lfi-v33-stable (local file inclusion)
- rfi-v33-stable (remote file inclusion)
- rce-v33-stable (remote code execution)
- methodenforcement-v33-stable (HTTP method enforcement)
- scannerdetection-v33-stable (scanner detection)
- protocolattack-v33-stable (protocol attacks)
- sessionfixation-v33-stable (session fixation)
- java-v33-stable (Java-specific attacks)
- nodejs-v33-stable (Node.js-specific attacks)
- php-v33-stable (PHP-specific attacks)
- cve-v33-stable (CVE-based attacks)
Rate Limiting Details
Rate limiting is implemented using the rateLimit() and enforcePerSecondRateLimit() functions. The syntax:
rateLimit("rate_limit_key", "rate_limit_window", "max_rate", "action_on_exceed")rate_limit_key: Can be {client_ip} or a custom expression.
rate_limit_window: "1m" (1 minute) or "10s" (10 seconds).
max_rate: Integer maximum requests per window.
action_on_exceed: "deny(429)" or "rateBasedBan(86400, 403)" (ban for 86400 seconds).
Example rule that allows 100 requests per minute per IP, then denies for 24 hours:
gcloud compute security-policies rules create 4000 \
--action deny-403 \
--expression "rateLimit('${client_ip}', '1m', 100, 'rateBasedBan(86400, 403)')" \
--security-policy my-policyAdaptive Protection
Adaptive Protection uses machine learning to detect DDoS attacks. It learns normal traffic patterns over a training period (default 24 hours). After training, it can create a custom rule that blocks anomalous traffic. The rule is automatically generated but must be manually enabled. Adaptive Protection is configured via:
gcloud compute security-policies update my-policy \
--enable-adaptive-protectionTo view suggested rules:
gcloud compute security-policies list-adaptive-protection-suggestions my-policyEdge Cases and Exam Traps
Policy attachment: A security policy can be attached to a backend service or directly to a load balancer (global external HTTP(S) load balancer). If attached to a backend service, it applies only to that backend. If attached to the load balancer, it applies to all backends.
Default action: The default action is allow. If you want to deny all by default, you must add a rule with lowest priority (highest number) that denies all, e.g., --action deny-403 --src-ip-ranges *.
Rule order: Rules are evaluated from lowest priority number to highest. A deny rule with priority 1000 will be evaluated before an allow rule with priority 2000. If both match, the deny takes effect.
Preconfigured WAF rules and custom expressions: You can combine preconfigured WAF rules with custom expressions using && or ||. For example, to block SQLi only from outside the US: evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2}) && origin.region_code != 'US'.
Logging: Logging is not enabled by default. You must explicitly enable it per policy. Logs are written to Cloud Logging with log name compute.googleapis.com/security_policy.
Pricing: Cloud Armor charges per policy rule evaluation and per MB of inspected traffic. Preconfigured WAF rules incur additional costs. Rate limiting is included in the base cost.
Integration with Cloud CDN
When Cloud CDN is enabled, Cloud Armor policies are evaluated on cache misses only. For cache hits, the request is served directly from the edge cache without Cloud Armor evaluation. This means that if a request is blocked by Cloud Armor, it will never be cached. However, if a request is allowed and the response is cached, subsequent identical requests will bypass Cloud Armor. To inspect all requests, you can disable caching or set cache policies to force revalidation.
Common Use Cases
Geo-blocking: Deny traffic from specific countries using origin.region_code expression.
IP allowlisting/blocklisting: Using src_ip_ranges in rules.
WAF protection: Enable preconfigured rules for SQLi, XSS, etc.
Rate limiting: Protect APIs from brute force attacks.
DDoS mitigation: Use adaptive protection and rate limiting to absorb volumetric attacks.
Monitoring and Alerts
Cloud Armor metrics are available in Cloud Monitoring. Key metrics:
- compute.googleapis.com/security_policy/request_count: Total requests evaluated.
- compute.googleapis.com/security_policy/blocked_request_count: Requests blocked.
- compute.googleapis.com/security_policy/preview_request_count: Requests that matched a rule in preview mode.
You can create alerts based on these metrics, e.g., when blocked requests exceed a threshold.
Summary of Configuration Steps
Create a security policy.
Add rules with appropriate priority, action, and match conditions.
(Optional) Enable preconfigured WAF rules.
(Optional) Enable rate limiting or adaptive protection.
Attach policy to backend service or load balancer.
Enable logging for troubleshooting.
Monitor and adjust rules based on logs.
Create Security Policy
Begin by creating a Cloud Armor security policy using the gcloud command `gcloud compute security-policies create POLICY_NAME --description "DESCRIPTION"`. A policy is a container for rules. You can have multiple policies, but each backend service or load balancer can only have one policy attached. The policy name must be unique per project. The description is optional but recommended for documentation. No rules are added by default; the default action is to allow all traffic. You can change the default action later.
Add Rules with Priorities
Add rules to the policy using `gcloud compute security-policies rules create PRIORITY --action ACTION --conditions`. Priority is an integer from 0 to 65535. Lower numbers have higher precedence. Actions include `allow`, `deny(403)`, `deny(404)`, `deny(429)`, `deny(502)`, or `redirect`. Conditions can be based on source IP ranges, geographic region (using CEL expression `origin.region_code`), request headers, URI paths, or custom CEL expressions. For example, a rule with priority 1000 that denies traffic from IP range 203.0.113.0/24 with a 403 response. Rules are evaluated in order of priority; the first matching rule determines the action.
Enable Preconfigured WAF Rules
To protect against common web attacks, add a rule that uses `evaluatePreconfiguredWaf()` expression. For example, `evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2})`. This rule will inspect the request body and headers for SQL injection patterns. You can specify sensitivity level (1-4) and choose which rule set to use. You can also combine with other conditions using `&&`. For example, to block SQLi only from outside the US: `evaluatePreconfiguredWaf('sqli-v33-stable') && origin.region_code != 'US'`. Preconfigured rules are updated by Google automatically.
Configure Rate Limiting
Add a rule with the `rateLimit()` expression to protect against brute force or DDoS attacks. The syntax is `rateLimit('${client_ip}', '1m', 100, 'deny(429)')` which allows 100 requests per minute per IP and denies with 429 if exceeded. You can also use `rateBasedBan()` to ban the IP for a longer duration. For example, `rateLimit('${client_ip}', '1m', 100, 'rateBasedBan(86400, 403)')` bans for 24 hours. The rate limit key can be any CEL expression, but typically uses client IP. The window can be 10 seconds or 1 minute.
Attach Policy and Verify
Attach the security policy to a backend service using `gcloud compute backend-services update BACKEND_SERVICE --security-policy POLICY_NAME`. Alternatively, for global external HTTP(S) load balancers, you can attach to the target proxy using `gcloud compute target-https-proxies update PROXY --security-policy POLICY_NAME`. After attachment, traffic to that backend will be evaluated. Verify the policy with `gcloud compute security-policies describe POLICY_NAME`. Check logs in Cloud Logging with filter `resource.type="http_load_balancer"` and `jsonPayload.enforcedSecurityPolicy.name="POLICY_NAME"`. Test with curl from allowed and denied sources.
Scenario 1: E-commerce Platform with Geo-Blocking and WAF
A global e-commerce company uses Cloud Armor to protect its checkout API. They block traffic from countries where they do not do business (e.g., North Korea, Syria) using geo-based rules. They also enable preconfigured WAF rules for SQLi and XSS at sensitivity level 2 to prevent data breaches. Rate limiting is applied to the login endpoint: 10 requests per minute per IP. During a flash sale, they temporarily increase rate limits to avoid false positives. They monitor blocked requests via Cloud Monitoring and adjust rules based on false positives. Misconfiguration: initially they set sensitivity to 4, causing many legitimate users to be blocked, resulting in revenue loss. They learned to start with sensitivity 2 and gradually increase.
Scenario 2: SaaS Application with Adaptive Protection
A SaaS provider offers a web-based document editor. They face occasional DDoS attacks. They enable Adaptive Protection on their security policy. After a 24-hour training period, Cloud Armor suggests a rule that blocks traffic from a specific ISP that is part of a botnet. The security team reviews and enables the rule. They also set up logging and alerts for when blocked traffic spikes. They use rateBasedBan to permanently block IPs that exceed 1000 requests per minute. Performance: Cloud Armor adds minimal latency (sub-millisecond) because it runs on the edge. They ensure their load balancer is global to absorb attacks close to the source.
Scenario 3: Healthcare Portal with Strict Access Control
A healthcare portal uses Cloud Armor to allow only traffic from a list of corporate IP ranges (allowlist). They set the default action to deny and add a rule with priority 1000 to allow specific IP ranges. They also block traffic from countries outside the US. They enable logging to audit all denied requests. They use deny(404) to hide the existence of the portal from attackers. They combine Cloud Armor with IAP for user authentication. Misconfiguration: they forgot to add their own office IP to the allowlist, locking themselves out. They had to use Cloud Shell to update the policy. Lesson: always have a break-glass access method.
The ACE exam tests Cloud Armor under Objective 5.2 'Configure and implement network security controls'. Expect 2-3 questions. Key areas:
Security Policy Attachment: Know that policies can be attached to backend services or target proxies. The exam may ask: 'You want to apply a Cloud Armor policy to all backends of a load balancer. What should you attach the policy to?' Answer: target proxy (global external HTTP(S) load balancer) or backend service (if regional).
Rule Priority and Evaluation: Understand that lower priority numbers are evaluated first. A common trap: a rule with priority 1000 that denies all traffic will block everything even if there is an allow rule with priority 2000. The deny rule matches first.
Preconfigured WAF Rules: Know that they use ModSecurity CRS 3.x. Be able to identify the expression evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2}). The exam may ask which rule set to use for SQL injection.
Rate Limiting Syntax: Memorize rateLimit('${client_ip}', '1m', 100, 'deny(429)'). Know the difference between deny(429) and rateBasedBan(). The exam might ask: 'Which action permanently blocks an IP after exceeding a rate limit?' Answer: rateBasedBan.
Default Action: The default is allow. To deny all by default, you must add a catch-all deny rule with the lowest priority (highest number). The exam may present a scenario where traffic is being allowed unexpectedly; the solution is to add a deny rule with src_ip_ranges *.
Logging: Not enabled by default. Must be enabled per policy. Logs are in Cloud Logging. The exam may ask how to troubleshoot blocked requests.
Adaptive Protection: Requires 24-hour training. It generates suggested rules that must be manually enabled. The exam may ask about the training period.
Common Wrong Answers:
Thinking Cloud Armor replaces VPC firewall rules (it does not; it's complementary).
Assuming Cloud Armor works with internal load balancers (it only works with external HTTP(S) and SSL proxy).
Believing that preconfigured WAF rules are static (they are updated automatically).
Confusing deny(403) with deny(404); deny(404) is used to hide existence, deny(403) indicates access forbidden.
Edge Cases:
If a policy is attached to both backend service and target proxy, the backend service policy takes precedence (only for that backend).
Rate limiting and adaptive protection can be used together, but adaptive protection may generate rules that conflict with rate limiting.
Elimination Strategy: When given a scenario, first identify if the requirement is WAF (SQLi, XSS) or DDoS (rate limiting, adaptive protection). Then check if the solution involves external load balancers. If the option mentions internal load balancer or VPC firewall rules, eliminate it.
Cloud Armor is a WAF and DDoS protection service for external HTTP(S) and SSL proxy load balancers.
Security policies consist of rules with priorities (0-65535); lower numbers are evaluated first.
Default action is allow; to deny all, add a catch-all deny rule.
Preconfigured WAF rules use ModSecurity CRS 3.x and are updated automatically.
Rate limiting syntax: rateLimit('${client_ip}', '1m', 100, 'deny(429)').
Adaptive Protection requires a 24-hour training period before suggesting rules.
Logging must be explicitly enabled per policy; logs go to Cloud Logging.
Cloud Armor does not work with internal load balancers or network load balancers.
Policies can be attached to backend services or target proxies.
Cloud Armor complements VPC firewall rules; it does not replace them.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Armor
Operates at the edge (Google Front End) before traffic enters VPC.
Inspects application-layer data (HTTP headers, body, URI).
Supports WAF rules, rate limiting, geo-blocking.
Works only with external HTTP(S) and SSL proxy load balancers.
Uses CEL expressions for match conditions.
VPC Firewall Rules
Operates at the VM instance level (subnet or instance tags).
Inspects only network and transport layers (IP, ports, protocols).
Supports allow/deny based on IP ranges, protocols, ports.
Works with all VM instances regardless of load balancer.
Uses simple IP/port/protocol rules.
Mistake
Cloud Armor can be used with any type of load balancer.
Correct
Cloud Armor only works with external HTTP(S) load balancers and SSL proxy load balancers. It does not work with internal HTTP(S) load balancers, TCP/UDP load balancers, or network load balancers.
Mistake
The default action of a security policy is to deny all traffic.
Correct
The default action is to allow all traffic. If you want to deny all by default, you must add a catch-all deny rule with the lowest priority (e.g., priority 65535) that denies all traffic.
Mistake
Preconfigured WAF rules are static and never change.
Correct
Preconfigured WAF rules are based on ModSecurity CRS and are automatically updated by Google to protect against new vulnerabilities. You do not need to manually update them.
Mistake
Rate limiting with rateBasedBan permanently blocks an IP address.
Correct
The ban duration is configurable. In the example `rateBasedBan(86400, 403)`, the ban lasts 86400 seconds (24 hours). After that, the IP can make requests again unless it exceeds the rate limit again.
Mistake
Cloud Armor policies are evaluated after the request reaches the backend instance.
Correct
Cloud Armor policies are evaluated at the edge (Google Front End) before the request is forwarded to the backend. This means malicious traffic is blocked before it consumes backend resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Cloud Armor can block or allow traffic based on geographic location using the CEL expression `origin.region_code`. For example, to allow only traffic from the US, use `origin.region_code == 'US'`. You can also use `origin.asn` to filter by autonomous system number. Geo-blocking rules are evaluated at the edge.
Logging is not enabled by default. To enable it, use the gcloud command: `gcloud compute security-policies update POLICY_NAME --enable-logging`. You can also enable it via the Cloud Console. Logs are written to Cloud Logging under the resource type `http_load_balancer` with the log name `compute.googleapis.com/security_policy`.
Both are HTTP status codes returned when a request is denied. `deny(403)` indicates 'Forbidden' and tells the client that access is denied but the resource exists. `deny(404)` indicates 'Not Found' and hides the existence of the resource. Use `deny(404)` if you want to make it harder for attackers to discover endpoints. The exam may ask which status code to use to obfuscate the existence of a service.
Yes, Cloud Armor works with Cloud CDN. However, Cloud Armor policies are evaluated only on cache misses. If a request hits a cached object, it is served directly without Cloud Armor inspection. To inspect all requests, you can disable caching or set cache policies to force revalidation. This is important for security-sensitive applications.
Adaptive Protection uses machine learning to learn normal traffic patterns for your application. It requires a training period of approximately 24 hours. After training, it can detect anomalous traffic and generate a suggested rule to block it. The rule is not automatically enabled; you must review and manually enable it via the Cloud Console or gcloud command `gcloud compute security-policies add-rule`.
The default action of a security policy is `allow`. If no rule matches, the request is allowed. Rule priorities range from 0 to 65535, with 0 being the highest priority. You can leave gaps between priorities. Rules are evaluated in ascending order of priority number (lowest number first). If a matching rule is found, its action is applied and no further rules are evaluated.
No, Cloud Armor only works with external HTTP(S) load balancers and SSL proxy load balancers. It cannot be used with internal load balancers. For internal applications, you should use VPC firewall rules or other security appliances. This is a common exam trap: Cloud Armor is for public-facing applications.
You've just covered Cloud Armor WAF and DDoS Protection — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?