AWS AI Practitioner common mistakes
AWS AI Practitioner · Understand the traps and how to avoid them.
Treating AI, ML, deep learning, and generative AI as interchangeable labels and picking whichever option sounds most advanced, instead of mapping each scenario to the correct level of the hierarchy.
Marketing language blurs the terms, and the exam deliberately offers options where a broader or narrower term is technically wrong for the described system (for example calling a rules-based classifier 'generative AI').
What to do instead
Before answering, restate the scenario in one sentence and classify it: is there learning from data (ML), neural networks with many layers (deep learning), or a model that produces new content such as text or images (generative AI)? Eliminate any option whose term is broader or narrower than that classification, and be able to state that generative AI is a subset of deep learning, which is a subset of ML, which is a subset of AI.
Confusing supervised, unsupervised, and reinforcement learning by focusing on the data format rather than on whether labels exist and what signal drives learning.
Candidates memorise example algorithms (clustering equals unsupervised) but freeze when the scenario describes a business problem in plain language, such as grouping customers without prior categories or rewarding an agent for winning a game.
What to do instead
Ask two questions for every scenario: are the training examples labelled with the correct answer, and is the model learning from trial-and-error reward? Labelled equals supervised (classification or regression); unlabelled structure-finding equals unsupervised (clustering, anomaly detection); reward-driven sequential decisions equal reinforcement learning. Anchor each answer to that decision tree rather than to algorithm names.
Assuming a foundation model already knows proprietary or current facts, and choosing an answer that skips retrieval or fine-tuning when the scenario requires company-specific or up-to-date knowledge.
The word 'foundation' suggests completeness, and candidates underestimate that model knowledge is frozen at training time and limited to public data.
What to do instead
Whenever a scenario mentions internal documents, recent events, or verifiable citations, look for an option that supplies external context at inference time, such as retrieval augmented generation over a knowledge base, rather than relying on the model's parameters. Reserve fine-tuning for changing behaviour, style, or task format, and treat 'the model will already know it' as a distractor.
Mixing up fine-tuning, retrieval augmented generation, and prompt engineering when the question asks for the most appropriate customisation approach under constraints such as cost, latency, or data volume.
All three adapt a model to a task, so candidates pick the most powerful-sounding one instead of matching the technique to the constraint described.
What to do instead
Build a mental table: prompt engineering changes instructions only, needs no training, and is cheapest and fastest to iterate; retrieval augmented generation adds external knowledge without changing weights and suits factual grounding and freshness; fine-tuning updates weights, needs labelled examples and compute, and suits consistent style, format, or domain behaviour. Then reread the constraint words in the stem (no labelled data, must cite sources, must minimise cost) and let them select the row.
Answering temperature and inference-parameter questions with intuition about 'more creativity is better' instead of the specific behaviour each parameter controls.
Parameters such as temperature, top-p, and maximum length sound similar, and candidates have not practised predicting output changes from parameter changes.
What to do instead
Memorise the direction of each effect: higher temperature increases randomness and diversity while lower temperature makes output more deterministic and repeatable; top-p restricts sampling to a cumulative probability mass; maximum length caps output tokens and can truncate responses. For each scenario, identify whether the requirement is consistency, variety, or length control, then choose the single parameter that governs it.
Choosing a model by benchmark reputation alone when the scenario supplies concrete constraints such as latency, cost per token, context window, or modality.
Candidates default to the largest or most famous model, missing that the exam tests matching model characteristics to workload requirements.
What to do instead
Extract every constraint from the stem into a checklist (input modality, output modality, context length, latency budget, cost sensitivity, data residency). Eliminate any option that violates a hard constraint first, then compare survivors on the remaining trade-offs. Remember that smaller models are often correct answers for high-volume, low-complexity tasks, and that multimodal requirements immediately exclude text-only models.
Treating responsible AI as a single compliance checkbox rather than distinguishing bias, fairness, explainability, privacy, safety, and hallucination as separate concerns with separate mitigations.
The principles overlap in casual discussion, so candidates match a mitigation to the wrong principle, for example citing transparency for a harmful-content problem.
What to do instead
For each scenario, name the harm in one phrase before looking at the options: skewed outcomes across groups (bias and fairness), inability to justify a decision (explainability), exposure of personal data (privacy), offensive or dangerous output (safety), fabricated facts (hallucination), or undisclosed AI use (transparency). Then select the mitigation that targets that named harm, and reject options that address a different principle even if they are generally good practice.
Assuming that removing sensitive attributes such as gender or ethnicity from training data automatically eliminates bias.
It feels like an obvious privacy and fairness fix, but correlated proxy features can still encode the excluded attribute, producing discriminatory outcomes.
What to do instead
Recognise proxy-variable questions: when an option says 'simply drop the protected attribute', check whether the stem mentions correlated fields such as postcode or job title. Prefer answers that measure outcomes across groups, evaluate for disparate impact, and use techniques such as rebalancing data, adjusting thresholds, or testing with subgroup metrics, and be ready to explain that fairness requires ongoing monitoring rather than a one-time data edit.
Confusing the shared responsibility model for AI services, attributing data protection, access control, or content filtering entirely to the provider or entirely to the customer.
Cloud security habits from infrastructure exams do not transfer cleanly, and managed AI services blur the line between provider-managed model security and customer-managed data and configuration.
What to do instead
Split every scenario into provider duties (security of the service, underlying infrastructure, and the base model) and customer duties (data classification, encryption choices, identity and access policies, prompt and output safeguards, and monitoring usage). When an option claims the provider will handle customer data governance or that the customer must patch the model, treat it as a shared-responsibility error and choose the option that assigns the duty to the correct party.
Overlooking governance and auditability requirements, such as logging model inputs and outputs, documenting training data provenance, or tracking model versions, when the scenario mentions regulated industries or audits.
Candidates focus on getting the model to work and treat documentation and logging as optional extras, so they miss the option that satisfies traceability.
What to do instead
Scan the stem for trigger words such as audit, regulation, incident investigation, reproducibility, or accountability. When present, prefer answers that enable traceability: capturing invocation logs with metadata, maintaining a model card or data lineage record, versioning models and prompts, and defining human review and approval steps. Pair this with the principle that governance controls are configured by the customer even when the model is provider-managed.