Understanding and Using APIs →hardMultiple Select

200-901 Understanding and Using APIs Practice Question

A developer is troubleshooting a REST API integration that intermittently returns HTTP 429 responses. Which TWO practices help the client handle rate limiting correctly? (Choose two.)

⚠ Common exam trap

The trap here is treating a 429 as a fatal error or retrying instantly, when it is a temporary signal that should be answered with a deliberate, measured pause.

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 exponential backoff with jitter so successive retries are spaced further apart and randomized.

Handling 429 responses well means cooperating with the server's throttling signals. Reading Retry-After gives an explicit wait time, while exponential backoff with jitter provides a robust fallback when no such header exists. Tight retry loops, transport downgrades, and abandoning the integration all fail because they either worsen the throttling or give up on recoverable conditions.

Answer analysis

Option-by-option breakdown

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

✗
Treat the 429 as a permanent failure and stop all further API calls from the application.
Why it's wrong here
A 429 indicates temporary throttling, not a permanent error. Abandoning all further calls would prevent the application from completing legitimate work once the limit window resets. The correct behavior is to pause and retry with a sensible strategy, so treating throttling as fatal is an overreaction that fails to resolve the intermittent failures.
✓
Implement exponential backoff with jitter so successive retries are spaced further apart and randomized.
Why this is correct
Exponential backoff increases the delay between retries, and adding jitter randomizes those delays so many clients do not retry in lockstep. This reduces the chance of repeated 429 responses and smooths load on the API. When no Retry-After header is present, backoff with jitter is the recommended fallback strategy, making it a correct practice in this scenario.
✗
Switch the request from HTTPS to HTTP to bypass the rate limiter.
Why it's wrong here
Rate limiting is enforced by the application or gateway based on client identity and request patterns, not by the transport scheme. Downgrading to HTTP would not bypass the limiter and would expose credentials and payloads to interception. It also violates the API's expected security posture, so it is both ineffective and harmful in this scenario.
✓
Read the Retry-After response header and wait the indicated number of seconds before resending the request.
Why this is correct
The Retry-After header is the server's explicit instruction for how long the client should pause before retrying. Honoring it aligns the client with the server's rate-limit window and avoids hammering the API while it is still throttling. This is a standard, correct practice for handling 429 responses and is especially relevant for APIs that enforce per-minute request quotas.
✗
Immediately resend the failed request in a tight loop until a non-429 response is received.
Why it's wrong here
Retrying immediately in a tight loop increases the request rate precisely when the server is asking the client to slow down. It can extend the throttling period, waste resources, and in some APIs trigger stricter limits or temporary blocks. This approach directly contradicts the purpose of a 429 status, so it is not a correct handling practice.

Go deeper

200-901 Understanding and Using APIs Practice Question

Why each option matters

Option-by-option breakdown

Related to this question