Azure AI-102 common mistakes
Azure AI-102 · Understand the traps and how to avoid them.
Provisions a separate single-service resource (for example a standalone Language resource plus a standalone Vision resource) for a solution that needs several AI capabilities behind one key, one endpoint, and one private endpoint, then answers networking and billing questions as if the resources were unified.
Candidates memorise the list of individual services and forget that the portal offers a multi-service Azure AI Services resource whose whole point is shared keys, endpoint, and network isolation.
What to do instead
Learn the rule: choose the multi-service Azure AI Services resource when two or more capabilities are needed with a single key/endpoint/VNet; choose a single-service resource only when you need per-service cost attribution, a region/SKU that the multi-service resource lacks, or isolation for compliance. Remember Azure OpenAI is provisioned as its own resource type.
Designs authentication as 'put the key in the config file' and cannot say which role assignment or resource setting is required to call a service with a managed identity, or how to block key-based access entirely.
Most tutorials and quickstarts use keys, so the identity-based path (role assignment plus token credential in code) is never rehearsed, and the local-auth toggle is easy to overlook in the portal.
What to do instead
Rehearse the pairing: disable local authentication on the resource, assign the calling identity a least-privilege role such as Cognitive Services User (or Cognitive Services OpenAI User for Azure OpenAI), grant the identity access to the key vault/secret only if keys are still used, and have code use DefaultAzureCredential with the resource endpoint rather than a key.
When told a deployed model returns stale prices or policies that change weekly, the candidate proposes fine-tuning the model on the current documents.
'Customise the model to our data' pattern-matches to fine-tuning, and fine-tuning is the flashier feature; candidates skip the cheaper, faster options that come first.
What to do instead
Apply the decision order: prompt engineering first, then retrieval-augmented generation when the knowledge changes or must be cited, and fine-tuning only for behaviour that retrieval cannot supply, such as output format, tone, classification behaviour, or reducing prompt length. Fine-tuning teaches style and task adherence, not facts with a shelf life.
Designs a RAG index with a vector field only: no hybrid keyword search, no semantic ranker, and no check that the embedding model and vector dimensions used at index time match the ones used to embed the query.
Vector search is the most talked-about piece of RAG, so candidates stop there and treat the index as a black box, forgetting that a dimension mismatch or a different embedding model silently produces irrelevant results.
What to do instead
State the full retrieval chain explicitly: chunking strategy, embedding deployment, index schema with the correct dimensions and vector algorithm/profile, hybrid query combining keyword and vector, semantic ranker on top, and the same embedding deployment used for both documents and queries.
Writes code that passes the base model name where a deployment name is expected, and selects provisioned throughput for a bursty, low-volume development workload.
In the Azure OpenAI model, the deployment is a named object that wraps a model; SDK samples sometimes use the model name, and throughput units sound like a performance upgrade without an obvious cost trade-off.
What to do instead
Keep the two concepts separate: the deployment name is what the client sends, the model is only chosen when creating the deployment, so changing model versions means changing the deployment, not the code. Choose standard/global standard for spiky or low utilisation, provisioned throughput only for steady, predictable, latency-sensitive load, and confirm that content filtering remains in place and cannot simply be switched off.
Implements an 'agent' as one chat completion call that describes available tools in the system prompt, with no structured tool schema and no code path for the model's tool-call response.
A single prompt looks simpler to write, and candidates who have not built the two-turn loop assume the model executes functions itself.
What to do instead
Describe the tool loop precisely: send tool definitions with JSON schemas, the model responds with a tool-call request and no answer, your code executes the function, you send the result back as a tool message, and the loop repeats until the model returns content. On the managed side, map this to the agent service concepts of an agent, a thread holding conversation state, a run that is polled to completion, and tools attached to the run.
Solves every agent scenario by adding more agents and more autonomy, without specifying grounding sources, tool permission boundaries, or where a human approves an action.
Multi-agent orchestration sounds more advanced and appears in vendor demos, so candidates over-architect and skip the guardrails the exam tests alongside capability.
What to do instead
Justify agent count from the task: one agent with several tools unless the subtasks genuinely need separate instructions, knowledge, or permissions. Always pair autonomy with grounding on a controlled data source, least-privilege tool credentials, input and output content safety checks, and an approval or escalation step for irreversible actions such as issuing refunds.
Uses face identification when the scenario only needs to confirm that a returning user matches one stored profile, and states that face identification is generally available for any scenario.
Both features live in the same Face resource and the names sound interchangeable; the access restrictions on identification are buried in eligibility documentation rather than in the API surface.
What to do instead
Pick by cardinality and purpose: verification is a one-to-one comparison against a specific person, identification searches one-to-many across a person group and is restricted-access with limited eligibility. Add liveness detection when the risk is a spoofed photo or replay, and prefer verification for re-authentication and access-control scenarios.
Reaches for custom question answering when the requirement is 'route a user's utterance to one of five intents and pull out the order number', or reaches for conversational language understanding when the requirement is 'answer from this fixed FAQ document'.
Both live in the Language service, both involve utterances and text, and both appear in natural-language tutorials, so the boundary between retrieval-style answering and trained intent classification blurs.
What to do instead
Choose by what the output must be: conversational language understanding when you need to classify intent and extract entities into structured fields, custom question answering when you need to return an answer from a curated knowledge base. A common production design uses language understanding for routing and question answering or a generative model for the answer, so state that hand-off explicitly.
Describes an Azure AI Search knowledge-mining solution as though skillsets run at query time, or treats the index, the indexer, the skillset, and the knowledge store as interchangeable parts.
All four appear in the same pipeline and the portal shows them on adjacent pages, so the direction of data flow and the execution point of enrichment get lost.
What to do instead
Narrate the pipeline in order: a data source feeds an indexer, the indexer runs on a schedule or on demand and invokes a skillset whose enrichment outputs are mapped into index fields, and optionally projected into a knowledge store for downstream analysis. Enrichment happens during indexing, never at query time, and query behaviour comes from the index's field configuration plus vector search and semantic ranker, not from the skillset.