PL-900 Practice Question: Demonstrate the capabilities of Power Automate
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?
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 retry logic with exponential backoff in the HTTP action settings.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement retry logic with exponential backoff in the HTTP action settings.
Why this is correct
Exponential backoff spaces retries progressively, so the flow waits out the 100-requests-per-minute window rather than hammering the API. This satisfies the rate-limit constraint by letting the HTTP action retry after throttling clears, avoiding repeated 429 failures.
- ✗
Increase the flow's concurrency setting to process more requests simultaneously.
Why it's wrong here
Raising concurrency sends requests in parallel, exhausting the 100-per-minute quota sooner and worsening the 429 responses. Concurrency tuning suits high-volume flows against APIs without tight limits, but graceful handling here requires retry-after delays or throttling to stay within the rate limit.
- ✗
Use a 'Condition' action to check the status code and ignore 429 errors.
Why it's wrong here
Ignoring 429 responses discards the call without retrying, so the API request never completes and data is lost. Condition actions are appropriate for branching on business logic, but rate limiting demands honouring the Retry-After header and reissuing the request after a delay, not suppressing the error.
- ✗
Use the 'Configure Run After' option to skip the action on failure.
Why it's wrong here
Skipping the action on failure abandons the API call permanently, leaving downstream steps without the response data. Configure Run After is designed for optional or non-critical steps, but a rate-limited call must be retried after the Retry-After interval so the request eventually succeeds.
Go deeper
Related to this question
About these practice questions
One of 701 original PL-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.