Cloud Armor for DDoS and WAF in GCP - Time & Space Complexity
We want to understand how the work Cloud Armor does changes as more traffic comes in.
Specifically, how does the number of checks and protections grow when many requests arrive?
Analyze the time complexity of the following operation sequence.
// Cloud Armor evaluates incoming requests
// against security policies and rules
for each incoming request {
check IP against denylist
check request headers and body for threats
apply rate limiting if needed
allow or block the request
}
This sequence shows how Cloud Armor processes each request to protect against attacks.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Checking each incoming request against security rules.
- How many times: Once per request, for every request received.
As the number of requests increases, the number of checks grows in the same way.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 checks |
| 100 | 100 checks |
| 1000 | 1000 checks |
Pattern observation: The work grows directly with the number of requests.
Time Complexity: O(n)
This means the time to process requests grows linearly with how many requests arrive.
[X] Wrong: "Cloud Armor processes all requests instantly, so time does not grow with more requests."
[OK] Correct: Each request needs to be checked, so more requests mean more work and more time overall.
Understanding how security checks scale helps you design systems that stay safe even under heavy traffic.
"What if Cloud Armor used caching to remember safe IPs? How would the time complexity change?"
Practice
Solution
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).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.Final Answer:
To block bad traffic and protect against attacks like DDoS -> Option AQuick Check:
Cloud Armor protects apps from bad traffic = A [OK]
- Confusing Cloud Armor with storage or authentication services
- Thinking Cloud Armor monitors performance instead of security
Solution
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'.Step 2: Eliminate incorrect commands
Firewall rules, instances, and networks are different resources and use different commands.Final Answer:
gcloud compute security-policies create my-policy --description="Protect app" -> Option AQuick Check:
Security policy creation uses 'compute security-policies create' = B [OK]
- Using firewall or instance commands instead of security-policies
- Confusing network creation with security policy creation
{
"expression": "origin.ip == '203.0.113.5'",
"action": "deny(403)"
}Solution
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.Step 2: Understand the effect on matching IP
Requests from 203.0.113.5 will be blocked and receive a 403 Forbidden response.Final Answer:
Requests from 203.0.113.5 will be denied with HTTP 403 -> Option BQuick Check:
IP match with deny(403) means block = D [OK]
- Thinking deny means allow
- Confusing deny with redirect or allow
- Assuming rule applies to all IPs
Solution
Step 1: Verify policy attachment
Cloud Armor policies must be attached to backend services or load balancers to take effect.Step 2: Check other factors
While correct IPs and API enablement matter, the main reason for no blocking is often missing attachment.Final Answer:
The security policy is not attached to the backend service or load balancer -> Option DQuick Check:
Policy must be attached to work = C [OK]
- Forgetting to attach policy to backend service
- Assuming policy works without attachment
- Ignoring API enablement or rule correctness
Solution
Step 1: Understand protection needs
DDoS protection requires blocking bad IPs; web exploits need WAF rules to detect attacks like SQL injection.Step 2: Combine IP rules and WAF
Cloud Armor supports both IP-based rules and preconfigured WAF rules to cover these threats together.Final Answer:
Create IP-based allow/block rules and enable the preconfigured WAF rules -> Option CQuick Check:
Use IP rules + WAF for full protection = A [OK]
- Using only IP rules without WAF for web exploits
- Relying on firewall rules instead of Cloud Armor WAF
- Not enabling blocking, only monitoring
Ready to prove it?
Pass the test and this pattern moves unknown
