AI-102 Practice Tests: 250+ Questions Mapped to Exam Objectives

AI-102 validates the day-to-day work of an Azure AI Engineer: planning and managing an AI solution and implementing applied AI workloads using Azure services. In practice-test terms, your job is to recognize which domain is being tested and which decision the question is forcing you to make. The exam objectives commonly cluster into: (1) plan/manage resources (identity, networking, monitoring, cost), (2) generative AI (Azure OpenAI, prompt engineering, RAG, safety/evaluation), (3) agentic solutions (tool use, orchestration, state, guardrails), (4) computer vision (image analysis, OCR, document intelligence), (5) NLP (text analytics patterns), and (6) knowledge mining (Azure AI Search indexing, enrichment, chunking, retrieval).

What the exam is really validating is your ability to move from “prototype works” to “solution can be run.” That includes selecting SKUs and regions, applying RBAC and managed identities, choosing private endpoints when required, designing content filters and prompt/response handling, and knowing when to use Azure AI Search vs. custom storage/query approaches.

Exam Tip: Watch for wording that signals the exam domain. “Minimize administrative effort” often points to managed services and built-in features (managed identity, built-in monitoring). “Ensure data does not traverse the public internet” signals private endpoints/VNet integration. “Must cite sources” or “reduce hallucinations” signals RAG with retrieval grounding and evaluation.

Common trap: treating AI-102 as a pure developer exam. Microsoft will test deployment readiness (logging, quotas, throttling, key rotation, content safety) even in questions that look like simple API usage.

Register through Microsoft’s certification dashboard and schedule via the authorized delivery provider. Decide early whether you will test online proctored or at a test center, because your preparation checklist changes. For online proctoring, your “test environment” is part of your score: a stable connection, a quiet room, and a compliant workspace are required. For a test center, travel time and check-in rules become the risk to manage.

Set up your account details to match your government-issued ID exactly (name order and special characters matter). Have acceptable identification ready and unexpired. If your legal name does not match your profile, fix it before scheduling; last-minute changes can trigger delays.

Exam Tip: Do a full technical check 24–48 hours before exam day (not five minutes before). The most preventable failure mode is treating environment readiness as optional. If you plan to use a laptop, confirm power settings won’t sleep/hibernate mid-exam.

Scheduling strategy: pick a date that supports a 2–4 week plan with at least two full practice-test cycles (attempt → review → targeted drills → reattempt). Avoid scheduling immediately after major work deadlines. You want consistent daily study time and a final 48-hour window for consolidation and light review rather than cramming new services.

Common trap: booking too early without a baseline diagnostic. You should schedule after you can estimate how far you are from passing and how many objective areas need focused remediation.

Microsoft exams are scored on a scaled system. The number of questions can vary, and not every question contributes equally. You are not aiming to “get X questions right” so much as to demonstrate competency across objective areas. Passing requires meeting the scaled passing score, and your score report will show performance bands by skill domain—use this to drive your study plan.

Time management matters because AI-102 can include multi-step scenarios and case-study style items. Plan to make one pass through the exam: answer what you can confidently, mark hard items, and return with remaining time. Don’t spend disproportionate time on a single item early; that is how candidates run out of time on easier points later.

Exam Tip: When you miss practice questions, categorize the miss: (1) concept gap, (2) misread constraint, (3) Azure service confusion, (4) test-taking error (overthinking, changing correct answers). Only category (1) needs more reading; categories (2)–(4) need process fixes.

Retake policies can enforce waiting periods and attempt limits. Treat each attempt as a project with a post-mortem: identify the top two weak domains and fix them before reattempting. “More practice tests” only helps if you review deeply and extract decision rules (for example: when to prefer Azure AI Search for retrieval vs. custom vector database, or when private endpoints are required for compliance scenarios).

Target score planning: set a practice-test target above the passing bar to create margin. Your baseline diagnostic (early in week 1) gives you a starting score; your goal is to move that score reliably, not sporadically. Consistency is the signal that you understand the objectives rather than guessing.

AI-102 is dominated by scenario-based questions that simulate real engineering constraints. Microsoft typically provides a short scenario (sometimes with multiple requirements) and asks for the “best” action, service, configuration, or next step. Your task is to locate the constraint that eliminates distractors. Distractors are often plausible but violate one requirement such as network isolation, least privilege, or operational monitoring.

Develop a repeatable parsing method: first underline requirements (must/should), then identify the objective domain (planning, gen AI, agents, vision, NLP, search). Next, translate requirements into a decision rule. Example: “Must prevent data exfiltration and use corporate identity” points you to managed identity and RBAC, plus private endpoints where relevant. “Needs citations and up-to-date internal knowledge” points to a RAG pattern with Azure AI Search indexing and retrieval, with chunking strategy and grounding.

Exam Tip: Watch for “minimize cost” paired with “high availability” or “global users.” The cheapest option is rarely correct if it cannot meet SLA/latency requirements. Microsoft expects you to balance cost with reliability and monitoring, not optimize a single dimension.

Common traps include: confusing similar services (Azure AI Document Intelligence vs. OCR features inside vision), assuming client-side secrets are acceptable (they are not—use managed identity where possible), and ignoring service limits/quotas (rate limits, token limits, content filtering). Another frequent trap is choosing a tool because it “can do it,” not because it is the most operationally appropriate Azure-managed capability for the requirement.

How to identify the correct answer: eliminate options that violate a hard constraint, then choose the remaining option that best aligns with Azure best practices (secure by default, monitorable, scalable) and the exam objective wording.

Your highest-return workflow is cyclical: learn the objective, practice questions mapped to that objective, review misses to extract decision rules, then repeat with narrower focus. This course’s practice tests are most effective when you treat them as diagnostics rather than final exams. The goal is to shorten the time between seeing a scenario and recognizing the correct Azure pattern.

Build a 2–4 week plan aligned to official domains. Week 1 is orientation plus baseline diagnostic and foundational gaps (resource planning, identity, networking). Week 2 focuses on generative AI and RAG: Azure OpenAI deployments, prompt engineering patterns, evaluation, safety, and Azure AI Search retrieval grounding. Week 3 covers agents and applied AI workloads: tool use/orchestration, state handling, guardrails; plus vision, OCR, and document intelligence. Week 4 is consolidation: mixed sets, timed practice, and weak-area drills. If you only have 2 weeks, compress by prioritizing your weakest two domains from the baseline diagnostic.

Exam Tip: Review is where the score increases. For every wrong answer, write the “because” in one sentence (for example: “Private endpoint required because traffic must not traverse public internet” or “RAG needed because model must use internal documents and provide citations”). If you cannot write the because, you are guessing.

Time management practice: do some sets timed, not all. Early on, untimed practice helps you learn. Later, timed mixed sets train endurance and reduce careless mistakes. Aim for a target score buffer on practice tests and require yourself to hit it twice on different days before you consider a domain “stable.”

Common trap: re-reading Learn modules without converting them into answerable decisions. Always translate reading into “if scenario says X, choose Y” rules that match exam-style prompts.

Use Microsoft Learn as your primary reference for objective-aligned content, but avoid passive consumption. Pair each Learn topic with hands-on validation where possible: create resources, set permissions, test endpoints, and observe outputs. Hands-on work is especially valuable for areas the exam loves to probe indirectly: authentication flows (keys vs. Entra ID), network isolation (private endpoints), and operational readiness (logging, metrics, alerts).

Sandboxing options include Azure free resources, a dedicated subscription for study, and labs that let you experiment without polluting production. When practicing generative AI, include end-to-end patterns: prompt templates, system messages, content filtering expectations, and RAG retrieval with Azure AI Search (indexing, chunking, embeddings, hybrid retrieval). For vision and document intelligence, test real sample documents so you understand what the service returns and what post-processing is required.

Exam Tip: Build a “decision notebook” rather than a feature notebook. Organize notes by scenario trigger and best answer: security triggers (managed identity, RBAC, private endpoints), cost triggers (right-size SKUs, avoid over-provisioning), monitoring triggers (Application Insights, logging, alerts), and gen AI triggers (RAG vs. fine-tuning, grounding, evaluation).

Adopt a lightweight note system: one page per exam domain with: key services, common constraints, and 10–15 decision rules. Add a “mistake log” from practice tests with the exact misread phrase that fooled you. This trains you to catch Microsoft’s wording patterns. Keep your notes concise so you can review them in the final 48 hours.

Finally, treat your baseline diagnostic as a tool, not a judgment. Its purpose is to identify which objectives to study first and to set a target score plan. The combination of Learn + hands-on sandboxing + disciplined review of practice misses is the fastest path to passing AI-102.

AI-102 frequently asks you to choose the “right” Azure AI service and deployment model for a scenario. Start by classifying the workload: prebuilt Azure AI Services (Vision, Language, Speech, Document Intelligence), Azure AI Search for retrieval, or Azure OpenAI for generative. Then decide whether to run in Azure (managed endpoints) or in containers (customer-managed runtime). Containers are commonly tested when the prompt mentions disconnected environments, edge locations, strict data sovereignty, or needing to run the model behind a customer-controlled network boundary. Managed cloud endpoints are typically correct for rapid time-to-value, managed scaling, and integrated monitoring.

Regions matter. The exam likes scenarios that mention “must remain in EU,” “use a specific geography,” or “minimize latency for users in APAC.” Your architecture answer should place resources in the required region and call out that not every AI capability is available in every region. If a service is unavailable in the required region, the correct design may involve choosing an alternative service or a compliant region pairing. Also consider multi-region resiliency: active/active for read-heavy endpoints, or active/passive for failover; the exam often rewards designs that reduce blast radius.

Exam Tip: When you see “on-premises,” “offline,” “air-gapped,” or “no data leaves the facility,” immediately evaluate containerized Azure AI Services or a pattern where only metadata leaves the network. If the scenario also demands managed identity, private endpoints, and Azure-native logging, a managed cloud deployment is usually expected.

• Use managed endpoints when you need fast deployment, autoscale, and Azure-native monitoring.
• Use containers when you need local processing, custom network control, or disconnected operations.
• Choose regions based on compliance and latency; confirm feature availability in that region.

Finally, recognize “architecture pattern” hints: if the question mentions retrieval, grounding, or “use enterprise documents,” it’s pushing you toward a RAG architecture using Azure AI Search plus an LLM endpoint. If it mentions “process many documents,” consider async/batch patterns with queues and event-driven compute to absorb spikes.

Provisioning is where exam questions test your familiarity with Azure resource concepts: endpoints, authentication, and role assignments. Most Azure AI Services expose an endpoint URL and require either API keys or Microsoft Entra ID (Azure AD) authentication. A classic trap: selecting “keys” when the scenario calls for enterprise governance (centralized identity, key rotation, or no secrets in code). If the prompt includes “least privilege,” “managed identity,” “no shared secrets,” or “rotate credentials,” prefer Entra ID + RBAC.

Know what must be configured after creation: selecting a pricing tier, enabling diagnostic settings, configuring allowed networks (public vs private), and assigning roles. RBAC is tested by asking who can “invoke,” “manage,” or “read” the resource. In practice, management-plane actions (create/update) require Contributor-like roles, while data-plane invocation is often controlled through specific “Cognitive Services User”/service-specific roles when Entra ID auth is enabled. If keys are used, anyone with the key effectively has invocation access—another reason keys are considered weaker for governance.

Exam Tip: If a question says “application runs in Azure” and “must not store secrets,” the best pattern is: system-assigned managed identity on the compute + RBAC assignment to the AI resource + Entra ID authentication. Eliminate answers that propose embedding keys in app settings without Key Vault.

• Endpoint + key: simplest, but treat the key as a secret; rotate and store in Key Vault.
• Endpoint + Entra ID: best for enterprise access control; pair with managed identities.
• RBAC: assign only the minimum roles needed (separate operators from callers).

Also watch for “multiple environments” (dev/test/prod). The exam expects separate resources (or at least separate keys/quotas) and consistent IaC deployment. When asked how to prepare for deployment readiness, describe repeatable provisioning via ARM/Bicep/Terraform and configuration through parameterization rather than manual portal changes.

Networking is a high-yield area because many wrong answers ignore isolation requirements. If the scenario says “no public internet access,” “internal-only,” or “exfiltration risk,” the correct solution usually includes private endpoints (Private Link) for the Azure AI resource plus corresponding DNS configuration (private DNS zones) so clients resolve the service endpoint to a private IP. A common trap is confusing IP firewall rules with true private connectivity; firewall allowlists still expose a public endpoint, while private endpoints eliminate the need for public exposure.

Managed identity appears frequently alongside private networking: your compute (App Service, Functions, AKS, VM) uses a system-assigned or user-assigned managed identity to authenticate to the AI resource via Entra ID. This avoids secrets and supports rotation-free credentials. If the question includes “rotate keys,” “remove hard-coded secrets,” or “audit access by user/app,” managed identity + RBAC is the cleanest path.

Exam Tip: When you see “must be accessible only from VNet,” look for an answer that combines: disable public network access (where supported) + private endpoint + private DNS + RBAC/managed identity. If any element is missing, it may be an incomplete design.

• Private Endpoint: data-plane traffic stays on Microsoft backbone; no public ingress.
• Private DNS: required so standard service FQDN resolves to private IP internally.
• Managed Identity: passwordless identity for Azure resources; pair with least-privilege roles.

Finally, consider egress controls. In agentic or RAG scenarios, the solution might call external tools or retrieve from storage/search. The secure design restricts outbound calls (e.g., through controlled endpoints) and enforces that all dependencies (Storage, Search, OpenAI, Key Vault) are reachable privately when required. The exam often rewards answers that secure the whole chain, not just the model endpoint.

Responsible AI in AI-102 is usually tested through governance basics: content safety, prompt/response logging considerations, human oversight, and compliance alignment. Scenarios may mention “avoid harmful content,” “prevent leaking PII,” or “audit generated outputs.” Your design response should include safety controls (for generative AI, using Azure AI Content Safety or built-in safety configurations where applicable) and a policy for what you log and how you protect it.

A frequent exam trap is proposing to log “everything” (full prompts, full outputs, full documents) without addressing sensitive data handling. The better answer acknowledges that logs are data too: apply data minimization, redact or hash identifiers, use secure storage with RBAC, and set retention policies. If the prompt mentions regulations (HIPAA, GDPR, financial), the expected approach includes explicit consent/notice considerations, data residency, and access auditing rather than ad-hoc application logging.

Exam Tip: If the scenario demands “traceability” or “investigation of incidents,” choose Azure-native logging (Azure Monitor/Log Analytics) with diagnostic settings enabled on each resource. Avoid answers that rely only on local application logs without centralized retention and access controls.

• Governance: define acceptable use, review flows, and incident response for harmful outputs.
• Logging: enable diagnostic settings; store logs securely; minimize sensitive content.
• Compliance: enforce retention, access reviews, and regional deployment requirements.

Also be ready to identify where governance lives: policy and controls at the platform level (Azure Policy, RBAC, private networking), and safety controls at the application/AI level (input validation, content filtering, grounding constraints). The exam typically wants layered guardrails, not a single control.

Operational excellence is core to “plan and manage.” AI-102 scenarios often describe intermittent failures, latency spikes, or “requests are being rejected.” Translate those symptoms into: monitoring, throttling/quotas, and resiliency patterns. First, enable diagnostic settings on AI resources to send logs and metrics to Log Analytics, Event Hub, or Storage. Then define alerts on key signals: error rates (4xx/5xx), latency, saturation (throttling), and dependency failures (Search/Storage).

Throttling is a common exam topic: 429 responses indicate rate limits or capacity constraints. The best answer usually includes client-side retry with exponential backoff and jitter, request pacing, and batching where appropriate. A trap is choosing “increase timeout” as a fix for throttling—it doesn’t address rate limiting. Another trap is ignoring idempotency: retries must be safe, especially for operations that create resources or trigger side effects.

Exam Tip: When asked to “improve reliability,” prefer patterns that reduce single points of failure: queue-based load leveling, circuit breakers, and graceful degradation (e.g., fall back to a simpler model or cached result) rather than only “scale up.”

• SLAs: identify what Azure provides vs what you must build (multi-region failover, retries).
• Diagnostics: centralize logs/metrics; correlate by request IDs across components.
• Resiliency: retries for transient faults, queue buffering for spikes, health probes.

The exam may also include “deployment caused outage.” Correct responses include canary or blue/green deployments, feature flags for risky changes (like prompt template updates), and rollback plans. Monitoring must validate both infrastructure health and model/app behavior (latency, output quality signals when available).

Cost and capacity questions on AI-102 reward candidates who can name concrete levers: pricing tiers, throughput/capacity units, caching, batching, and controlling token usage for LLMs. If the scenario says “cost is too high,” avoid vague answers like “optimize code.” Instead, identify measurable drivers: request volume, payload size, model size, and retry storms. For generative workloads, token limits, prompt length, and response length are the first places to look; for OCR/document processing, page counts and batch frequency dominate.

Capacity planning on the exam usually appears as “prepare for peak traffic” or “avoid 429s.” The correct solution combines: estimating peak RPS, sizing quotas/capacity, pre-provisioning where applicable, and implementing load leveling with queues. A trap is relying solely on autoscale when the downstream AI service enforces fixed quotas—autoscale can amplify throttling if you scale callers faster than the service capacity.

Exam Tip: If you see “budget alert” or “chargeback,” the answer should mention Azure Cost Management budgets/alerts and resource tagging. If you see “predictable monthly spend,” look for reserved capacity/commitment options where applicable and tight quota controls.

• Cost controls: budgets, alerts, tags, right-sized tiers, and workload scheduling.
• Efficiency: caching frequent results, compressing payloads, reducing prompt/context size.
• Deployment checklist: RBAC least privilege, private endpoints, diagnostics enabled, alerts, runbooks, and rollback plan.

For deployment readiness, think in checklists because the exam often describes a near-production state. A strong final design includes: IaC templates, environment separation, secret management (Key Vault or managed identity), network lockdown, monitoring/alerting, documented SLOs, and a tested failover/retry strategy. This mindset directly supports the chapter’s domain practice set: you’re not just building an AI feature—you’re operating an Azure AI service reliably and securely at scale.

AI-102 commonly tests whether you understand the difference between a model and a deployment. In Azure OpenAI, you select a model family (for example, GPT-style chat models, embedding models, or image generation models), then create a deployment with a deployment name. Most SDK calls target the deployment name, not the underlying model identifier. A frequent exam trap is choosing an answer that references “call the model directly” rather than “call the deployment endpoint using the deployment name.”

Tokens drive both cost and model limits. The exam expects you to reason about prompt + completion tokens, maximum context window, and how conversation history accumulates. If a scenario says “multi-turn chat over long documents,” assume you must summarize, chunk, or use RAG rather than dumping entire documents into the prompt. Parameters such as temperature (creativity), top_p (nucleus sampling), and max_tokens (response cap) show up in scenario questions. In regulated scenarios, lower temperature and explicit output schemas reduce variance and help with repeatability.

• Temperature low (e.g., 0–0.3): more deterministic, better for extraction and compliance.
• Temperature higher: better for brainstorming but increases risk of hallucinations.
• max_tokens: cap cost and latency; also prevents overly long answers that may violate UI constraints.

Exam Tip: If a question mentions “reduce cost” or “avoid exceeding context limits,” the best answer often involves trimming chat history, using summaries, or moving knowledge into Azure AI Search + RAG rather than increasing max tokens.

In your “build chat/completions solutions” lesson, map the requirement to the right API style: use chat for multi-turn, role-based prompting; use completions (where applicable) for simpler single-turn generation. The exam may also check whether you can identify when embeddings are required (semantic search, similarity, RAG) versus when generation alone is sufficient (formatting, rewriting, summarization of short input).

Prompt engineering is tested in AI-102 as an implementation skill: selecting the correct role messages (system/developer/user), applying constraints, and producing outputs that downstream code can reliably parse. System messages are your “policy layer” inside the prompt: they define persona, boundaries, and output rules. A common trap is placing critical rules in the user message; the exam typically expects durable instructions (safety, citation format, JSON schema) to live in the system message so they persist across turns.

Use prompt patterns that align with scenario requirements:

• Instruction + constraints: “Answer using only provided sources; if insufficient, say you don’t know.”
• Delimiters: separate retrieved context from user question to reduce prompt injection risk.
• Few-shot examples: stabilize formatting and classification outputs.
• Chain-of-thought handling: the exam may imply you should request concise rationale or structured fields rather than verbose internal reasoning.

Structured outputs are a recurring exam theme because they reduce post-processing errors. When a scenario says “must integrate with a workflow,” “must return fields,” or “must be machine-readable,” the correct solution usually includes JSON output constraints (and often schema-like guidance). Your “output control” lesson should emphasize: specify keys, allowed values, and fallback behavior (e.g., nulls) to avoid brittle parsing. Also restrict verbosity and include explicit instructions like “Do not include additional keys” when strict parsing is required.

Exam Tip: If the options include “use regex to parse free-form text” versus “constrain the model to JSON,” the exam almost always favors structured output prompting (and/or native structured output features when presented) because it is more reliable and test-aligned.

Finally, watch for prompt injection scenarios. If the question describes user-supplied content attempting to override instructions (“ignore previous directions”), the best answer combines role separation (system message rules), delimiter-based context isolation, and RAG grounding/citations rather than “just increase temperature” or “add more examples.”

AI-102 assesses whether you can design safety into a generative AI solution rather than treating it as an afterthought. Azure OpenAI content filtering and safety features are typically evaluated by scenario: public-facing chatbot, HR assistant, healthcare FAQ, or internal tool. The exam expects you to apply a policy-driven design: define what is allowed, detect and handle risky inputs/outputs, and ensure auditing/monitoring requirements are met.

Key implementation concepts include: applying content filters for both prompts and completions, choosing appropriate severity thresholds, and defining fallbacks (refusal messages, escalation to a human, or redirect to safe content). If the scenario says “must prevent hateful content,” “must block self-harm instructions,” or “must comply with responsible AI,” the correct answer typically includes explicit content filtering plus prompt-level guardrails (system message constraints) and logging for investigation (while respecting privacy requirements).

• Input filtering: stop harmful user prompts before the model generates unsafe output.
• Output filtering: prevent unsafe completions from reaching users.
• Application policy: define what to do when content is blocked (retry, refuse, or human review).

Exam Tip: When an option says “just add a disclaimer,” treat it as insufficient. The exam generally expects technical controls (filters, refusal behavior, constrained prompts) instead of purely informational mitigation.

Another frequent trap: confusing safety with privacy. Safety controls manage harmful content; privacy controls cover data handling (PII, retention, access). If the scenario emphasizes “do not store prompts” or “restrict access to keys,” that’s security/governance. If it emphasizes “avoid violent content,” that’s safety. Many correct answers require both, but the exam will test whether you can pick the feature that matches the stated requirement.

In practice, safety should be layered: prompt rules (system message), content filtering, and retrieval constraints (RAG limited to approved sources). That layered approach is often the “most correct” answer in multi-select or best-practice questions.

RAG is one of the highest-yield topics in the “Implement generative AI solutions” objective area. The exam doesn’t just ask what RAG is; it tests whether you can implement the pattern with Azure AI Search and Azure OpenAI: create embeddings, index chunks, retrieve relevant passages, and ground the final response with citations. Your “Implement RAG with Azure AI Search and grounding techniques” lesson should translate into a crisp architecture: ingest → chunk → embed → index → retrieve → generate.

Chunking is frequently tested because it impacts relevance, cost, and citation quality. If chunks are too large, you waste tokens and dilute relevance; too small, you lose context. Look for options that mention overlap (sliding windows) and metadata (document id, page, section) because citations require traceability. Embeddings are then stored in a vector field in Azure AI Search, enabling vector search and often hybrid search (keyword + vector) for better recall.

• Embeddings: used for similarity; choose an embedding model deployment, generate vectors per chunk.
• Vector search: retrieves semantically similar chunks even if exact keywords differ.
• Hybrid search: combines lexical and semantic signals; commonly the best default for enterprise docs.
• Citations: include source metadata in the prompt and instruct the model to cite it.

Exam Tip: If a question requires “answer must include sources” or “must only use internal documents,” RAG with citations is the intended solution—not fine-tuning. Fine-tuning changes style/behavior; it does not reliably inject up-to-date proprietary facts.

Grounding techniques on the exam include: (1) strict instructions to use only retrieved context, (2) “insufficient information” fallback, and (3) returning citations tied to chunk metadata. A common trap is retrieving content but failing to pass it to the model in a structured way (no delimiters, no source ids), which makes citations impossible and increases hallucination risk. Another trap: using the entire document as context instead of retrieved top-k chunks; that usually violates token/cost constraints and reduces answer quality.

The exam increasingly emphasizes that you must evaluate generative AI solutions, not just build them. Expect scenario questions that mention “model updates caused different answers,” “latency is too high,” “cost exceeded budget,” or “users report inconsistent outputs.” The correct responses usually combine prompt/model tuning with measurable evaluation.

Quality evaluation includes groundedness (did the answer use sources?), correctness, completeness, and safety. For RAG, evaluate retrieval metrics (are the right chunks being returned?) separately from generation (is the model using them well?). Latency and cost are typically driven by token usage (prompt size + response), retrieval time, and model selection. Practical tuning levers include reducing context size (better chunking, lower top-k), summarizing conversation history, caching frequent retrieval results, and constraining output length.

• Quality: test with representative prompts; look for hallucinations and citation accuracy.
• Latency: measure end-to-end; retrieval + generation; reduce tokens and network hops.
• Cost: control tokens, batch embedding jobs, use the smallest model that meets requirements.
• Regression: keep a “golden set” of prompts and compare outputs over time.

Exam Tip: If an option proposes “manual spot checks only,” it is usually incomplete. The exam favors repeatable evaluation: automated regression sets, tracked metrics, and clear acceptance thresholds (for example, citation presence, refusal correctness, or response time SLOs).

Regression testing is especially relevant for prompt changes and retrieval/index updates. Even small changes (chunk size, synonym maps, ranking profiles, or system message edits) can shift outputs. For exam scenarios about “recent changes broke behavior,” choose answers that add versioning, A/B testing, and automated evaluation runs rather than ad-hoc fixes.

This section is where many exam questions hide: not “how to build,” but “what went wrong” and “how to fix it.” Hallucinations often stem from missing or poor retrieval, ambiguous prompts, or high temperature. If a scenario says “model invents policies,” the exam expects you to add RAG grounding, require citations, lower temperature, and implement an “I don’t know” fallback when sources don’t support an answer.

Grounding failures can occur even with RAG when the wrong chunks are retrieved or when the prompt does not clearly instruct the model to use the provided context. Look for fixes like hybrid search, improved chunking/overlap, better metadata filters (department, region, date), and explicit delimiters separating sources from the user request. Another classic trap is passing multiple conflicting chunks; the model may merge them. The best exam answer typically includes ranking improvements and prompt instructions to prioritize the most recent or highest-authority source.

Rate limits and throttling appear in operational scenarios: “HTTP 429,” “too many requests,” or “spiky traffic.” Correct mitigations include request throttling, exponential backoff with retries, queue-based buffering, and caching. Simply “increase max tokens” or “use a larger model” won’t solve throughput limits and may worsen cost/latency.

• Hallucinations: ground with RAG + citations; lower temperature; enforce refusal on missing evidence.
• Grounding failures: fix retrieval (chunking, hybrid search, filters), then fix prompt structure.
• Rate limits: implement retry/backoff, concurrency controls, and caching; design for peak load.

Exam Tip: When you see “must be accurate and verifiable,” assume the exam wants citations and grounded answers; when you see “intermittent failures under load,” assume it wants retry/backoff and queueing—not prompt changes.

As you move into the domain practice set for Generative AI, keep a diagnostic mindset: identify whether the scenario is a generation problem, a retrieval problem, a safety problem, or a throughput problem. AI-102 questions are often easiest when you classify the failure mode first and then select the feature that directly addresses it.

Section 4.1: Agent concepts—planner/executor, function calling, tools, and skills

AI-102 expects you to distinguish “chatbot” from “agent.” A chatbot can answer questions; an agent can decide to take steps using tools and then report results. In exam scenarios, the trigger words are “book,” “create,” “update,” “search internal systems,” “run a query,” or “resolve the issue end-to-end.” That implies a planner/executor mindset: the model (planner) chooses actions; your application (executor) performs them with deterministic code and returns structured results.

Function calling is the testable mechanism that connects model reasoning to tool execution. You expose a tool schema (function name, parameters, types), and the model produces a tool call payload. Your code then validates parameters, enforces authZ, invokes the tool, and returns the tool output back to the model for synthesis. Tools are the concrete capabilities (Search, SQL query, REST API call, file read/write), while skills are reusable tool bundles or workflows (e.g., “CustomerLookupSkill” that calls CRM + billing + returns normalized profile).

Exam Tip: If an answer choice says “let the model call the API directly,” treat it as a trap. The correct architecture has your service call the API (with managed identity/keys), not the model. The model emits intent (function call), your code enforces policy.

Common traps include (1) over-trusting the model to select safe parameters, (2) embedding secrets in prompts, (3) skipping strict JSON/schema validation, and (4) conflating tool outputs with ground truth without verification. On the exam, prefer designs that keep a deterministic boundary: the model proposes; the app disposes. Also watch for “skills” vs. “tools”: skills typically imply composability and reuse; tools are individual actions. If the question asks for reducing prompt complexity across multiple tasks, a skills abstraction is usually the best fit.

Section 4.2: Tool integration patterns (APIs, search, code, and data actions)

Tool integration questions usually test whether you can choose the right tool type and boundary for reliability and security. Four high-frequency patterns appear in AI-102-style scenarios: (1) API tools for business actions (CRM, ServiceNow, Graph), (2) search tools for grounding (Azure AI Search retrieval), (3) code tools for deterministic computation/formatting, and (4) data actions (SQL/NoSQL queries, data lake lookups).

For API tools, design for idempotency, retries, and least privilege. If a model is allowed to “create order,” ensure the tool requires explicit fields (customerId, sku, quantity) and your service checks authorization and business rules. For search tools, return snippets plus metadata (source, URL, timestamp) so the model can cite and you can audit. For code tools, keep them constrained: use code to compute totals, validate formats, convert units, or apply policies—never to “decide” policy.

Exam Tip: When you see “must provide citations” or “must answer only from approved docs,” the best tool pattern is retrieval + response synthesis, not “fine-tune the model.” Fine-tuning is rarely the first-choice answer for enterprise grounding requirements.

Data actions introduce common exam pitfalls: SQL injection via tool parameters, overly broad query permissions, and ambiguous joins that produce misleading results. Prefer parameterized queries, stored procedures, or a data access layer that accepts only whitelisted fields. Another trap is latency: chaining too many tools can violate response time requirements. In those cases, prefer parallel calls (where safe) or precomputed indexes (e.g., Azure AI Search) rather than repeated database scans.

Finally, tool outputs should be structured. If an option suggests returning free-form text from tools, consider it weaker than JSON with explicit fields, because structured outputs enable validation, deterministic rendering, and easier incident triage.

Section 4.3: State, memory, and conversation management (short/long-term)

State management is a frequent hidden requirement in agent questions. The exam tests whether you can separate short-term context (the last few turns and tool outputs) from long-term memory (user preferences, prior cases, durable facts). Short-term memory typically lives in the conversation transcript and must be truncated/summarized to fit token limits. Long-term memory should be stored externally (database, key-value store, vector store) and retrieved intentionally, not blindly appended to every prompt.

Short-term strategy: maintain a message history with role separation (system/developer/user/tool) and summarize older turns while preserving commitments, constraints, and unresolved tasks. Long-term strategy: store user profile facts (timezone, language, account IDs) and retrieve them only when needed. For grounding, store embeddings of relevant documents and retrieve per query rather than persisting entire documents into chat history.

Exam Tip: If a scenario mentions “must forget data after the session” or “data residency/privacy,” avoid designs that write raw transcripts to long-term stores. Prefer ephemeral session state or redacted logs with retention controls.

Common traps: (1) treating memory as “whatever the model remembers,” (2) leaking sensitive information by storing full prompts/responses, and (3) using vector memory as an authoritative source without verifying freshness or ownership. Correct answers usually include explicit scope: session cache for immediate context, durable store for approved fields only, and retrieval filters (userId, tenantId, document ACLs) to prevent cross-user leakage.

Conversation management also includes tool-result handling: tool outputs should be linked to a turn, persisted with correlation IDs, and optionally summarized for future steps. If the agent runs multi-step plans, you need a state machine concept (planned steps, completed steps, pending confirmations) so failures can be retried safely without duplicating actions.

Section 4.4: Orchestration patterns—multi-agent workflows and routing

Orchestration is where AI-102 questions become architecture-heavy. You should recognize when a single agent with tools is sufficient versus when you need routing or multi-agent collaboration. Routing patterns classify the user request and send it to a specialized agent (billing agent, technical agent, HR agent) with scoped tools and knowledge. Multi-agent workflows break a complex task into roles: a planner agent creates a plan, a researcher agent gathers sources, an executor agent performs actions, and a verifier agent checks constraints and outputs.

On the exam, choose multi-agent only when the scenario justifies separation of concerns: strict tool permissions, different data sources, or independent verification. Otherwise, a single orchestrator with clear tool boundaries is simpler and often preferred for cost and latency. If an option introduces multiple agents “to improve accuracy” without a governance reason, it may be a distractor.

Exam Tip: Look for requirements like “must not access HR data unless needed” or “separate systems per department.” That points to routing with scoped identities and tool sets per route, not one omniscient agent.

Workflow control is also testable: synchronous orchestration for interactive chat; asynchronous orchestration for long-running tasks (document review, batch enrichment). Correct designs include checkpoints, retries, and compensating actions (e.g., if step 3 fails after creating a ticket, update the ticket status rather than creating a duplicate). Another common trap is ignoring user confirmation. For destructive actions (delete, submit payment, send email externally), the best answer usually requires a “confirm intent” step before the executor tool runs.

Section 4.5: Guardrails—grounding, permissions, jailbreak resistance, validation

Guardrails are highly exam-relevant because they connect safety, correctness, and compliance. In agentic systems, guardrails typically combine grounding controls (RAG), permissioning, jailbreak resistance, and validation. Grounding means the agent’s responses are tied to retrieved enterprise sources; permissioning ensures the agent can only call tools within the user’s rights; jailbreak resistance ensures the user cannot override policies; validation ensures tool parameters and final outputs meet constraints.

Grounding guardrails: use Azure AI Search with security trimming (ACL filters) and return citations. If a scenario demands “answer only from provided sources,” include a refusal rule when retrieval returns insufficient evidence. Permission guardrails: tools should run under managed identity or service principals, with per-tool RBAC and least privilege. Never rely on the model to “decide” whether access is allowed.

Exam Tip: If an answer choice says “add a stronger system prompt to prevent jailbreaks,” that is incomplete by itself. Prefer layered defenses: content filters/policies, tool allowlists, schema validation, and access control outside the model.

Jailbreak resistance and prompt injection: treat retrieved content as untrusted input. Strip or neutralize instructions found inside documents (“ignore previous instructions”). Prefer patterns where the model is instructed to treat retrieved text as data, not commands. Validation: enforce JSON schema for tool calls; validate ranges, formats, and business rules; sanitize user inputs before passing to data tools. For final responses, use post-processing checks (PII detection, profanity, policy compliance) when required by the scenario.

Common traps include over-grounding (dumping too many chunks, causing confusion) and under-grounding (no citations, vague claims). The “correct” option generally balances: retrieve top-k relevant chunks, include metadata, and instruct the model to cite and to say “I don’t know” when sources don’t support an answer.

Section 4.6: Observability—tracing, auditing, evaluation, and incident response

Agentic solutions fail in more ways than simple Q&A: tool timeouts, partial plans, wrong parameter extraction, policy violations, and cascading errors across steps. The exam expects you to operationalize agents with tracing, auditing, evaluation, and incident response. Tracing means you can reconstruct what happened: user input, model output, tool calls, tool responses, and final answer—all linked by correlation IDs. Auditing means you can answer “who did what” and “why,” including which data sources were used and which actions were taken.

In Azure scenarios, look for integration with Application Insights/Azure Monitor (requests, dependencies, exceptions), plus structured logs of tool calls and model metadata (model version/deployment, prompt template version, retrieval query, document IDs). For regulated environments, store audit trails with retention policies and access controls; redact or tokenize sensitive fields before logging.

Exam Tip: If a requirement says “investigate hallucinations” or “prove the source of an answer,” the best design includes logging retrieved document identifiers and the exact passages returned, not just the final response.

Evaluation is both offline (test sets, regression) and online (quality metrics, human review sampling). Expect exam language like “continuous improvement” or “monitor response quality”; that points to systematic evaluation, not ad-hoc spot checks. Incident response includes runbooks: disable a risky tool, roll back a prompt version, rotate keys, throttle traffic, and notify owners. Failure handling should be explicit: timeouts with fallback, retries with backoff, circuit breakers for unstable dependencies, and safe degradation (answer with partial results plus transparency).

Common traps: logging secrets, storing full raw prompts without redaction, and missing per-step timing/latency metrics (which hides tool bottlenecks). Correct answers emphasize end-to-end traceability, least-privilege access to logs, and a feedback loop that ties incidents to evaluation and prompt/tool updates.

Section 5.1: Computer vision solution selection (image analysis vs custom vs OCR)

AI-102 expects you to select the right vision capability for a business scenario, not just “use Computer Vision.” The core decision is whether you need (a) general image understanding, (b) custom classification/detection, or (c) text extraction (OCR). For general image understanding—captions, tags, objects, people/scene descriptions—use Azure AI Vision image analysis features (prebuilt). For custom domain-specific categories (e.g., identifying specific product SKUs, detecting defects on a manufacturing line), you typically need a custom model pattern (custom image classification or object detection) rather than relying on generic tags.

OCR is its own branch: when the question says “extract printed/handwritten text from images” or “read serial numbers,” you’re in OCR land. OCR can be a feature within vision offerings, but exam scenarios often push you toward a document-centric workflow if the input is PDFs, scans, invoices, receipts, or multi-page forms (which leads to Document Intelligence in the next section). If the input is a photo with a short line of text, OCR in a vision service may be enough; if the input is a form with fields and tables, treat it as a document problem.

Exam Tip: Watch for wording like “need bounding boxes for objects” (object detection), “need categories you define” (custom classification), “need to locate text lines and return the text” (OCR), and “need key-value pairs/tables across many vendor layouts” (Document Intelligence).

• Common trap: Choosing a custom model when the scenario only needs generic tags/captions. The exam rewards the simplest service that satisfies requirements.
• Common trap: Treating all PDFs as images for OCR only. If the output needs structure (fields, tables, line items), OCR alone is insufficient.
• How to identify correct answers: Look for explicit output requirements: classification label vs object coordinates vs extracted text vs structured fields.

Implementation-wise, be ready to reason about throughput and async patterns. Vision/document analysis calls can be synchronous for small inputs but often become asynchronous for large documents or batch processing. In case studies, also note security requirements: private endpoints/VNet integration can be a deciding factor when multiple services overlap in capability.

Section 5.2: Document Intelligence patterns (forms, layouts, extraction, confidence)

Document Intelligence is the go-to when the exam mentions invoices, receipts, IDs, contracts, multi-page PDFs, tables, and “extract fields into JSON.” The testable patterns typically include: (1) prebuilt models (invoice/receipt/ID), (2) layout extraction (text, tables, selection marks) when you don’t need semantic fields, and (3) custom extraction when documents vary or you need your own schema.

A common exam move is to give you a requirement like “documents come from many vendors with different layouts; extract total amount, invoice number, and date.” The correct direction is usually a prebuilt invoice model first (fastest time-to-value), and only then a custom model if prebuilt doesn’t meet accuracy or field coverage. Conversely, if the scenario says “proprietary form with stable layout used internally,” a custom model is often justified.

Confidence scores matter. AI-102 questions sometimes ask what to do when extraction confidence is low or when human review is required. Your design should include a threshold-based workflow: accept high-confidence fields automatically, route low-confidence fields to manual review, and store both the extracted value and confidence for auditability.

Exam Tip: If the requirement includes “tables/line items,” that strongly signals Document Intelligence rather than plain OCR. Layout extraction can find tables, but a prebuilt/custom model is usually needed to map tables to business concepts (e.g., line item description, quantity, unit price).

• Common trap: Assuming a single pass returns perfect structured data. Realistic solutions include validation, fallback, and exception handling.
• Common trap: Ignoring multi-page handling and async polling. Many document analysis operations are long-running; designs should reflect that.

On the exam, you also need to recognize the difference between “extract everything” and “extract specific fields.” Layout is best for broad text/tables without semantic labeling. Prebuilt/custom models are best when your downstream system needs stable field names and types. In document-heavy pipelines, plan how outputs flow into storage and search (often feeding Azure AI Search as enriched content for retrieval).

Section 5.3: NLP solution selection and Text Analytics patterns

NLP on AI-102 typically revolves around selecting the right capability: sentiment analysis, key phrase extraction, named entity recognition (NER), language detection, summarization, classification, or custom entity extraction. Many exam cases can be solved with prebuilt Text Analytics-style features when you need common insights (sentiment, entities, PII detection) and can tolerate generalized models. If the scenario demands domain-specific categories or labels (e.g., support tickets must be routed to 25 internal teams with organization-specific taxonomy), expect a custom classification pattern.

Start by identifying whether the task is analysis (derive insights from text), extraction (pull entities/fields), or generation (draft text). This chapter’s focus is analysis/extraction patterns; generative AI and RAG are covered elsewhere, but your solution may still feed extracted entities into search indexes or downstream automation.

Exam Tip: “PII,” “redaction,” “compliance,” and “sensitive data” keywords often signal a requirement for entity recognition focused on personal data, plus storage/telemetry controls. Don’t answer with “log raw text everywhere” patterns; assume audit and minimization requirements.

• Common trap: Picking sentiment analysis when the scenario asks for “opinion about specific aspects” (aspect-based sentiment) or asks for “reasons” behind dissatisfaction (may require richer extraction or custom modeling).
• Common trap: Ignoring multilingual requirements. If the prompt states “customers write in multiple languages,” your choice must explicitly support language detection and multilingual analysis, or a translation step.

Operationally, expect to reason about batching (processing many documents efficiently), idempotency (retries without double-writing), and evaluation. The exam often rewards designs that include offline evaluation sets, thresholding, and monitoring drift for custom models—especially when routing or classification decisions affect business workflows.

Section 5.4: Conversational experiences and language workflows (design considerations)

Conversational scenarios on AI-102 test whether you can design an end-to-end language workflow, not merely “add a chatbot.” Begin by identifying the conversation type: FAQ-style retrieval, transactional bot (collect slots/fields), agent-assisted support, or voice-enabled assistant. Then map to components: intent recognition, entity extraction, dialog/state management, fallback/escalation, and evaluation.

Even when the exam mentions “conversation,” the real objective is often orchestration: how do you manage context, handle ambiguity, and integrate with external systems? Look for requirements like “confirm before submitting,” “handoff to human,” “maintain conversation state across channels,” or “log conversation transcripts safely.” These indicate you need explicit dialog management patterns and state persistence, plus guardrails around sensitive data.

Exam Tip: If the scenario includes “users ask follow-up questions referencing earlier messages,” prioritize solutions that maintain state and use a consistent conversation history strategy. If it includes “must not answer outside policy,” prioritize moderation/filters and deterministic fallback flows (e.g., provide a form, link, or escalation).

• Common trap: Treating entity extraction as optional. Many transactional workflows fail without robust entity handling (dates, product IDs, locations) and confirmation loops.
• Common trap: Ignoring evaluation. AI-102 frequently expects you to measure intent accuracy, entity F1, containment rate (self-serve vs escalate), and user satisfaction signals.

Design-wise, incorporate “happy path” and “unhappy path.” A strong answer includes: clarification questions when confidence is low, explicit escalation criteria, and safe logging practices. When conversation is paired with enterprise knowledge, it often feeds into Azure AI Search (hybrid retrieval) and uses extracted metadata (topic, product, region) to narrow results.

Section 5.5: Azure AI Search indexing, analyzers, vector + hybrid retrieval

Knowledge mining questions often hinge on your Azure AI Search configuration choices: index schema, analyzers, filters/facets, and whether to use keyword search, vector search, or hybrid retrieval. The exam wants you to distinguish “search over documents” from “store documents.” Azure AI Search is for retrieval; raw content typically sits in Blob Storage, SQL, or Cosmos DB, while the search index stores searchable fields and metadata.

Index design is testable. Identify which fields need full-text search (e.g., content, title), which need filtering (e.g., category, security group, document type), and which need faceting/sorting. If a requirement says “users filter by department and date,” those must be filterable fields. If it says “support exact match for product codes,” choose an analyzer/field configuration that doesn’t over-tokenize identifiers.

Exam Tip: “Hybrid retrieval” is often the best answer when you need both semantic similarity and precise keyword constraints. Vector search improves relevance for conceptual queries, but keyword search is still superior for exact terms, codes, and compliance phrases. Hybrid combines both and is a frequent scenario-fit on AI-102.

• Common trap: Forgetting security trimming. If documents have per-user or per-group access, your index needs fields that enable filtering by ACL/claims, and your query layer must enforce it.
• Common trap: Treating analyzers as an afterthought. Language analyzers impact stemming/tokenization; the wrong analyzer can break recall/precision for multilingual corpora.

Implementation-wise, be ready to recognize the ingestion pattern: data source → indexer → index. If the scenario emphasizes “near real-time updates,” you may need a push pattern (app writes to index) or frequent indexing schedules rather than a slow nightly batch. If it emphasizes “large PDFs and scans,” that signals skillsets/enrichment (next section) to make the content searchable.

Section 5.6: Enrichment pipelines and information extraction (skills, chunking, metadata)

Enrichment pipelines are the bridge between raw content and high-quality retrieval. AI-102 tests whether you understand how Azure AI Search skillsets can extract text, detect language, perform OCR, identify entities/key phrases, and attach metadata to documents during indexing. The key is that enrichment is not “nice to have”—it’s often the only way to make scanned PDFs searchable, to enable filters (entities as facets), or to prepare content for chunk-based retrieval.

Chunking is especially important in modern retrieval patterns. Large documents must be split into smaller passages to improve relevance and reduce noise. A typical design is: extract text → split into chunks (by page/heading/length) → store each chunk as a searchable item with parent document metadata (document ID, source URI, ACL, page number). This enables targeted retrieval and better grounding for downstream applications.

Exam Tip: If the requirement mentions “citations,” “show the paragraph that answered the question,” or “retrieve the most relevant section,” chunking plus metadata (page/section) is implied. Answers that index an entire 200-page PDF as one field are usually wrong.

• Common trap: Losing provenance. If you don’t carry source URL, page number, and extraction confidence forward into the index, you can’t support traceability or human review workflows.
• Common trap: Over-enrichment. Adding every possible skill increases cost and latency. Choose only what supports the scenario (e.g., OCR only when documents are scanned images).

From the chapter’s “domain practice set” perspective, the exam frequently combines all three domains: a user uploads images/PDFs (vision + Document Intelligence), you extract entities and PII (NLP), then index chunks with metadata (AI Search) to support secure retrieval. The correct solution is usually the one that shows a cohesive pipeline: ingestion, extraction/enrichment, indexing, and a query experience that respects access control and returns explainable results.

Section 6.1: Mock exam instructions, timing, and scoring approach

Your goal is to simulate exam conditions closely enough that timing, fatigue, and uncertainty become familiar. AI-102 typically mixes standalone questions and case-study style sets. In your mock, use two blocks to mirror this: a first pass that emphasizes breadth and a second pass that stresses endurance and focus. Set a fixed time window and do not pause the clock for “quick research.” If you must look something up during your learning phase, mark it and move on.

Scoring should be objective and diagnostic. Track: (1) accuracy by domain (plan/manage; generative AI; agents; vision; NLP; knowledge mining), (2) error type—concept gap vs. misread vs. “two good answers,” and (3) time per item. Your improvement plan should target the highest-impact combination: frequent + costly errors.

• Pass 1 (Part 1): Moderate speed, focus on correct service selection and configuration details (keys vs. managed identity, network isolation, content safety, RAG mechanics).
• Pass 2 (Part 2): Strict time boxing, focus on eliminating distractors quickly and validating constraints (latency, data residency, scaling, monitoring).
• Review: Do not just record the right answer—write the reason the wrong options fail the scenario constraints.

Exam Tip: A “slow correct” today can become “fast correct” only if you practice the elimination logic. If you only practice by re-reading notes, you’ll stay slow under pressure.

Section 6.2: Full mock exam—Domain mix set A (exam-style scenarios)

Mock Exam Part 1 (Set A) should feel like a realistic cross-domain sprint. Expect scenarios that combine at least two objectives—e.g., an Azure OpenAI chatbot that must use enterprise documents (Azure AI Search) while meeting security and monitoring requirements. Your job is to identify “hard constraints” first: identity model (managed identity vs keys), network (private endpoints), compliance (data residency), and safety (content filtering, jailbreak resistance). Only then select services and patterns.

Key concept clusters that frequently appear together in Set A-style items:

• RAG implementation: chunking strategy, embedding model choice, top-k retrieval, semantic ranking, citations/grounding, and when to use hybrid search. Common trap: treating “vector search” as sufficient without considering chunk overlap, metadata filtering, or freshness of indexed data.
• Azure AI Search indexing/enrichment: skillsets, indexers, data sources, and enrichment pipelines. Common trap: confusing Document Intelligence extraction with Search enrichment—Document Intelligence can extract structure, but Search skillsets orchestrate enrichment into an index.
• Plan/manage readiness: monitoring and cost controls (Azure Monitor, logging, quotas), deployment choices, and scaling. Common trap: picking an architecture that works in dev but ignores rate limits, throughput, or multi-region needs.

Exam Tip: In scenario questions, the “best answer” is usually the one that satisfies all constraints with the fewest moving parts. Over-engineered options often hide a miss (extra service that doesn’t meet a stated requirement or adds avoidable risk).

As you work Set A, practice writing a 1–2 sentence “requirement extraction” before selecting an answer. This prevents the most common failure mode: noticing one keyword (like “OCR”) and choosing a service without checking for structured extraction, confidence scores, or downstream indexing needs.

Section 6.3: Full mock exam—Domain mix set B (exam-style scenarios)

Mock Exam Part 2 (Set B) is the endurance pass. You are testing whether you can keep quality high when you’re tired—exactly when misreads happen. This set should lean into agentic solutions, evaluation/safety, and “choose the best orchestration” items. Expect scenarios like: an agent that calls tools (Search, internal APIs), maintains state, must be grounded to enterprise data, and must refuse unsafe instructions.

Focus areas that commonly drive Set B errors:

• Agent orchestration and tool use: distinguish “LLM calling a tool” from a full agent design (planning, state, retries, tool schemas). Trap: assuming prompt-only approaches solve reliability—exam scenarios often require explicit tool definitions, structured outputs, and guardrails.
• Safety and governance: Azure OpenAI content filters, system messages, prompt injection defenses, and data leakage controls. Trap: relying solely on “content safety” when the issue is grounding (e.g., require citations, restrict to retrieved passages, or block tool calls without policy checks).
• Evaluation: offline evaluation (test sets, regression), online monitoring (quality signals, user feedback), and hallucination metrics. Trap: choosing “manual spot checks” when the scenario demands repeatable evaluation pipelines and measurable criteria.
• NLP and vision integration: when to use Text Analytics (language, sentiment, NER) versus a custom model; when OCR alone is insufficient and Document Intelligence is required for key-value pairs/tables. Trap: picking OCR for structured forms where layout understanding is needed.

Exam Tip: If an option promises “highest accuracy” but introduces a new dependency (extra service, custom training) without justification in the requirements, it’s often a distractor. The exam rewards alignment, not maximal capability.

Time boxing matters more in Set B. If you exceed your target time on an item, flag it and move on. The exam is designed so that some questions are inherently slower—don’t let them steal time from easier points.

Section 6.4: Answer review framework (why the distractors are wrong)

After both mock parts, use a consistent review framework to convert mistakes into durable wins. The key is to analyze distractors—the wrong answers that look attractive—because that is what the real exam uses to differentiate prepared candidates. For every missed (or guessed) item, write: (1) the scenario’s top 2–3 constraints, (2) the correct approach, and (3) the specific reason each distractor fails.

Use these common distractor patterns to speed your analysis:

• Service confusion: Azure AI Search vs. Azure OpenAI “memory,” Document Intelligence vs. OCR, Text Analytics vs. custom ML. Distractor fails because it cannot produce required outputs (citations, key-value pairs, structured extraction) or lacks integration primitives.
• Security mismatch: keys where managed identity is required, public endpoints where private networking is required, or missing RBAC boundaries. Distractor fails because it violates explicit security/compliance language.
• Operational gap: no monitoring, no throttling strategy, ignores quotas/rate limits, no rollback plan. Distractor fails because it cannot meet reliability or deployment readiness objectives.
• RAG flaw: retrieval without chunking/metadata filters, embedding mismatch, or no grounding/citations. Distractor fails because it increases hallucination risk and cannot justify answers.

Exam Tip: When two options both “work,” look for the hidden requirement: auditing, least privilege, network isolation, evaluation repeatability, or cost control. The best answer usually mentions the operational control plane, not just the model.

Finally, categorize each error: knowledge gap (study), process gap (slow reading or missing constraints), or strategy gap (not eliminating). Your weak spot analysis in the next section should be built from these categories, not from raw score alone.

Section 6.5: Final objective checklist across all official domains

Use this checklist as your final review map. You are not trying to re-learn everything—only to confirm you can recognize the tested patterns and make correct choices under constraints.

• Plan and manage an Azure AI solution: choose correct resources (Azure OpenAI, AI Search, Document Intelligence, Vision, Language), apply identity (managed identity, RBAC), secure networking (private endpoints), monitor (logs/metrics/traces), manage cost (quotas, scaling, batching), and deploy safely (versioning, rollback, environment separation).
• Implement generative AI solutions: prompt engineering (system vs user, few-shot, structured outputs), RAG patterns (chunking, embeddings, hybrid search, citations), safety (content filters, prompt injection mitigation), and evaluation (quality metrics, regression tests).
• Implement an agentic solution: tool/function calling, orchestration flow, state management, grounding to trusted data, and guardrails (policy checks before tool calls, constrained outputs, audit logs).
• Implement computer vision solutions: image analysis vs OCR vs Document Intelligence; when layout/structure matters; confidence/thresholding; integrating outputs into search and downstream workflows.
• Implement NLP solutions: entity extraction, classification, summarization patterns, conversational design constraints, and evaluating model outputs for accuracy and safety.
• Knowledge mining and information extraction: AI Search indexing, indexers/data sources, skillsets/enrichment, chunking strategies, metadata filters, and retrieval tuning for relevance and grounding.

Exam Tip: If you cannot explain “why this service, not the neighboring one,” you are not done. AI-102 frequently tests boundaries between similar services and overlapping capabilities.

Before exam day, do a targeted mini-drill: pick one weak domain and write a one-page “decision tree” (e.g., OCR vs Document Intelligence vs Vision; or keyword vs semantic vs vector search). This reduces hesitation and prevents second-guessing.

Section 6.6: Exam-day strategy—case studies, review flags, and time boxing

On exam day, strategy protects your score. Many candidates lose points not from lack of knowledge but from time mismanagement and overthinking. Your priorities: (1) bank easy points early, (2) prevent a few hard questions from consuming the entire session, and (3) avoid unforced errors in case studies.

For case-study style items, read in this order: business requirements → constraints (security/compliance, networking, latency, cost) → existing environment → only then the question. Build a quick “must/should” list. The most common trap is answering based on the architecture you would build in real life, rather than what the prompt explicitly requires.

• Time boxing: set a per-question target. If you exceed it, flag and move on. Return later with fresh eyes.
• Use review flags intentionally: flag only items where additional time is likely to change the outcome (e.g., two close options). Do not flag items you truly don’t know—guess, record a mental note, and move forward.
• Elimination technique: remove options that violate constraints first (network/public access, keys vs managed identity, missing evaluation/monitoring, wrong service for structured extraction).

Exam Tip: If an answer choice includes specific operational controls (private endpoint, RBAC, monitoring, citations/grounding) and the scenario mentions risk or compliance, that option often aligns with the exam’s intent.

Finally, do a last-minute mental checklist before submitting: Did you misread “must” vs “should”? Did you ignore a security requirement? Did you pick a service that can’t produce the requested output format (tables, key-value pairs, citations, structured JSON)? This 20-second scan catches the most expensive mistakes.