AI-200 common mistakes
AI-200 · Understand the traps and how to avoid them.
Choosing a provisioning model by picking the one with the lowest per-token price while ignoring the throughput floor that Standard deployments can actually serve, then being unable to explain why the design fails under bursty load.
Candidates treat pricing tables as the deciding factor and never reason about quota, tokens-per-minute allocation, or how Provisioned Throughput Units reserve capacity rather than pay-as-you-go consumption.
What to do instead
For every deployment choice, write two sentences: the expected peak concurrency and the latency target. Match capacity type to that profile (Standard for spiky/low volume, Provisioned for steady high volume with latency SLAs, Batch for offline), and state the quota increase request needed.
Designing a content filtering and safety plan that only names the default filter and never covers prompt shields, groundedness detection, or the escalation path when a filter fires.
Safety is studied as a checkbox feature rather than a pipeline of controls with observable outcomes, so candidates cannot describe telemetry or fallback behaviour.
What to do instead
Build a three-layer answer: input controls (prompt shields, jailbreak detection), output controls (severity thresholds per category, custom blocklists), and operational response (log to Application Insights, return a graceful refusal, route to human review).
Recommending RAG for every accuracy problem instead of distinguishing when to fine-tune, when to use prompt engineering, and when to add a grounding data source.
Retrieval-augmented generation is the most rehearsed pattern, so candidates default to it even for tasks like enforcing a fixed output style or teaching a proprietary taxonomy.
What to do instead
Use a decision rule: changing knowledge or freshness → retrieval; changing format, tone, or strict schema adherence → fine-tuning or few-shot examples; changing reasoning steps → prompt/orchestration change. State the rule explicitly in the answer.
Describing a chat application without specifying how conversation state, token budget, and history truncation are handled, resulting in an answer that cannot survive a 30-turn conversation.
Candidates memorise the API call shape and forget that context windows are finite and that stateless model calls require the application to manage history.
What to do instead
Always include: where history is stored, the truncation or summarisation strategy, the max output token setting, and how the system message is preserved when trimming.
Treating an agent as a single prompt that 'decides things' rather than specifying the tool schemas, the orchestration loop, and the termination conditions.
Agentic solutions are new to most candidates, so they describe intent instead of the concrete loop of plan, invoke tool, observe result, and decide whether to continue.
What to do instead
For any agent question, enumerate the tools with their parameter contracts, the maximum iteration or step limit, the error-handling path when a tool call fails, and how the run is logged for evaluation.
Confusing the responsibilities of an agent's instructions, its knowledge/tools, and a connected multi-agent topology, then proposing multiple agents where one agent with two tools suffices.
Multi-agent orchestration sounds more sophisticated, so candidates over-engineer and lose points on cost, latency, and debuggability trade-offs.
What to do instead
Justify agent count: one agent per distinct responsibility with a clear boundary. If the tasks share context and tools, keep it single-agent and say why in one sentence.
Picking a vision capability by product name rather than by the task shape, e.g. proposing image classification when the requirement is to locate and count objects, or using OCR when the requirement is to extract structured field values from a form.
The vision service family has overlapping features (classification, detection, OCR, face, custom models) and candidates match on keywords instead of on input/output requirements.
What to do instead
Convert the requirement into an input/output pair before choosing: boxes and counts → object detection; per-image single label → classification; text plus layout → document/OCR with layout; identity or liveness → face APIs with the appropriate gating.
Ignoring the data and labelling prerequisites for a custom vision model, presenting training as a single step with no dataset size, class balance, or evaluation metric discussion.
Custom model training feels like a managed button-press, so candidates skip the part the exam actually tests: what data and thresholds make the model usable.
What to do instead
State per-class sample expectations, how the train/validation split is formed, and which metric (precision vs recall) matters for the stated business cost of false positives versus false negatives.
Answering an NLP question with a generic 'use the language service' instead of naming the specific capability and its output contract, such as sentiment with confidence scores, key phrase extraction, or intent plus entity recognition.
Candidates group all text analysis under one umbrella and never learn which capability returns what, so the answer cannot be validated against the requirement.
What to do instead
For each NLP requirement, name the capability, the expected response fields, and the language/locale support constraint. If a custom model is needed (intents, entities), say so explicitly and describe the training data labelling.
Designing an extraction or knowledge mining pipeline that stops at indexing and never covers chunking, enrichment skills, enrichment cache, or how the retriever will consume the index.
Candidates learn ingestion as 'point at a data source and create an index' and skip the enrichment and chunking decisions that determine retrieval quality.
What to do instead
Walk the pipeline end to end: data source → skillset (OCR, chunking, entity/vector enrichment) → index schema shaped for the query → retriever configuration. Call out which fields are searchable, filterable, and vectorized.