UiPath-ADPv1 Resource Management Practice Question
A developer is building a UiPath automation that processes insurance claims. The process must read each claim from a queue, validate the claim data against a web service, and then update the claim status in a legacy system. The validation step occasionally encounters a temporary network timeout, and the developer wants the transaction to be retried automatically up to three times before being marked as failed. The developer has configured the Orchestrator queue with Max Retry = 3. Which activity or configuration should the developer use to ensure that the retry count is respected and the transaction is retried correctly?
⚠ Common exam trap
The trap here is assuming that a Retry Scope activity or re-adding the item is needed for queue retries, when actually the queue's Max Retry setting works automatically when the transaction is marked as Failed.
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
✓
Set the queue's Max Retry to 3 and use the Set Transaction Status activity with the status Failed in the catch block, allowing Orchestrator to automatically retry the transaction.
Orchestrator queues support automatic retries when a transaction is marked as Failed. The Max Retry property defines how many times a failed item will be retried. The developer must use Set Transaction Status with the Failed status in the catch block to trigger this mechanism. This ensures the item is retried up to the configured limit without creating duplicate queue items or relying on local retry logic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the queue's Max Retry to 3 and use the Postpone Transaction Item activity to delay the transaction by a fixed time before retrying.
Why it's wrong here
Postpone Transaction Item is used to delay the processing of a transaction item until a specified date and time, but it does not trigger automatic retries. It is typically used for items that are not ready to be processed. The Max Retry setting is only honored when an item is marked as Failed, not when it is postponed, so this approach would not achieve the desired retry behavior.
- ✗
Use the Get Transaction Item activity inside a Retry Scope activity with the NumberOfRetries property set to 3.
Why it's wrong here
The Retry Scope activity retries the activities it encloses when an error occurs, but it does not interact with Orchestrator queue retry settings. Setting NumberOfRetries to 3 here would cause the entire enclosed sequence to retry locally, potentially duplicating the Get Transaction Item call and bypassing the queue's built-in retry mechanism. Queue retries are managed by Orchestrator, not by a Retry Scope inside the process.
- ✗
Use the Add Queue Item activity to re-add the claim to the queue after a failure, and rely on the queue's Max Retry setting to limit retries.
Why it's wrong here
Add Queue Item creates a new queue item, not a retry of the existing one. The Max Retry setting applies only to the original item when it is marked as Failed. Re-adding the item would create a separate transaction with its own retry count, potentially leading to duplicate processing and bypassing the intended retry limit for the original claim.
- ✓
Set the queue's Max Retry to 3 and use the Set Transaction Status activity with the status Failed in the catch block, allowing Orchestrator to automatically retry the transaction.
Why this is correct
When a queue item is marked as Failed via Set Transaction Status, Orchestrator checks the queue's Max Retry setting. If the item's retry count is below Max Retry, Orchestrator resets the item to New and increments the retry count, making it available for reprocessing. This leverages the native queue retry mechanism, ensuring the transaction is retried up to three times before being permanently failed.
About these practice questions
One of 276 original UiPath-ADPv1 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official UiPath exam blueprint
This UiPath-ADPv1 practice question is part of Courseiva's free UiPath 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 UiPath-ADPv1 exam.