UiPath-ADPv1 Advanced Data Manipulation 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.

• ✗

  Keep the List(Of String) but sort it once and call BinarySearch for each existence check.

  Why it's wrong here

  Sorting once and using BinarySearch does improve each lookup to logarithmic time, which is a real gain over linear scanning. However, BinarySearch requires the list to remain sorted and returns a bitwise complement when no match is found, so callers must test for a negative result carefully; the failure mode is subtle and error-prone. More importantly, a hash-based lookup is still asymptotically faster and simpler to use correctly, so this is not the best change.

• ✗

  Convert the List(Of String) to a String array and use Array.IndexOf for each existence check.

  Why it's wrong here

  Array.IndexOf performs a linear scan identical in complexity to List.Contains, so the total work remains proportional to the product of checks and records. For 400,000 checks against 200,000 entries this is still on the order of tens of billions of comparisons. Converting the collection type changes memory layout slightly but does not change the algorithmic cost, so the hours-long runtime would persist and the scenario's bottleneck would remain unaddressed.

• ✓

  Load the account codes into a Dictionary(Of String, Boolean) and test existence with ContainsKey for each check.

  Why this is correct

  A Dictionary(Of String, Boolean) keyed by account code uses hashing to locate entries, giving near-constant average lookup time instead of a linear scan. Four hundred thousand ContainsKey calls against 200,000 keys complete in a fraction of the time the List.Contains loop requires, because each check touches roughly one bucket rather than every element. This directly removes the algorithmic bottleneck causing the multi-hour runtime while preserving the same matching logic.

• ✗

  Enable the 'Continue on error' property on the loop and wrap each check in a Try Catch so failed checks are skipped.

  Why it's wrong here

  Wrap-and-skip changes error handling, not lookup performance. Contains does not throw when an item is absent; it simply returns False, so a Try Catch around it adds overhead without altering the linear scan that dominates runtime. Worse, silently skipping checks could produce incorrect invoice matches. This option neither addresses the algorithmic cause of the slowdown nor preserves the correctness of the matching results the workflow must produce.