UiPath-ADPv1 Attended Automation Practice Question
A developer is building an attended automation that runs on a shared workstation used by several employees. The process must ensure that each employee's personal settings and credentials are used, and that two employees cannot accidentally run the process under the same Windows session at the same time. Which TWO configurations or practices should the developer implement? (Choose two.)
⚠ Common exam trap
The trap here is believing that assigning many users to one machine object automatically isolates their credentials and prevents concurrent runs, when in fact user-mode robot registration plus an explicit single-instance guard is what achieves both.
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
✓
Install the UiPath Robot in user mode so each employee runs the automation under their own Windows account.
Per-user robot installation ensures each employee's Windows identity, profile, and credentials are used, while a single-instance guard such as a mutex prevents two employees from running the same automation at once. Together they address both halves of the requirement on a shared workstation. Machine templates and shared accounts do not deliver personal identity, and background execution is irrelevant to an interactive, desktop-based attended process.
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 robot as a standard machine template and assign all employees to the same machine object.
Why it's wrong here
A standard machine template with multiple users mapped to a single machine object is a valid Orchestrator model, but by itself it does not guarantee that each employee's personal Windows profile and credentials are used, nor does it prevent two employees from running the same process under one session. The isolation requirement is better met by per-user robot installation and connection.
- ✗
Publish the process as a background process so it can run concurrently regardless of the active desktop session.
Why it's wrong here
Background processes are designed for automations that do not interact with the UI and can run without an active desktop session. This scenario involves employees on a shared workstation, so background execution does not address per-user credentials, nor does it prevent two employees from starting the same foreground automation in one session. It solves a different problem than the one described.
- ✓
Install the UiPath Robot in user mode so each employee runs the automation under their own Windows account.
Why this is correct
User-mode installation registers the robot for the signed-in user, so the attended automation executes in that employee's Windows session and uses their credentials, profile, and permissions. This directly satisfies the requirement that each employee's personal settings and credentials apply. It also isolates users from one another because each has a separate robot registration tied to their own account.
- ✗
Use a single shared Windows account for all employees and store credentials in a Windows Credential Store asset.
Why it's wrong here
Sharing one Windows account means all employees run the automation under the same identity, which contradicts the requirement that each employee's personal settings and credentials be used. Storing credentials in an asset does not change the Windows session identity. This approach also makes auditing ambiguous because every run appears to come from the same user.
- ✓
Enable the process to run only when no other instance of it is active, for example by checking a lock file or using a mutex before the main logic.
Why this is correct
Enforcing single-instance execution with a mutex or lock file prevents two employees from running the same process concurrently in a way that could collide. Combined with per-user robot installation, this satisfies the isolation and concurrency requirements. The lock must be acquired before the main logic and released reliably, typically inside a Try Finally, so a crash does not leave the lock held indefinitely.
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.