3.1 Network Security and Threat Mitigation
Key Takeaways
- Network Security and Threat Mitigation is the largest CSA-C01 domain, so expect multi-clue scenario questions that ask for the single best Alibaba Cloud control rather than a definition.
- Security groups are stateful instance/ENI-level controls (return traffic is auto-allowed); network ACLs are stateless vSwitch-level controls where inbound and outbound rules must be written separately.
- Cloud Firewall is the central control plane for Internet (north-south) and VPC-to-VPC (east-west) inspection with built-in intrusion prevention (IPS); WAF is scoped to HTTP/HTTPS application attacks.
- Anti-DDoS Origin protects existing Alibaba Cloud public IPs in place (no DNS redesign); Anti-DDoS Pro and Premium use a proxy/CNAME traffic-forwarding model that reroutes traffic to scrubbing centers.
- Anti-DDoS Origin Basic is free with up to ~5 Gbit/s mitigation and triggers blackhole filtering when the per-asset threshold is exceeded; Bot Management and GameShield are niche answers, not WAF or Anti-DDoS replacements.
Match the Control to the Traffic Path
The CSA-C01 exam (Alibaba Cloud Certified Associate: Cloud Security Engineer, the certification that replaced the retired ACA Cloud Security on 13 May 2025) delivers 50 questions in 90 minutes with a passing score of 70 out of 100. Network Security and Threat Mitigation is the heaviest of the five domains, so treat it as scenario-driven. A typical item gives you a workload, a traffic pattern, and a threat, then asks for the single best service or rule layer. Your first move is always to locate the traffic: Internet edge ingress/egress, VPC-to-VPC, intra-VPC, the web application layer, or a public IP under volumetric attack.
Core Decision Table
| Scenario clue | Best control | Why it wins on the exam |
|---|---|---|
| ECS instance or ENI needs allow/deny rules | Security group | Stateful, instance-level; return traffic auto-allowed |
| Whole vSwitch/subnet needs a boundary | Network ACL | Stateless, subnet-level; both directions written |
| Internet boundary or VPC-to-VPC inspection + IPS | Cloud Firewall | Central north-south and east-west policy + logging |
| SQL injection, XSS, HTTP flood, bad bots at L7 | WAF | HTTP/HTTPS application-layer inspection |
| Public IP hit by volumetric flood, keep the IP | Anti-DDoS Origin | In-place scrubbing, no DNS/CNAME redesign |
| Need CNAME redirect to dedicated scrubbing IP | Anti-DDoS Pro/Premium | Proxy forwarding to scrubbing centers |
| Credential stuffing, scraping, scalping | Bot Management | Behavior analysis + challenges |
| Low-latency game server under L4 DDoS | GameShield | SDK-based per-connection game protection |
Stateful vs Stateless, and the L3/L4 vs L7 Split
Do not collapse these products into one generic "firewall" answer; CSA-C01 explicitly tests boundaries. A security group is stateful: if you allow inbound TCP 443, the matching outbound response is permitted automatically, so you rarely write a return rule. A network ACL is stateless at the vSwitch layer: an inbound allow on 443 does not imply the ephemeral-port (1024-65535) outbound reply is allowed, so you must add it explicitly.
A classic trap question describes "return traffic is being dropped despite an inbound allow rule" — the answer is that a stateless network ACL is missing its outbound rule, not that the security group is wrong.
Cloud Firewall is the centralized control plane. It enforces policy and intrusion prevention (IPS) on three planes: the Internet firewall (north-south, asset-level), the VPC firewall (east-west between VPCs over Cloud Enterprise Network or Express Connect), and the internal firewall (between ECS instances). It also gives traffic visibility and access-control logging that security groups alone cannot.
Layered defense for one public web app
- L3/L4 volumetric → Anti-DDoS (Origin or Pro/Premium)
- L7 application → WAF in front of Server Load Balancer
- Network boundary/IPS → Cloud Firewall
- Instance allow-list → security groups on private ECS
This stack is correct architecture, but on a single-best-answer question you pick the one layer the clue names — over-layering is a wrong answer when the stem says "which single service."
A further nuance the exam loves: order of operations at the edge. Traffic to a public web app reaches Anti-DDoS first (it absorbs the volumetric flood at the scrubbing layer), then WAF inspects the surviving HTTP requests for injection and abuse, then the Server Load Balancer distributes clean requests, and finally the security group on each private ECS enforces the instance allow-list. If a question asks "the attack is a SYN flood saturating bandwidth," no WAF rule helps because the link is full before HTTP parsing begins — the answer is an Anti-DDoS tier.
Conversely, a slow application-layer attack (Slowloris, malformed HTTP) passes the volumetric filter untouched and must be stopped at WAF. Sequencing the controls correctly is how you tell adjacent distractors apart.
Anti-DDoS Tiers, Blackholing, and the Web-Layer Tools
The three Anti-DDoS choices are a frequent CSA-C01 distractor set. Anti-DDoS Origin Basic is enabled free for Alibaba Cloud assets and provides up to roughly 5 Gbit/s of mitigation; each protected asset (for example an Internet-facing CLB) has a scrubbing threshold and a blackhole threshold. When inbound attack traffic exceeds the blackhole threshold, Alibaba Cloud null-routes that public IP for a cooldown window so the attack cannot saturate the shared link — the protected IP becomes unreachable until the timer expires.
Anti-DDoS Origin (paid/Native) raises thresholds and lets you keep the existing IP with no architecture change. Anti-DDoS Pro and Premium are proxy products: you point a CNAME at a dedicated scrubbing IP, traffic is forwarded to scrubbing centers, and only clean traffic reaches the origin. The exam phrase "protect an existing public IP without redesigning DNS" maps to Origin; "forward traffic through a dedicated scrubbing address" maps to Pro/Premium.
Web-layer abuse: WAF vs Bot Management vs GameShield
| Threat in the stem | Pick this | Trap to avoid |
|---|---|---|
| SQL injection, XSS, file-inclusion, HTTP flood | WAF managed/custom rules | Not Cloud Firewall (that is L3/L4) |
| Login stuffing, scraping, inventory scalping | Bot Management | Not a generic WAF rate rule alone |
| Latency-sensitive game UDP/TCP under DDoS | GameShield | Not WAF (games are not HTTP) |
| Encrypted data at rest on OSS | KMS/SSE (not network) | Wrong domain entirely |
GameShield uses an SDK and per-device scheduling so legitimate players keep a stable low-latency path while attack traffic is isolated. WAF is strictly HTTP/HTTPS; if the protocol in the question is not web, WAF is wrong. Whenever "automated abuse," "account takeover at scale," or "scalper bots" appears, Bot Management beats both WAF and Anti-DDoS.
A CSA-C01 scenario describes two Alibaba Cloud VPCs connected over Cloud Enterprise Network. The security team needs centralized policy and intrusion prevention for traffic moving between those VPCs. Which control is the best fit?
An administrator allows inbound HTTPS on a vSwitch using a network ACL, but return responses to clients are being dropped. What is the most accurate explanation for CSA-C01?