Palo Alto Networks Certified Security Automation Engineer (PCSAE)IntegrationsHard
A security analyst is developing a custom integration for Cortex XSOAR that interacts with a cloud-based security service. The service's API implements strict rate limiting, returning HTTP 429 (Too Many Requests) errors when exceeded. The integration needs to gracefully handle these errors by waiting and retrying the request. Which strategy is most effective for implementing this retry logic in a custom integration?
- ALog the 429 error and fail the command, leaving manual intervention to the analyst.
- BImmediately retry the request up to 5 times if a 429 error is received.
- CUse an exponential backoff algorithm with jitter, respecting the `Retry-After` header if present.
- DImplement a fixed delay (e.g., 5 seconds) before retrying after a 429 error.
Show answer & explanationAnswer & explanation
Correct answer: C. Use an exponential backoff algorithm with jitter, respecting the `Retry-After` header if present.
Exponential backoff with jitter, combined with respecting the `Retry-After` header, is the most robust and recommended strategy for handling API rate limiting. It prevents overwhelming the API, adapts to server-specified delays, and randomizes retry times to avoid thundering herd problems.
Why the other options are wrong
- A. Failing the command and requiring manual intervention defeats the purpose of automation and is not an effective way to handle transient rate limiting errors.
- B. Immediately retrying multiple times is likely to exacerbate the rate limiting issue and lead to more 429 errors, potentially causing an IP ban.
- D. A fixed delay might still be too short or too long, leading to continued rate limiting or unnecessary delays. It doesn't adapt to the API's actual needs.
Exponential Backoff with Jitter
An algorithm for retrying failed network requests where the wait time between retries increases exponentially, and a small random delay (jitter) is added to prevent all clients from retrying simultaneously.
- Reduces load on overloaded services during retries.
- Prevents 'thundering herd' problem from simultaneous retries.
- Often combined with respecting `Retry-After` HTTP header.
Memory trick: Back off, don't rush, give it a little shake.