UiPath-ADPv1 Generic Automation Development 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.

• ✗

  Add an Element Exists activity before each interaction to poll for the element and branch on the result.

  Why it's wrong here

  Element Exists returns a Boolean for the presence of an element and does not perform the interaction itself, so it must be paired with a retry loop to be effective. Used indiscriminately before every step it adds duplicated logic and overhead. Modern activities already expose retry and WaitForReady behavior, making a blanket Element Exists check redundant and harder to maintain.

• ✓

  Set the WaitForReady property to Interactive or Complete on activities that need the target to be fully rendered before acting.

  Why this is correct

  WaitForReady controls how long the activity waits for the target application to reach a usable state before executing. Choosing Interactive or Complete ensures the element is rendered and ready, which directly addresses failures caused by acting too early. This is a targeted, condition-based setting rather than an arbitrary pause, so it improves reliability without inflating runtime on every step.

• ✓

  Configure a retry scope around transient UI interactions so that failed attempts are repeated before the workflow throws.

  Why this is correct

  A Retry Scope re-executes its contained activities when an error occurs, which handles intermittent conditions such as a dialog appearing late or a page loading slowly. Combined with a WaitForReady setting, it provides both a readiness check and a recovery path. This is a structured, condition-driven approach to resilience rather than an arbitrary fixed delay, and it keeps transient failures from aborting the whole process.

• ✗

  Increase the Delay After property on individual activities that follow navigation or window switching.

  Why it's wrong here

  Delay After inserts a fixed pause after an activity, which masks timing issues rather than resolving them. It slows every execution regardless of actual readiness and can still fail when the application is slower than the configured delay. A dynamic wait targets the condition that matters, so a fixed post-activity delay is not the recommended practice for making the automation resilient.

• ✗

  Enable the ContinueOnError property on all activities so execution proceeds even when an element is not found.

  Why it's wrong here

  ContinueOnError suppresses exceptions and lets the workflow proceed with invalid state, which can corrupt downstream processing and hide genuine defects. It does not make elements appear sooner; it simply ignores the failure. For a long-running unattended process, silently continuing after a missing element produces incorrect results and makes root-cause analysis much harder than failing fast.