Rate Limiting to Stop AI Model DoS Attacks
Short answer
C Rate limiting throttles API request frequency, preventing the brute-force denial-of-service attack against the patient-diagnosis model.
Question
Key Takeaways
The question tests API-level availability protections for AI systems, and the trap is choosing data- or content-focused controls (tokenization, guardrails, prompt firewalls) that do nothing to stop volumetric brute-force traffic.
This CompTIA CySA+ (CY0-001) question tests which security control prevents a brute-force denial-of-service attack against a healthcare AI model exposed through an API. The analysis establishes that rate limiting is the control that throttles request volume, preserving availability and blocking resource-exhaustion attempts.
Common mistake: The most common wrong picks are prompt firewall or model guardrails, because learners associate "AI security" with input filtering; those controls inspect content semantics, not request frequency, so they cannot prevent a flood of legitimate-format API calls from exhausting the model's resources.
Expert Analysis
Why the Answer Is Correct
Rate limiting (C) caps the number of API requests a client can make within a defined time window, so a brute-force or resource-exhaustion flood is throttled before the inference backend saturates. In an API-integrated deployment like this diagnostic model, request-frequency controls are the primary safeguard for the availability property that a DoS attack targets. Compounding controls such as API keys, quotas, and backoff challenges sit on the same layer, which is why rate limiting is the correct preventive control. Kristen8730's observation captures this precisely, noting that it "restricts how frequently the API/model can be called, directly mitigating brute-force/resource-exhaustion attacks."
Why the Other Options Are Wrong
Tokenization (A) protects data at rest and in transit by substituting sensitive values with non-sensitive tokens; it is a data-security control and has no bearing on request volume or service availability. Model guardrails (B) enforce behavioral boundaries such as refusing harmful or out-of-scope outputs, which is relevant to model misuse but not to volumetric attacks. A prompt firewall (D) inspects and filters prompt content for injection or unsafe instructions, again a content-layer control that cannot stop a flood of syntactically valid requests. None of these three mitigate an attack whose mechanism is simply too many calls in too little time.
Community Comment Notes
The single comment aligns with this verdict, with Kristen8730 selecting C and explaining that rate limiting "restricts how frequently the API/model can be called, directly mitigating brute-force/resource-exhaustion attacks." No dissenting comments were posted, so there is no competing rationale to reconcile; the reasoning stands on the technical fit between the attack vector and the control layer.
Official Reference
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question names a DoS or brute-force attack against an API-exposed service, look for the availability-layer control (rate limiting, throttling, or quotas) rather than data-protection or content-filtering options. Map each option to the security property it protects: tokenization and encryption address confidentiality, guardrails and firewalls address integrity/behavior, and rate limiting addresses availability.
Frequently Asked Questions
Why doesn't a prompt firewall stop a brute-force DoS attack on the model API?
Is rate limiting enough to protect an API-integrated AI model?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
Kristen8730 👍 1 Answered CRestricts how frequently the API/model can be called, directly mitigating brute-force/resource-exhaustion attacks.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.