A bluebell-wood public API behind API Management is being scraped. How should the developer throttle callers without coding a counter inside the Function?
Select an answer to reveal the explanation.
Short Explanation
Throttling belongs at the gateway. Drop rate-limit, rate-limit-by-key, or quota on inbound in APIM and leave the Function free of homemade counters.
Full Explanation
API Management provides first-class throttling policies—rate-limit, rate-limit-by-key, and quota—that you apply on the inbound section so excessive callers are rejected at the gateway before the bluebell-wood Function or App Service spends compute. That is the AZ-204 pattern for protecting a public API from scrapers without embedding homemade counters in the backend.
Opening anonymous Redis ports so scrapers “self-limit by latency” fails both security and the throttling skill: Redis should not be public, and latency is not a controlled rate or quota policy on APIM.
Replacing APIM with a VM cron that reboots the App Service every minute fails because reboots destroy availability and do not throttle individual callers; they punish every municipal user when scrapers appear.
Publishing the Function URL publicly and relying only on Front Door WAF fails the Domain 5 APIM answer: WAF can help at the edge, but the exam skill here is gateway rate-limit / quota policies on inbound, not bypassing APIM for a raw Function host.
Exam caveat: rate-limit and quota differ—rate-limit is short-window call volume; quota is longer-period allotment—and rate-limit-by-key scopes counters by subscription key, IP, or another expression. Operational check: add an inbound rate-limit or rate-limit-by-key, send a burst that exceeds the threshold, and confirm APIM returns 429 while the Function’s invocation count stays flat for those rejected calls.