PL-900 Practice Question: Demonstrate the capabilities of Power Automate
A Power Automate flow uses the 'HTTP' action to call an external API. The flow fails intermittently with a 429 (Too Many Requests) error. What is the best practice to handle this?
⚠ Common exam trap
PL-900 often tests the misconception that any error should be handled by stopping the flow or changing the endpoint, rather than implementing resilient retry logic for transient issues like throttling.
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
✓
Configure retry policy with exponential backoff
The 429 error indicates the API is rate-limiting requests. Configuring a retry policy with exponential backoff allows the flow to automatically retry after increasing delays, reducing server load and respecting the API's rate limits. This is the standard best practice for handling transient throttling errors in Power Automate.
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 to a different API endpoint
Why it's wrong here
A different endpoint does not address rate limiting; the API's throttling policy applies regardless of which URI is called, and 429 responses would continue. Switching endpoints is tempting when an API is deprecated or returns persistent server errors, but 429 signals request volume, which retry and backoff logic resolves.
- ✗
Add a 'Terminate' action to stop the flow on error
Why it's wrong here
Terminate halts the run on error rather than retrying, so the API call is never completed and the flow fails permanently. It is tempting because Terminate is used to end flows deliberately when a business condition is unmet, but a transient 429 requires the action to be retried after a delay.
- ✓
Configure retry policy with exponential backoff
Why this is correct
A 429 signals the API throttled the flow, so retries must space out over time. Exponential backoff increases the delay between successive attempts, letting the service recover and preventing repeated throttling, which satisfies the intermittent-failure constraint without manual intervention.
- ✗
Reduce the timeout of the HTTP action
Why it's wrong here
A shorter timeout makes the HTTP action abandon the request sooner, increasing failures rather than allowing the API's rate-limit window to reset. Reducing timeouts is tempting for slow endpoints that hang, but 429 responses arrive immediately and demand retry-after delays, not faster abandonment.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-900 question from scratch — 701 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PL-900
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are troubleshooting a Power Automate flow that uses an HTTP action to call a REST API. The flow fails with a '429 Too Many Requests' error. The API has a rate limit of 100 requests per minute. Which strategy should you implement to handle this error gracefully?
hard- ✓ A.Implement retry logic with exponential backoff in the HTTP action settings.
- B.Increase the flow's concurrency setting to process more requests simultaneously.
- C.Use a 'Condition' action to check the status code and ignore 429 errors.
- D.Use the 'Configure Run After' option to skip the action on failure.
Why A: Implementing retry logic with exponential backoff allows the flow to automatically retry the request after a delay that increases with each attempt, which is the standard approach to handle rate limiting (HTTP 429 errors) and reduces server load. Option B is wrong because increasing concurrency would send more requests simultaneously, likely exacerbating the rate limit issue. Option C is wrong because simply ignoring 429 errors means requests are not retried and the action fails. Option D is wrong because 'Configure Run After' can handle failures but does not implement backoff, so it would not effectively manage rate limits.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This PL-900 practice question is part of Courseiva's free Microsoft 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 PL-900 exam.