AIF common mistakes
AIF · Understand the traps and how to avoid them.
Reversing the nesting of AI, machine learning, and deep learning - e.g., selecting an option that says machine learning is a subset of deep learning, or that all AI systems learn from data.
The three terms are used interchangeably in marketing material, so candidates rely on everyday usage instead of the formal hierarchy and pick whichever option sounds broadest.
What to do instead
Memorize the containment order once and apply it to every option: AI is the broad discipline, ML is a subset of AI that learns patterns from data, deep learning is a subset of ML using multi-layer neural networks, and generative AI is a subset of deep learning. Reject any option that breaks this order before reading the rest of the choice.
Classifying an algorithm or use case by the wrong learning type - calling clustering 'supervised' because the data looks organized, treating anomaly detection as always supervised, or confusing a regression task with classification when the target is a price or a count.
Candidates memorize algorithm names without the decision rule (is the training data labeled? is the output continuous or categorical?), so they pattern-match on surface cues in the scenario.
What to do instead
Apply two checks to each scenario: (1) Are the training examples labeled with the correct answer? Yes = supervised, no labels = unsupervised, learning by reward/penalty through interaction = reinforcement learning. (2) Is the predicted output a category = classification, or a numeric quantity = regression. Say both answers to yourself before looking at the options.
Choosing fine-tuning when the scenario needs frequently changing proprietary facts, or choosing retrieval-augmented generation when the scenario needs a consistent output format or tone.
Both techniques 'adapt' a foundation model, so the distinction blurs; candidates also assume few-shot prompting in the prompt counts as training.
What to do instead
Use the data-change test: if the knowledge changes often, is large, or must be cited, use RAG with a vector store so content updates without retraining. If the need is style, format, tone, or task behavior on a stable body of examples, use fine-tuning. Remember that examples placed in a prompt (zero-shot, one-shot, few-shot) are inference-time guidance, not model customization.
Treating temperature, top-p, and top-k as controls over factual accuracy, model knowledge, or safety - e.g., 'lower the temperature so the model stops hallucinating about our product documentation.'
These parameters visibly change output quality, so candidates attribute every improvement to them; the vocabulary of 'creativity' versus 'accuracy' sounds like a knowledge dial.
What to do instead
Fix the mental model: these parameters only shape how the next token is selected from the model's probability distribution. Lower temperature/top-p gives more deterministic, repeatable text; higher gives more varied text. They add zero knowledge. For factual grounding use RAG or a knowledge base; for disallowed content use guardrails; for repeatable outputs use low temperature.
Confusing pre-training, fine-tuning, RLHF, and prompt engineering - for example, saying RLHF is how a model learns a company's product catalog, or that pre-training is done by the customer on their own data.
The pipeline is taught as a list of stages without the 'who does it and with what data' dimension, so the stages collapse into 'training stuff.'
What to do instead
Anchor each stage to owner and data: pre-training = provider, massive general text, next-token prediction; fine-tuning = customer or provider, curated labeled examples, adapts behavior; RLHF = provider, human preference rankings, aligns helpfulness and safety; prompt engineering = user, no weight changes. If the question says 'the customer wants the model to answer in their brand voice,' the answer is fine-tuning, not pre-training.
Picking a model-hosting service by name recognition rather than by requirement - selecting Amazon SageMaker for a team that wants a serverless API to a third-party foundation model, or selecting Amazon Bedrock for a team that needs to build and host a custom training pipeline with their own containers.
Every service description contains words like 'machine learning' and 'models', so options sound interchangeable unless the candidate isolates the requirement (serverless API? custom training? managed assistant?).
What to do instead
Map requirement to service before reading options: serverless access to multiple foundation models via API with guardrails and knowledge bases = Amazon Bedrock; build, train, tune, and deploy your own models with full control = Amazon SageMaker AI; a prebuilt generative assistant for business data and enterprise search = Amazon Q Business. Underline the requirement keyword in the stem first.
Assuming a guardrail or responsible-AI feature fully eliminates a risk - e.g., 'enabling Guardrails for Amazon Bedrock removes all hallucinations,' or 'the model card certifies the model is unbiased.'
Service features are described with strong verbs ('filter', 'block', 'detect'), and candidates convert a mitigation into a guarantee, which is the most attractive-sounding option.
What to do instead
Adopt the rule that AWS responsible-AI tooling mitigates and detects but does not guarantee. Hallucinations are reduced with grounding/RAG plus human review; bias is measured with Amazon SageMaker Clarify and must be addressed with data and process changes. Choose the option that pairs the control with ongoing monitoring or human oversight, and reject absolute words like 'eliminates,' 'guarantees,' and 'prevents all.'
Mismatching AWS responsible-AI and governance services - using SageMaker Clarify for content filtering, Guardrails for bias metrics on a tabular dataset, or Amazon A2I when no human review workflow is described.
The services are all 'responsible AI' adjacent and their names are not self-explanatory, so candidates guess from the word 'AI' in the name rather than from the function.
What to do instead
Build a one-line function card for each: Clarify = bias detection and explainability; Model Monitor = drift and data quality in production; A2I = human review workflows; Guardrails for Amazon Bedrock = content filters, denied topics, PII redaction; Model Cards = documentation of intended use and limitations. Match the verb in the question ('measure bias', 'review low-confidence predictions', 'block harmful output') to the card.
Answering security scenarios with the wrong control family - e.g., using Amazon Macie to stop prompt injection, Amazon Comprehend to encrypt data at rest, or AWS Artifact to detect configuration drift.
All of these are security- or compliance-sounding AWS services, and under time pressure candidates match on topic rather than on the specific mechanism.
What to do instead
Classify the ask first: encryption and key management = AWS KMS; sensitive data discovery in S3 = Macie; PII detection in text = Comprehend; private network access to AWS services without the public internet = VPC endpoints / AWS PrivateLink; resource configuration compliance = AWS Config; audit evidence and reports = AWS Artifact. Prompt injection is addressed at the application layer with input validation, guardrails, and least-privilege model access, not by a data-classification service.
Confusing the shared responsibility boundary for foundation models - stating that AWS is responsible for the accuracy of a model's outputs, or that the customer is responsible for patching the underlying managed infrastructure.
The shared responsibility model is usually memorized as 'AWS secures the cloud, you secure what's in the cloud' without ever applying it to generative AI workloads.
What to do instead
Apply the split explicitly: AWS secures the infrastructure, the managed model endpoint, and the service; the customer owns the data, prompts, access policies, guardrail configuration, output review, and the compliance of the application built on top. Any option that makes AWS accountable for output correctness or the customer accountable for data-center patching is wrong.