Courseiva

SAUTO Practice Question: Using the Cisco Secure Endpoint (formerly AMP for Endpoints) API to query file trajectory…

You are using the Cisco Secure Endpoint (formerly AMP for Endpoints) API to query file trajectory data for a specific SHA-256 hash. The API returns a 429 Too Many Requests status code. What is the most efficient way to handle this in your automation script?

⚠ Common exam trap

SAUTO often tests whether candidates treat 429 as an authentication or configuration problem rather than a rate-limit signal, luring them toward credential refresh or dashboard changes instead of backoff-and-retry.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Implement an exponential backoff strategy with a retry logic.

HTTP 429 Too Many Requests means the client has exceeded the API's rate limit, and the correct, standards-aligned response is to back off and retry. Exponential backoff (e.g., wait 1s, 2s, 4s, 8s, with jitter) with retry logic prevents hammering the API, respects the server's Retry-After header when present, and lets the script eventually succeed once the window resets. This is the recommended pattern in Cisco's Secure Endpoint API documentation and in RFC 6585, which defines 429.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Switch from HTTPS to HTTP to reduce overhead.

    Why it's wrong here

    Rate limits count requests, not bytes or encryption overhead, so switching to HTTP would not reduce 429 responses. The Cisco Secure Endpoint API requires HTTPS anyway, so plain HTTP calls would fail outright, and sending API credentials without encryption would expose them. The right response to a 429 is to slow down and retry, ideally honouring any Retry-After header.

  • ✗

    Increase the API rate limit in the Cisco Secure Endpoint dashboard.

    Why it's wrong here

    API rate limits are set and enforced by the service, per API credential or organisation, and customers cannot raise them by changing a dashboard setting. The dashboard is where you manage API credentials and their read or write scope. When you hit a limit, the script must back off and pace its requests, and cache or batch data to need fewer calls.

  • ✗

    Force an authentication refresh on every request.

    Why it's wrong here

    Refreshing authentication on every request adds extra calls and does nothing about the request rate, so it makes rate limiting worse. Authentication problems produce 401 Unauthorized, which is when credentials or tokens should be renewed. A 429 means valid requests are arriving too quickly, so the fix is to wait and retry with increasing delays.

  • ✓

    Implement an exponential backoff strategy with a retry logic.

    Why this is correct

    Exponential backoff waits progressively longer after each 429, for example 1, 2, 4 and 8 seconds, with random jitter so many clients do not retry at once, and gives up after a set number of tries. If the response includes a Retry-After header or rate-limit reset time, use that value. In Python, urllib3's Retry or the tenacity library implement this pattern.

About these practice questions

This SAUTO question is part of Courseiva's 272-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

You might also like

Similar SAUTO questions

Written by Johnson Ajibi, MSc IT Security

Security Systems Architect · founder of Courseiva

This SAUTO practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAUTO exam.