UiPath-ADAv1 Control Flow 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.

• ✗

  Wait For Element

  Why it's wrong here

  The 'Wait For Element' activity (or 'Element Exists') is used to pause the workflow until a specific UI element appears on the screen. It is not intended for a fixed time delay. While it can have a timeout, its primary purpose is synchronization with an application's state rather than simply waiting for a predetermined number of seconds regardless of the UI.

• ✓

  Delay

  Why this is correct

  The Delay activity is specifically designed to pause the execution for a set duration. It is highly configurable and is the standard tool for adding wait times in a process. Using Delay is considered best practice because it is explicit, visible in the workflow designer, and does not require writing custom code or scripts to achieve a simple pause.

• ✗

  Invoke Code with 'Thread.Sleep(5000)'

  Why it's wrong here

  While 'Thread.Sleep' would technically work, it is generally discouraged in UiPath. It blocks the execution thread in a way that can interfere with the robot's ability to communicate with Orchestrator or handle certain background events. The native 'Delay' activity is preferred as it is managed by the workflow engine and is more 'low-code' friendly than custom script blocks.

• ✗

  Wait

  Why it's wrong here

  There is no activity simply named 'Wait' in the core UiPath activity sets. Developers often confuse this with activities like 'Wait for Job' or 'Wait for Task', which are for completely different purposes (like long-running workflows). For a simple time-based pause, the 'Delay' activity is the correct and only standard activity name used in the Studio designer.