Cloud Armor for DDoS and WAF in GCP - Step-by-Step Execution

Process Flow - Cloud Armor for DDoS and WAF

Client sends request

↓

Request hits GCP Load Balancer

↓

Cloud Armor evaluates request

↓

Allowed

↓

Backend service receives request

Requests from clients go through the load balancer where Cloud Armor checks them. Allowed requests go to backend; blocked requests are dropped to protect from attacks.

Execution Sample

GCP

1. Client sends HTTP request
2. Load Balancer receives request
3. Cloud Armor checks rules
4. If request matches block rule, drop it
5. Else, forward to backend

This flow shows how Cloud Armor filters requests to block attacks and allow safe traffic.

Process Table

Step	Request Source IP	Rule Matched	Action Taken	Result
1	198.51.100.23	No rule matched	Allow	Request forwarded to backend
2	203.0.113.45	IP block rule matched	Block	Request dropped
3	198.51.100.23	Rate limit exceeded	Block	Request dropped
4	198.51.100.23	No rule matched	Allow	Request forwarded to backend
5	192.0.2.10	WAF rule matched (SQLi)	Block	Request dropped
6	198.51.100.23	No rule matched	Allow	Request forwarded to backend

💡 Requests stop processing after Cloud Armor decides to allow or block based on rules.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
Request Source IP	-	198.51.100.23	203.0.113.45	198.51.100.23	198.51.100.23	192.0.2.10	198.51.100.23
Rule Matched	-	No rule matched	IP block rule matched	Rate limit exceeded	No rule matched	WAF rule matched (SQLi)	No rule matched
Action Taken	-	Allow	Block	Block	Allow	Block	Allow
Result	-	Request forwarded to backend	Request dropped	Request dropped	Request forwarded to backend	Request dropped	Request forwarded to backend

Key Moments - 3 Insights

Why does a request get blocked even if the IP is not on a block list?

Because Cloud Armor also uses other rules like rate limiting and WAF rules (see steps 3 and 5 in execution_table) that can block requests based on behavior, not just IP.

What happens to requests after Cloud Armor blocks them?

Blocked requests are dropped immediately and do not reach the backend service, as shown in the 'Result' column for blocked steps.

Can a request be allowed if it matches some rules?

No, if a request matches a block rule, it is dropped. Only requests that do not match any block rules are allowed (see steps 1, 4, and 6).

Visual Quiz - 3 Questions

Look at the execution_table, what action is taken at step 2 for IP 203.0.113.45?

A Block

B Allow

C Rate limit

D Forward

💡 Hint

Check the 'Action Taken' column at step 2 in the execution_table.

At which step does a WAF rule block a request?

A Step 3

B Step 1

C Step 5

D Step 6

💡 Hint

Look for 'WAF rule matched' in the 'Rule Matched' column in the execution_table.

If the rate limit rule was removed, what would happen at step 3?

A Request would still be blocked

B Request would be allowed

C Request would be dropped for IP block

D Request would cause an error

💡 Hint

Refer to the 'Rule Matched' and 'Action Taken' columns at step 3 in the execution_table.

Concept Snapshot

Cloud Armor protects apps by checking incoming requests.
It blocks bad traffic like DDoS or attacks using rules.
Requests pass through load balancer, then Cloud Armor.
If a request matches block rules, it is dropped.
Allowed requests go to backend services safely.

Full Transcript

Cloud Armor works by inspecting incoming requests at the load balancer. It uses rules to detect bad traffic such as IP blocks, rate limits, or web attack patterns. When a request arrives, Cloud Armor checks if it matches any block rule. If yes, the request is dropped and does not reach the backend. If no rules match, the request is allowed and forwarded. This protects backend services from overload and attacks. The execution table shows different requests and how Cloud Armor decides to allow or block them based on rules. Variables like source IP, matched rule, and action change step by step. Key moments clarify why some requests are blocked even without IP blocks and what happens after blocking. The visual quiz tests understanding of these steps and rule effects.

Practice

1. What is the main purpose of Google Cloud Armor in protecting your applications?

easy

A. To block bad traffic and protect against attacks like DDoS

B. To store application data securely

C. To manage user authentication and login

D. To monitor application performance metrics

Solution

1. Step 1: Understand Cloud Armor's role

   Cloud Armor is designed to protect applications from harmful traffic and attacks such as Distributed Denial of Service (DDoS).

2. Step 2: Compare options

   Options B, C, and D describe other services like storage, authentication, and monitoring, which are not Cloud Armor's main function.

3. Final Answer:

   To block bad traffic and protect against attacks like DDoS -> Option A

4. Quick Check:

   Cloud Armor protects apps from bad traffic = A [OK]

Hint: Cloud Armor blocks bad traffic and DDoS attacks [OK]

Common Mistakes:

• Confusing Cloud Armor with storage or authentication services
• Thinking Cloud Armor monitors performance instead of security

2. Which of the following is the correct way to create a Cloud Armor security policy using gcloud CLI?

easy

A. gcloud compute security-policies create my-policy --description="Protect app"

B. gcloud compute firewall-rules create my-policy --description="Protect app"

C. gcloud compute instances create my-policy --description="Protect app"

D. gcloud compute networks create my-policy --description="Protect app"

Solution

1. Step 1: Identify correct gcloud command for Cloud Armor policy

   The command to create a Cloud Armor security policy is under 'compute security-policies create'.

2. Step 2: Eliminate incorrect commands

   Firewall rules, instances, and networks are different resources and use different commands.

3. Final Answer:

   gcloud compute security-policies create my-policy --description="Protect app" -> Option A

4. Quick Check:

   Security policy creation uses 'compute security-policies create' = B [OK]

Hint: Cloud Armor policies use 'compute security-policies create' command [OK]

Common Mistakes:

• Using firewall or instance commands instead of security-policies
• Confusing network creation with security policy creation

3. Given this Cloud Armor rule snippet, what action will be taken for requests from IP 203.0.113.5?

{
  "expression": "origin.ip == '203.0.113.5'",
  "action": "deny(403)"
}

medium

A. Requests from 203.0.113.5 will be allowed

B. Requests from 203.0.113.5 will be denied with HTTP 403

C. Requests from all IPs except 203.0.113.5 will be denied

D. Requests from 203.0.113.5 will be redirected

Solution

1. Step 1: Analyze the rule expression and action

   The rule matches requests where the IP is exactly '203.0.113.5' and denies them with HTTP status 403.

2. Step 2: Understand the effect on matching IP

   Requests from 203.0.113.5 will be blocked and receive a 403 Forbidden response.

3. Final Answer:

   Requests from 203.0.113.5 will be denied with HTTP 403 -> Option B

4. Quick Check:

   IP match with deny(403) means block = D [OK]

Hint: deny(403) blocks matching IPs with forbidden response [OK]

Common Mistakes:

• Thinking deny means allow
• Confusing deny with redirect or allow
• Assuming rule applies to all IPs

4. You created a Cloud Armor security policy but it is not blocking malicious traffic as expected. What is a common mistake to check?

medium

A. The Cloud Armor API is enabled in the project

B. The policy rules have correct IP addresses

C. The firewall rules allow all traffic

D. The security policy is not attached to the backend service or load balancer

Solution

1. Step 1: Verify policy attachment

   Cloud Armor policies must be attached to backend services or load balancers to take effect.

2. Step 2: Check other factors

   While correct IPs and API enablement matter, the main reason for no blocking is often missing attachment.

3. Final Answer:

   The security policy is not attached to the backend service or load balancer -> Option D

4. Quick Check:

   Policy must be attached to work = C [OK]

Hint: Attach policy to backend service or load balancer to activate [OK]

Common Mistakes:

• Forgetting to attach policy to backend service
• Assuming policy works without attachment
• Ignoring API enablement or rule correctness

5. You want to protect your web app from both DDoS attacks and common web exploits. Which combination of Cloud Armor features should you use?

hard

A. Use Cloud Armor only for DDoS, and rely on firewall rules for web exploits

B. Only create IP-based allow/block rules without WAF

C. Create IP-based allow/block rules and enable the preconfigured WAF rules

D. Use Cloud Armor to monitor traffic but not block anything

Solution

1. Step 1: Understand protection needs

   DDoS protection requires blocking bad IPs; web exploits need WAF rules to detect attacks like SQL injection.

2. Step 2: Combine IP rules and WAF

   Cloud Armor supports both IP-based rules and preconfigured WAF rules to cover these threats together.

3. Final Answer:

   Create IP-based allow/block rules and enable the preconfigured WAF rules -> Option C

4. Quick Check:

   Use IP rules + WAF for full protection = A [OK]

Hint: Combine IP rules with WAF for best protection [OK]

Common Mistakes:

• Using only IP rules without WAF for web exploits
• Relying on firewall rules instead of Cloud Armor WAF
• Not enabling blocking, only monitoring