UiPath-ADPv1 Orchestrator Advanced Usage Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a queue with Max # of Retries set to 3 and a unique reference, then change the process to add each invoice as a queue item.

  Why it's wrong here

  Queue Max # of Retries applies to queue item processing, not to the job itself, and requires the process to use Queues as its input mechanism. The scenario describes a process reading from a network share, not from an Orchestrator queue, and forbids project changes. This configuration would also not produce the specified 10-minute delay between attempts, so it fails both the mechanism and the timing requirement.

• ✓

  On the process's trigger, set the Retry options: Maximum Retries to 3 and Retry Interval to 10 minutes, then save the trigger.

  Why this is correct

  In Orchestrator, a time- or queue-based trigger exposes Retry options where Maximum Retries and Retry Interval can be set independently of the automation project. Setting Maximum Retries to 3 and Retry Interval to 10 minutes makes Orchestrator requeue the same job after a fault, waiting ten minutes between attempts. This meets the requirement without editing the UiPath project and applies uniformly to every job started by that trigger.

• ✗

  Edit the UiPath project's config file to add a Try Catch with a 10-minute delay and a loop counter of 3, then republish the package.

  Why it's wrong here

  Modifying the project and republishing contradicts the explicit constraint that the automation project must not be modified. Even if allowed, embedding retry logic inside the workflow couples business logic to transient infrastructure faults and requires a code change and redeployment for every adjustment. Orchestrator already provides first-class retry settings on triggers, so this approach is unnecessarily invasive and operationally inferior.

• ✗

  Configure the trigger's Execution Target to include a second robot and enable High-Density Robots on the machine template.

  Why it's wrong here

  High-Density Robots and expanding the Execution Target change which machines or robot accounts can run the job; they do not implement retry logic. If the underlying network share is down, adding more robots simply produces additional faults on the same failing resource. This setting is unrelated to scheduling retries after a fault, so it cannot satisfy the requirement to retry up to three times with a fixed delay.