AA Essentials common mistakes
AA Essentials · Understand the traps and how to avoid them.
Classifying a task as 'automatable' purely because it is repetitive, without checking whether the inputs are structured and the decision rules are stable.
Candidates latch onto the word 'repetitive' as the sole criterion and skip the other suitability tests (input variability, exception rate, rule stability), because repetition is the most memorable signal in the study material.
What to do instead
For every suitability question, run a three-part checklist in writing: are inputs machine-readable, are decision rules explicit and stable, and is the exception rate low enough to handle? If any answer is no, the task is a poor automation candidate regardless of repetition.
Treating 'automation' and 'orchestration' as synonyms when answering questions about multi-step processes spanning several systems.
Both terms appear in the same chapters and both involve machines doing work, so candidates collapse them into one concept and pick whichever answer sounds most technical.
What to do instead
Anchor the distinction: automation executes a defined task; orchestration coordinates and sequences multiple automations or services, including error handling and ordering. When a stem mentions sequencing, dependencies, or multiple systems, look for the orchestration answer.
Confusing a rule-based system with a machine-learning model when asked to choose the right approach for a given problem.
Candidates see 'the system decides' and assume AI is involved, missing that explicit if/then logic with deterministic outcomes is rule-based, not learned.
What to do instead
Ask whether the decision logic was written by a human (rules) or inferred from data (model). Also check whether the requirement demands explainability and determinism, which point to rules, versus generalization from examples, which points to ML.
Describing a model's output as a 'fact' or 'answer' rather than a prediction with a confidence level, especially in questions about hallucination or errors.
Everyday language treats software output as authoritative, so candidates default to trusting it and pick answers that overstate reliability.
What to do instead
Adopt the habit of restating model output as 'a prediction that can be wrong'. For hallucination questions, the correct answer almost always involves grounding, verification, or human review, not trusting the output more.
Skipping the trigger design step and jumping straight to writing the action steps when asked to describe how an automation should be built.
Action steps feel like the 'real work' and are more concrete, so candidates describe them first and omit what starts the flow, leaving the design incomplete.
What to do instead
Always start the design with three named elements: trigger (event or schedule), conditions/filters, and actions. If a question asks for the first step in building an automation, it is defining the trigger and its conditions.
Omitting error handling and logging from a proposed automation design, presenting only the happy path.
Candidates mentally simulate the successful run and never consider what happens when a step fails, because failure paths are not visible in a simple walkthrough.
What to do instead
For every design answer, append two lines: what happens on failure (retry, alert, fallback) and what is recorded for later diagnosis. If an answer option includes error handling and yours does not, reconsider.
Hard-coding values such as credentials, file paths, or recipient addresses directly into automation steps instead of using configuration or variables.
Hard-coding works in a quick demo and candidates optimize for the simplest description, not for maintainability or security.
What to do instead
State explicitly that environment-specific values belong in configuration or a secrets store, referenced by the automation. When an option mentions centralized configuration or secret management, it is usually the better answer.
Assuming an automation that works on the test data will behave identically in production without validating edge cases and volume.
Candidates treat 'it ran successfully once' as proof of correctness, conflating a successful test with adequate testing.
What to do instead
Name the test categories explicitly: normal cases, edge cases (empty, malformed, maximum-size inputs), and volume/load. A design answer that includes only normal-case testing is incomplete.
Evaluating an automation proposal only on labor hours saved, ignoring governance, auditability, and change-management requirements.
Cost and time savings are the most quotable benefits, so candidates lead with them and forget that enterprise questions test the non-financial constraints.
What to do instead
For enterprise-context questions, check the answer against four lenses: who owns the automation, how changes are approved, what is logged for audit, and how exceptions are escalated. Include at least one governance element in every recommendation.
Treating a pilot's success as sufficient justification for enterprise-wide rollout without a scaling or ownership plan.
Candidates read 'the pilot succeeded' as the end of the story and select the option that immediately expands scope, missing that pilots are deliberately narrow.
What to do instead
Distinguish pilot from scale-up: before expansion, require named ownership, support and monitoring arrangements, a change-control process, and a plan for handling exceptions at higher volume. Prefer answers that establish these before broadening scope.