Test what you understood — not what you memorized.
QUESTION 01 OF 05
Dan Salmon scraped 207 million Venmo transactions in one month. What made this possible?
Correct — Salmon called a public, unauthenticated endpoint with no rate limit. His script ran for 30 days without any throttling stopping it. He did not exploit a vulnerability in the traditional sense — he called an endpoint that was working exactly as designed, just at a volume the designers never considered constraining.
Not quite — Salmon needed no exploit, no botnet, and no stolen credentials. He called a public API endpoint in a loop. The API had no rate limiting, so his script ran as fast as the network allowed for 30 days. The "attack" was entirely within the designed functionality of the endpoint — just at a scale the team never limited.
QUESTION 02 OF 05
How is API4 Unrestricted Resource Consumption different from a traditional DDoS attack?
Correct — this distinction matters for defense. A DDoS is stopped at the network layer with traffic filtering. API4 attacks pass through network defenses because the requests are valid — they use the right endpoints, the right format, and sometimes valid auth tokens. The defense must be at the application layer: rate limits, quotas, and size caps built into the API itself.
Not quite — the key difference is the type of traffic and where the defense lives. A DDoS sends garbage traffic that can be filtered at the network edge. An API4 attack sends valid requests that the application is designed to process — they just arrive at a volume that exhausts resources. Network filters don't help because the traffic looks legitimate all the way down.
QUESTION 03 OF 05
An API endpoint for sending SMS OTPs has no rate limiting. What are the two risks this creates?
Correct — two distinct harms. First, the API owner's SMS provider bill scales directly with attacker volume — 10,000 unauthorized sends = $100 charge. Second, flooding a specific phone number with OTP texts is an effective harassment/DoS attack against a real person. Both require separate rate limiting: per IP to stop bulk financial attacks, and per target phone number to stop victim flooding.
Not quite — the risks here are financial (the API owner's bill) and harassment (flooding a victim's phone), not authentication bypass or OTP interception. Rate limiting on the OTP endpoint doesn't protect OTP values — it protects the API owner from runaway SMS costs and protects users from having their phones flooded.
QUESTION 04 OF 05
A client sends a GraphQL query with 10 levels of nested relationships. What's the risk if there are no complexity limits?
Correct — in a naive GraphQL implementation, each nested relationship is resolved with an additional database call. 10 levels of nesting on a list of 100 users can generate 100^2, 100^3, or more database queries from a single HTTP request (without DataLoader batching). Even with batching, extreme nesting can exhaust the server. Complexity limits reject the query before execution — the defense happens before any database is touched.
Not quite — GraphQL's N+1 query problem means nested relationships often trigger a separate database query per parent object per level. 10 levels deep on 100 users can generate thousands of database calls. Without complexity limits to reject such queries before execution, a single HTTP request becomes a database saturation attack. The defense is analysis at query parse time, not execution time.
QUESTION 05 OF 05
Why isn't it sufficient to rely on cloud billing alerts to catch API resource abuse?
Correct — billing alerts are reactive by design. They tell you what already happened. An attacker who scripts 100,000 AI inference calls at 3am can generate a $2,000 bill before a morning billing alert fires. Rate limiting is the real-time defense — it prevents the calls from going through. Billing alerts are a valuable backstop for misconfigured limits, but they are not a substitute for enforcement at the API layer.
Not quite — the issue isn't reliability or scope, it's timing. Billing alerts are inherently retrospective — they fire after your budget threshold is hit, which means after the money is spent. A $10,000 overnight attack generates a $10,000 bill before any alert could stop it. Real-time rate limiting is the defense that prevents the calls from being processed in the first place.