AA Master RPA common mistakes
AA Master RPA · Understand the traps and how to avoid them.
Treating Control Room roles (AAE_User, AAE_Basic, AAE_Admin) as interchangeable and assigning AAE_Admin to developers 'to avoid permission errors'.
Candidates learn that elevated permissions make bots run, so they default to the broadest role instead of mapping least privilege to task, and the exam tests role-to-capability mapping directly.
What to do instead
Memorize the capability boundary of each built-in role (who can create/edit/run/deploy bots, manage users, view audit logs) and practice justifying the minimum role a given persona needs before answering.
Writing a single monolithic task that performs login, data extraction, processing, and reporting in one linear flow.
Candidates optimize for getting a demo working end-to-end and never practice decomposing logic, but the exam rewards modular design with reusable sub-tasks and clear separation of concerns.
What to do instead
Refactor practice bots into a driver task plus callable sub-tasks (login, extract, transform, report) with defined input/output parameters, and rehearse explaining why each boundary exists.
Handling errors only with a blanket try/catch around the whole task and no step-level recovery.
Broad catches suppress failures during development, so candidates never learn to distinguish recoverable from non-recoverable errors or to design retry and compensation logic.
What to do instead
Practice placing error handlers at the step or block level, classifying errors (system, business, application), and defining explicit retry counts, delays, and escalation paths for each class.
Assuming a bot can read files, reach a network share, or open an application because it works on the developer's machine.
Candidates test only in their own interactive session and overlook that unattended bots run under a different device or user context with different permissions and session type.
What to do instead
Before answering deployment questions, explicitly identify the runtime identity, session type (attended vs unattended), and required file/network/application permissions, then verify each against the execution context.
Confusing the Bot Creator, Bot Runner, and Control Room component responsibilities when answering architecture questions.
Candidates use the tools daily but never study the component model, so they attribute scheduling, credential vaulting, or package storage to the wrong tier.
What to do instead
Build a one-page component map (authoring client, runner, control room services, credential vault, repository) and quiz yourself on which component owns each function until it is automatic.
Storing credentials, API keys, or connection strings directly in bot variables or task logic.
It is the fastest way to make a bot work in a lab environment, so it becomes a habit, and candidates then miss questions that test secure credential handling.
What to do instead
Always route secrets through the credential vault or locker and reference them at runtime; practice converting a hard-coded credential bot into a vault-backed one and note every artifact that must change.
Deploying a bot to production without a versioned package, dependency check, or rollback plan.
Candidates treat deployment as 'copy the bot and run it', skipping package dependencies and environment-specific configuration, which the exam probes through release-management scenarios.
What to do instead
Rehearse the full promotion path (dev to test to prod) with versioned packages, documented dependencies, environment-specific config separated from logic, and a defined rollback step.
Ignoring queue and workload design, then answering orchestration questions as if bots run one item at a time.
Single-item demos hide concurrency, locking, and throughput concerns, so candidates cannot reason about work queues, bot pools, or device allocation.
What to do instead
Study how queues distribute work items, how multiple runners consume them, and how device pools are sized; practice estimating throughput and identifying contention points in a multi-bot design.
Skipping input validation and treating business-rule exceptions as technical errors.
Candidates focus on making the happy path work and never separate 'the data is invalid' from 'the system failed', so they design wrong exception branches.
What to do instead
For each bot, enumerate invalid-input and business-exception cases separately from technical failures, and specify distinct handling (reject and log vs retry vs escalate) for each category.
Designing bots with no logging, audit trail, or measurable success criteria, then guessing on governance questions about monitoring and CoE reporting.
Logging feels like overhead during development, so candidates never build the observability mindset the governance domain assumes.
What to do instead
Instrument every practice bot with structured logs at start, key decisions, and end, plus a defined success metric; then practice describing how those logs feed Control Room monitoring and CoE dashboards.