AI-102 Azure AI Engineer: Full Exam Prep with Labs

Section 1.1: AI-102 overview, skills outline, and role expectations

AI-102 is designed for the Azure AI Engineer role: you’re expected to design and implement AI solutions that are production-minded—governed, secured, monitored, and cost controlled. In practice, the exam centers on solution selection and configuration: which Azure AI service to use, how to deploy it, and how to integrate it with identity, networking, and observability.

Map your preparation to the outcomes you’ll be tested on. You will plan and manage solutions (resource organization, keys/managed identity, private networking, logging, and budgets). You will implement generative AI solutions with Azure OpenAI, including prompt orchestration patterns and safe deployments. You will build agentic solutions that call tools/functions, maintain memory, and evaluate responses. You will implement computer vision (image/video analysis, OCR), NLP (text analytics, translation, summarization, conversational patterns), and knowledge mining using Azure AI Search with enrichment pipelines.

• What the exam is really checking: Can you choose the right service and configure it correctly under constraints (security, cost, latency, compliance)?
• What it is not: Deep research-level ML math. You’re not being graded on deriving loss functions; you’re being graded on Azure implementation decisions.

Common trap: Treating services as interchangeable. For example, OCR can appear in multiple places (Vision vs. Document Intelligence). The exam will give hints like “structured forms,” “prebuilt invoices,” or “layout extraction,” which should push you toward Document Intelligence rather than generic image analysis.

Exam Tip: Watch for “role expectation” cues: if the prompt mentions deployment slots, monitoring, private endpoints, or RBAC, you’re being tested on the plan/manage domain even if the scenario involves AI features.

Section 1.2: Registration, scheduling, accommodations, and exam policies

Register for AI-102 through Microsoft Learn/Certification dashboard and schedule via the authorized testing provider (typically online proctoring or a test center). Lock in a realistic date early—your study plan becomes more effective when it has a firm deadline. When scheduling, choose a time when you can perform sustained scenario reading; this exam includes longer prompts and multi-step reasoning.

If you need accommodations (extra time, assistive technology, etc.), request them before booking the final appointment. Build buffer time into your timeline; accommodations approval can take time depending on documentation requirements.

Policies matter because they affect your preparation workflow. For online proctoring, confirm your test environment (quiet room, cleared desk, stable internet). For test centers, plan travel and arrive early. Understand ID requirements and the rules on breaks. If you plan to use the “last week” for heavy practice, make sure your exam appointment is not at risk from schedule changes or policy conflicts.

• Policy-driven study constraint: You cannot rely on external notes during the exam. Practice doing full case-study reasoning from memory.
• Device constraint (online): Corporate devices sometimes block secure browsers. Test your system setup well in advance.

Common trap: Treating logistics as an afterthought and losing momentum due to rescheduling. In exam prep, consistency beats intensity—avoid disruptions that break your spaced repetition loop.

Exam Tip: Schedule your exam for a time of day when you typically do labs. Your brain performs best in the environment you trained in—match your peak focus window.

Section 1.3: Scoring, question types, case studies, and time management

AI-102 is scored on a scaled model; you’re aiming to demonstrate consistent competence across domains rather than perfection in one area. Your study plan should therefore avoid “pet topics” and ensure each objective area gets repetitions. A baseline assessment early helps you identify weak domains and set a target score. Many candidates improve fastest by fixing misreads and service confusion rather than learning brand-new content.

Expect a mixture of question styles: scenario-based multiple choice, multi-select, ordering/sequence, and case studies that include longer background with requirements, existing environment, and constraints. Case studies often test planning and integration: identity, networking, security, cost, and monitoring combined with an AI service choice.

• Case study approach: First read requirements and constraints (security, data residency, latency, budget). Then map to services. Finally validate configuration details (auth method, network access, logging, scaling).
• Time management: Don’t “wrestle” with a question you’re uncertain about. Mark it, move on, and return after you’ve secured easier points.

Common traps: (1) Missing one keyword like “must use customer-managed keys,” “private endpoint required,” or “no public internet,” which eliminates otherwise plausible options. (2) Overengineering—selecting multiple services when one meets the requirement. (3) Confusing data plane vs. management plane permissions (RBAC vs. API keys vs. managed identity).

Exam Tip: When two answers seem close, choose the one that best satisfies constraints with the fewest assumptions. If the scenario mentions Azure Monitor/Application Insights, the exam likely expects you to wire diagnostics and track metrics/logs—not just “deploy the model.”

Section 1.4: Study strategy for beginners: labs-first, notes, and review loops

If you’re new to Azure AI, use a labs-first strategy. The exam is practical: it rewards familiarity with what settings look like in the portal, what fails when identity is misconfigured, and how to reason about costs and quotas. In this course, every major objective (Azure OpenAI, agents, Vision, NLP, Search/enrichment, and management) should be paired with hands-on work. Your labs are your “memory anchors.”

Use a tight note system: one page per service area, written in decision language (when to use it, key configurations, security defaults, pricing drivers, and top limitations). Add “if you see X requirement, choose Y” rules. This transforms studying into pattern recognition—the exact skill exams measure.

• 2–4 week plan with spaced repetition: study in short daily sessions; revisit notes and missed concepts on day 2, day 7, and day 14.
• Review loop: Lab → summarize decisions → attempt practice items → analyze misses → update notes → repeat.
• Baseline and target: Take an early baseline assessment to identify domain gaps; set a target score that includes buffer (e.g., aim higher than the minimum passing level to absorb exam-day variance).

Common trap: Passive reading. Candidates who only watch videos often fail case studies because they can’t apply constraints under time pressure. Your goal is to be able to answer: “Which service, which authentication, which network posture, which monitoring, and which cost control?” without looking anything up.

Exam Tip: Keep a “mistake log” categorized by objective (OpenAI, agents, Vision, NLP, Search, management). Most score gains come from eliminating repeat mistakes, not from adding new notes.

Section 1.5: Setting up Azure: subscriptions, resource groups, and budgets (prep)

Your Azure environment setup is part of exam readiness because it mirrors real-world governance: subscriptions, resource groups, naming, tagging, and cost controls. Start with a dedicated subscription (trial, pay-as-you-go, or a sandbox provided by your organization). The key is isolation: you want your labs separated from work production resources and easy to delete.

Create a consistent resource group strategy. For example, one resource group per chapter or per solution (e.g., rg-ai102-ch01, rg-ai102-openai). This helps you clean up quickly and reduces accidental cross-dependencies. Apply tags like Course=AI-102, Owner=YourName, Expiry=YYYY-MM-DD so you can track spend and enforce cleanup.

• Budgets and alerts: Configure a monthly budget and set alert thresholds (e.g., 50%, 80%, 100%). Many AI services have usage-based pricing; budgets prevent “surprise” bills during experimentation.
• Quotas and regions: Some services (notably Azure OpenAI) require access approval and have regional availability constraints. Plan early so your study timeline isn’t blocked.
• Identity choice: Prefer Microsoft Entra ID and managed identities for apps where possible; use keys only when the scenario requires it. This aligns with exam expectations around secure design.

Common trap: Creating resources across multiple regions randomly. Later, when a case study asks about data residency, private endpoints, or latency, you’ll have trouble mentally modeling the architecture. Keep labs region-consistent unless the lab explicitly tests multi-region design.

Exam Tip: Practice deleting resource groups at the end of a lab. It trains you to think in lifecycle terms (deploy, monitor, retire), which is a recurring theme in AI-102 planning and management scenarios.

Section 1.6: Tooling for the course: Azure portal, CLI, SDKs, and Git workflow

AI-102 assumes you can work across the Azure portal and code. Use the portal to learn where settings live (networking, identity, diagnostics). Use automation tools to make deployments repeatable—an exam-relevant skill because many questions imply infrastructure-as-code thinking even when they don’t name it explicitly.

Set up four pillars of tooling. First, the Azure portal for resource creation, monitoring, and policy-level configuration. Second, Azure CLI for quick provisioning, querying resource properties, and scripting cleanup. Third, SDKs (Python or C# are common) to call Azure AI services and implement patterns like tool/function calling, retrieval with Azure AI Search, or Vision/NLP requests. Fourth, Git for versioning your lab code and notes so you can replay labs and track changes.

• Recommended workflow: Clone a course repo → create a branch per chapter → commit after each lab with a short message describing what you learned (e.g., “Add managed identity auth for Search indexing”).
• Environment hygiene: Use .env files locally, never commit keys, and prefer managed identities where possible. This matches exam expectations around secret handling.
• Observability habit: When you deploy a service, immediately check diagnostics settings and metrics. The exam frequently rewards candidates who operationalize AI.

Common trap: Treating SDK code as “optional.” Many exam scenarios describe applications that must authenticate, call endpoints reliably, handle throttling, and log outputs for evaluation. Even if you’re not a full-time developer, you must be comfortable reading small code snippets and reasoning about configuration.

Exam Tip: When practicing, force yourself to switch between portal and CLI/SDK views of the same resource (name, endpoint, region, SKU, identity). The exam often describes a requirement in one “language” (policy/security) and expects the answer in another (service configuration).

Section 2.1: Solution planning: selecting Azure AI services and constraints

The AI-102 exam frequently starts with requirements and asks you to choose services and an architecture that satisfy constraints. Your first planning step is to map the workload to the correct Azure AI building blocks: Azure AI Services (Vision, Language, Speech), Azure AI Search for retrieval and enrichment, Azure OpenAI for generative tasks, and Azure Machine Learning when you need custom training/ML lifecycle rather than “prebuilt” capabilities. The exam expects you to recognize when a requirement is best met by a purpose-built service (for example, OCR with Azure AI Vision) instead of “just use a large language model.”

Constraints matter as much as capabilities. Look for: data residency (region), restricted networking (private endpoints), key management (customer-managed keys), throughput (quotas/TPM), latency (regional proximity), and operational constraints (SLA, monitoring). If the scenario mentions “no data stored” or “PII,” treat it as an instruction to use proper data handling plus governance controls; it does not automatically disqualify managed services, but it does influence logging, encryption, and access control choices.

Exam Tip: In multiple-choice scenarios, identify the “hard constraint” first (for example, “private network only” or “must use CMK”). Eliminate answers that violate it, even if they seem feature-rich. The exam rewards constraint-driven architecture, not maximal functionality.

• Use Azure AI Search when you need enterprise retrieval (filtering, ACL trimming patterns, indexing pipelines) and knowledge mining.
• Use Azure AI Vision/Language for deterministic extraction and classification tasks where prebuilt models are tested and cost-effective.
• Use Azure OpenAI for generative summarization, conversational patterns, and prompt orchestration—then wrap it with governance and safety.

Common trap: confusing “Azure AI Studio” (a management and development experience) with a runtime service. The runtime endpoints are Azure resources (Azure OpenAI, AI Services, Search), and your architecture must account for how callers authenticate, how traffic flows, and how you audit usage.

Section 2.2: Azure AI resource provisioning, regions, quotas, and naming standards

Provisioning questions on AI-102 tend to mix “what to create” with “where and how.” Be ready to reason about region availability, capacity, and quotas. Azure OpenAI is region-limited and quota-governed; many scenario stems include “model not available in region” or “quota exceeded.” The correct action is often to deploy in a supported region, request quota increase, or choose a different model deployment—rather than changing application code.

Resource organization (subscriptions, resource groups, and naming) is also tested indirectly through governance and operations. Apply consistent naming to support auditing and automation, such as: {org}-{env}-{workload}-{region}-{resource} (for example, contoso-prod-support-eus-aoai). Separate environments (dev/test/prod) into distinct resource groups or subscriptions to limit blast radius and enable clear cost allocation.

Exam Tip: When you see “multiple teams” and “chargeback,” think: separate subscriptions or at least distinct resource groups plus tags, then enforce with Azure Policy. Cost allocation is a management-plane design, not an app code change.

• Regions: choose based on data residency, latency, and service/model availability.
• Quotas: know that Azure OpenAI has throughput constraints; scaling requires quota management and sometimes multiple deployments.
• Tags: enforce standard tags (CostCenter, Owner, DataClassification, Environment) for governance and reporting.

Common trap: assuming “global” services remove regional planning. Even when a service is multi-tenant, you still select a region for the resource, and that region affects compliance, latency, and which private networking options you can use.

Section 2.3: Security and governance: RBAC, Managed Identity, Key Vault, policies

The exam strongly emphasizes identity and governance. For access control, prioritize Microsoft Entra ID (Azure AD) with Azure RBAC for management-plane permissions, and use service-specific auth (keys, tokens) only when necessary. In secure designs, application components (App Service, Functions, AKS, Logic Apps) should use Managed Identity to access other Azure resources without storing secrets in code or configuration files.

Key Vault is the go-to for secrets, keys, and certificates, and it becomes mandatory in scenarios mentioning secret rotation, audit requirements, or customer-managed keys (CMK). If a stem says “store API keys securely,” the exam typically expects: put secrets in Key Vault, grant access via Managed Identity, and restrict Key Vault access via RBAC/access policies plus networking controls.

Exam Tip: Distinguish between RBAC for “who can manage the resource” and application authentication for “who can call the endpoint.” Many wrong answers swap these concepts (for example, using RBAC when the question is about runtime API access).

• Use least privilege: grant only required roles (for example, Cognitive Services User vs Contributor) to identities.
• Use Azure Policy to enforce governance: required tags, allowed regions, deny public endpoints, require diagnostic settings.
• For sensitive workloads, plan data protection: encryption at rest (platform or CMK where supported) and controlled logging to avoid storing prompts/responses with PII.

Common trap: “Just use keys in app settings.” That may work technically, but exam scenarios with security requirements almost always want Managed Identity + Key Vault. Another trap is forgetting that governance is continuous: policies and role assignments must be repeatable across environments, not configured manually once.

Section 2.4: Networking patterns: private endpoints, VNet integration, firewall rules

Networking shows up in AI-102 as “how do we make this private?” or “how do we restrict access to specific networks?” Private endpoints (Azure Private Link) are the standard pattern to bring supported Azure AI services onto a private IP in your virtual network, removing public inbound exposure. If the scenario states “no public internet access” or “data exfiltration risk,” your answer should usually include private endpoints, private DNS zones, and disabling public network access where supported.

VNet integration is the complementary pattern for outbound calls from a compute service (App Service/Functions) into a VNet to reach private endpoints. Firewall rules (IP allowlists) are a lighter control for public endpoints but are often insufficient for strict compliance scenarios. The exam expects you to select the strongest control that meets the requirement.

Exam Tip: If the requirement is “only accessible from our corporate network,” prefer private endpoints over IP allowlists. IPs change, bypass paths exist, and allowlists still expose a public endpoint. Private Link is the usual “exam-safe” answer when available.

• Private Endpoint: inbound access to PaaS over private IP; pair with Private DNS for name resolution.
• Disable public network access: reduces attack surface; commonly combined with Private Link.
• Firewall rules: acceptable for less strict cases (for example, restrict to a known NAT gateway egress IP).

Common trap: forgetting DNS. With Private Link, you must ensure the service FQDN resolves to the private IP via a private DNS zone; otherwise clients may still try the public endpoint. Another trap is mixing up “VNet injection” vs “VNet integration”—the exam is typically checking whether you know how the app reaches private endpoints, not just that a VNet exists.

Section 2.5: Reliability and operations: monitoring, diagnostics, alerts, SLAs

Operational readiness is a core competency: the exam tests whether you can observe and support AI services in production. Use Azure Monitor as the umbrella, with Log Analytics for queries, Application Insights for application telemetry, and diagnostic settings to route service logs/metrics to a workspace, storage account, or Event Hub. For Azure AI resources, enabling diagnostic settings is often the difference between “it works” and “we can troubleshoot incidents.”

Plan alerting based on symptoms and service limits: latency spikes, throttling/429s, quota consumption, error rates, and dependency failures. Tie alerts to action groups (email, SMS, webhook, ITSM connector) and define runbooks. SLAs matter in multi-tier solutions: the end-to-end availability is the product of dependencies, so adding more services without resilience can reduce your effective SLA.

Exam Tip: When you see throttling, think “retry with exponential backoff + monitor quota and capacity,” not “increase VM size.” For managed AI endpoints, scaling is usually quota/deployment-related rather than compute sizing.

• Enable diagnostic logs early; enforce via Azure Policy so new resources aren’t created without logging.
• Track both platform metrics (requests, errors, latency) and application metrics (prompt size, token usage, user-level latency).
• Design for failure: timeouts, circuit breakers, fallback models/services, and graceful degradation.

Common trap: relying solely on client-side logs. The exam expects you to centralize telemetry in Azure Monitor/Log Analytics for audit and incident response. Another trap is assuming SLAs apply to your app automatically; you must design redundancy (where supported) and operational procedures.

Section 2.6: Cost management and deployment: budgets, autoscaling, CI/CD patterns

Cost and deployment questions often hide behind “management and governance scenarios.” Use Azure Cost Management to set budgets, alerts, and cost analysis by subscription/resource group/tag. For AI workloads, the major drivers are request volume, token usage (for generative), indexing/storage (for search), and compute for any custom processing. Implement guardrails: budgets with alert thresholds, quota limits where applicable, and application-level controls (rate limiting, prompt size limits, caching of responses when appropriate).

Autoscaling depends on the component. For App Service/Functions/AKS, configure autoscale rules based on CPU, memory, queue length, or custom metrics. For Azure OpenAI, “scaling” is primarily about deployments and quotas rather than adding instances; you may create multiple model deployments for load distribution, but you still need quota and monitoring to avoid 429s.

Exam Tip: In CI/CD scenarios, prefer Infrastructure as Code (Bicep/ARM/Terraform) to make governance repeatable: role assignments, diagnostic settings, private endpoints, and tags should be deployed consistently. The exam often rewards “codify the platform” over “configure manually in the portal.”

• Budgets: set at subscription/resource group; alert early and route to action groups.
• Deployment patterns: blue/green or canary for app code; version model deployments separately and test with staging traffic.
• Secure pipelines: store secrets in Key Vault; use federated credentials/managed identities for pipeline auth where possible.

Common trap: optimizing only compute cost while ignoring AI-specific cost drivers (tokens, indexing, calls). Another trap is treating deployment as purely application code—AI solutions include dependent resources (identity, network, monitoring) that must be deployed and validated together for a compliant production release.

AI-102 expects you to understand how Azure OpenAI is operationalized: you select a model family, create a deployment, then call that deployment from your app. A common exam trap is confusing “model name” with “deployment name.” In Azure OpenAI requests, you typically target the deployment; the model can be swapped behind it without changing client code (useful for controlled upgrades).

Tokens are the accounting unit for context length and cost. Every request has input tokens (system/user prompts, tool definitions, retrieved passages) and output tokens (the model’s completion). When the scenario mentions “long documents,” “multi-turn chat,” or “RAG with many citations,” the hidden constraint is usually context window or token budget. If you exceed the model’s maximum context, the call fails or you must truncate/shorten inputs.

Throughput is often tested via rate limits and capacity. If the prompt mentions “spikes,” “high concurrency,” or “timeouts,” you should think about right-sizing deployments, controlling max output tokens, caching, and reducing prompt bloat. Also watch for synchronous versus batch-like patterns: generation is interactive and latency-sensitive; offline summarization can be queued and parallelized.

• Choose models based on task: chat/completions for dialog, embeddings for vector search, vision-capable models when images are part of the prompt.
• Manage token usage: shorten system prompts, limit retrieved chunks, and cap max output tokens.
• Design for throughput: implement retries with backoff, and avoid calling the model multiple times per user action unless necessary.

Exam Tip: If an answer option says “increase temperature to improve throughput,” it’s wrong. Temperature affects randomness, not performance. Throughput improvements come from capacity, concurrency control, smaller prompts, and smaller outputs.

The exam tests prompt engineering primarily as a reliability tool, not artistry. You need deterministic workflows: extract entities, generate structured summaries, classify tickets, or produce an action plan that downstream code parses. The highest-leverage concept is role separation: system prompts define non-negotiable behavior (format, safety, tool use rules), while user prompts carry the task and data.

Few-shot prompting (including examples) is a frequent solution when “the model sometimes misclassifies” or “format is inconsistent.” Provide 2–5 tight examples that match the desired schema. However, few-shot increases token usage; if the scenario also mentions cost or long context, the better answer might be “use a smaller schema, fewer examples, or move repeated instructions into the system message.”

For structured outputs, AI-102 scenarios often want strict JSON. Your prompt should: (1) specify a JSON schema, (2) forbid extra keys, and (3) define how to handle uncertainty (e.g., nulls). If the platform supports “JSON mode” or structured outputs, prefer it—this reduces parsing failures. If not, you must instruct the model to output only JSON and validate it in code.

• System message: formatting rules, allowed tools, refusal behavior, and citation requirements.
• User message: the variable business content and request.
• Few-shot: examples that mirror your real inputs (don’t use unrealistic toy examples).

Exam Tip: When two answer choices both “improve accuracy,” choose the one that makes the output verifiable (schema + validation). The exam rewards designs that fail safely and predictably.

Common trap: assuming “lower temperature” guarantees correct JSON. It helps reduce variance, but you still need explicit constraints, structured output support where available, and server-side validation with fallback handling.

Azure OpenAI in enterprise settings is never just a model call; it is a governed system. AI-102 frequently tests whether you can deploy safely and comply with organizational policies. You should be ready to select and configure content filtering, define what data can be sent to the model, and implement logging that supports audits without leaking sensitive information.

Content safety controls address both user input and model output. If the scenario mentions harmful content, policy violations, or a public-facing chatbot, you should think “defense in depth”: pre-check inputs, post-check outputs, and implement refusal/redirect flows. Do not rely on a single layer (for example, “just add a disclaimer in the prompt”).

Data handling is a major trap area. Questions often include cues like “PII,” “medical data,” “financial records,” or “internal IP.” The correct design usually includes data minimization (send only what’s needed), redaction/tokenization before sending prompts, and access control around logs and storage. Also consider where retrieved documents live in RAG—if indexing confidential content, ensure Azure AI Search security trimming and proper authentication.

• Apply content filters and define actions on violations (block, warn, human review).
• Log safely: capture request IDs, token counts, latency, and policy events; avoid storing raw prompts with PII unless required and secured.
• Implement governance: RBAC, private networking options, and key management for secrets.

Exam Tip: If an option says “store all prompts and completions unredacted for troubleshooting,” treat it as suspect unless the scenario explicitly requires it and includes compensating controls (encryption, access restrictions, retention policy). The exam prefers minimal necessary retention.

Retrieval-augmented generation (RAG) is a core AI-102 generative pattern: use Azure AI Search to retrieve relevant passages, then ground the model response. The exam checks whether you understand why RAG beats “paste the whole document,” and how to tune retrieval quality with chunking and embeddings.

Chunking is not arbitrary. If chunks are too large, you waste tokens and dilute relevance; too small, you lose context and citations become fragmented. A practical rule is to chunk by semantic boundaries (headings/sections) and include overlap to preserve continuity. When the scenario says “answers are incomplete” or “citations don’t support claims,” suspect poor chunking, missing overlap, or retrieving too few passages.

Embeddings convert text to vectors for similarity search. In Azure AI Search you commonly use vector fields plus metadata filters (e.g., department, date, security label). Many exam items want a hybrid approach: lexical (keyword/BM25) + vector search to handle both exact terms and semantic similarity. If the prompt contains product codes, legal clauses, or exact IDs, keyword signals matter.

Citations are a reliability feature. You should instruct the model to cite sources and restrict answers to retrieved content; in code, you pass retrieved chunks (with source metadata) and require the output to reference them. This reduces hallucinations and is a strong “enterprise grounding” indicator.

• RAG flow: ingest → chunk → embed → index → retrieve → generate with citations.
• Improve relevance: tune top-K, add filters, and use hybrid retrieval.
• Reduce hallucination: require “answer only from sources” and include citation IDs/URLs.

Exam Tip: If the scenario demands “use the latest policy” or “only documents user is permitted to view,” the correct answer usually involves metadata filtering and security trimming in Azure AI Search, not just prompt instructions.

Beyond single prompts, AI-102 expects you to recognize orchestration patterns: tool/function calling, templates for repeatable prompts, and evaluation loops that catch regressions. When you see “agentic” behaviors—booking, searching internal systems, or executing steps—the correct architecture often uses tool calling with explicit schemas, not free-form text parsing.

Tool calling is about controlled delegation: the model proposes a function call (name + JSON arguments), your app executes it, then returns results to the model. Exam scenarios emphasize safety: validate arguments, enforce allowlists, and apply authorization checks in the tool layer. A common trap is assuming the model can be trusted to call “deleteUser” responsibly; in reality, your orchestrator must prevent dangerous operations or require human approval.

Templates standardize prompts across environments. Put stable instructions (format, tone, citation rules) into versioned templates. This supports change management—an exam favorite when the scenario mentions “updates caused failures.”

Evaluation and guardrails make generative systems testable. Use automated checks: JSON validity, citation presence, toxicity checks, groundedness against retrieved sources, and regression tests on a golden dataset. If the scenario asks how to “measure quality” or “prevent policy violations,” look for answers involving evaluation pipelines and content safety gates, not manual spot checks alone.

• Pattern: plan → tool call → observe result → finalize response.
• Guardrails: schema validation, allowlisted tools, max steps, and refusal policies.
• Evaluation: offline test sets + online monitoring for drift and failures.

Exam Tip: If an option proposes “let the model directly access the database,” prefer an architecture where the app mediates access via constrained tools and enforces RBAC. The exam prioritizes controllability.

The final skill is operational troubleshooting—often presented as a vague complaint: “too slow,” “too expensive,” or “it worked last month.” Your job is to map symptoms to likely causes and select the most targeted mitigation.

Latency issues usually come from (1) large prompts (RAG stuffing too many chunks), (2) large outputs (no max tokens), (3) multiple sequential model calls, or (4) slow retrieval (unoptimized search/index). Fixes include reducing top-K, compressing context (summarize chunks before final answer), caching frequent retrieval results, and parallelizing independent calls. If the scenario includes “peak hours,” consider throttling and backoff, plus capacity planning for deployments.

Cost issues track tokens. Reduce repetitive instructions (move to system template), cap completion length, and avoid unnecessary few-shot examples. For RAG, improve retrieval precision so you pass fewer, better chunks. Another common cost trap is using a high-end model for simple classification; a smaller model or a rules-first approach may be the expected answer.

Prompt drift happens when small prompt edits or new documents change behavior unexpectedly. Countermeasures: version prompts, store test fixtures, run evaluations before rollout, and monitor key metrics (format error rate, refusal rate, groundedness). In production, implement fallback paths—if JSON parsing fails, retry with a stricter system message or use structured output features.

• Observe: token counts, latency breakdown (search vs generation), and failure rates.
• Optimize: reduce context, tighten schema, and use caching.
• Stabilize: prompt versioning + regression evaluation to catch drift early.

Exam Tip: When troubleshooting, choose answers that add measurement (logging token usage, timing search vs generation) before guessing. AI-102 favors engineers who instrument, then optimize.

Section 4.1: Agentic concepts: planners, executors, and task decomposition

An agentic solution is typically a control loop that transforms a user goal into actions and tool calls, then refines the result until it meets a stop condition. The exam often distinguishes between (1) a planner that decomposes the task and selects tools, and (2) an executor that performs each step and verifies outcomes. This separation improves reliability: planners can be optimized for reasoning, while executors focus on correct tool usage and validation.

Task decomposition shows up in scenarios like “generate a quarterly report”: the agent should break it into retrieving data, validating totals, drafting narrative, and checking citations. A robust loop is usually: Plan → Act (tool call) → Observe (tool result) → Reflect/Decide → Repeat or Finalize. On AI-102, you may be asked to identify which component is missing when an assistant hallucinates data: often it’s the “Act/Observe” grounding step (no retrieval) or a missing verification step (no reflection/validation).

Exam Tip: If the requirement includes “must handle multi-step workflows” or “must automate tasks,” choose an agent loop with explicit state and tool calls over a single prompt. If the requirement includes “deterministic output,” emphasize structured outputs and validation at each step.

Common trap: assuming “chain-of-thought” is an architecture. The exam is not asking you to expose private reasoning; it’s asking for a system that can reliably call tools, check results, and stop. Another trap is letting the model self-initiate steps indefinitely; you need termination criteria (max iterations, success checks, error thresholds) and a fallback path (handoff to human, ask clarifying question, or return partial results with caveats).

Section 4.2: Tooling and function calling: schemas, validation, and retries

Tool/function calling is the exam’s practical mechanism for making an agent do real work: call a search endpoint, fetch a record, create a ticket, or run a calculation. AI-102 expects you to understand schema-driven calls: define function names, descriptions, and a JSON schema for arguments so the model emits structured input rather than free text. This reduces ambiguity and makes it easier to validate and log.

Validation is a key tested concept. You should validate required fields, types, ranges, and enums before executing a tool. For example, if an agent calls create_refund(orderId, amount), validate that amount is positive, within policy thresholds, and that the caller is authorized. The correct answer in many exam stems is “use function calling + server-side validation,” not “improve the prompt.”

• Schemas: constrain arguments (e.g., enum for priority, regex for IDs).
• Retries: retry on transient failures (HTTP 429/503), with backoff and max attempts.
• Idempotency: prevent double execution (e.g., idempotency keys for ticket creation).
• Error handling: return tool errors to the agent in a controlled format; decide when to ask the user for clarification vs retry.

Exam Tip: When you see “must be robust to API failures” or “must not create duplicate records,” think retries + idempotency + deterministic validation. The model’s output is not the authority; your application is.

Common trap: trusting tool output without normalization. If a tool returns free text, you may need a post-processor or a second structured extraction step. Another trap is using tools for actions (write/delete) without a confirmation step; exam scenarios often require “read-only unless user confirms,” especially in regulated environments.

Section 4.3: Memory patterns: short-term context, long-term stores, summarization

Memory is how agentic systems maintain conversation continuity and user preferences without overflowing the model context window. AI-102 typically tests memory as an implementation pattern rather than a specific database product. Think in three layers: (1) short-term conversational context (recent turns), (2) long-term memory (profiles, preferences, past interactions), and (3) task/workflow state (what step we are on, what tools were called, what outputs were produced).

Short-term memory is usually managed via a sliding window of recent messages plus key system instructions. Long-term memory often uses a store that supports retrieval (commonly vector search) to fetch relevant past facts. Summarization is the bridge: compress older conversation turns into a stable summary that preserves commitments (“user is allergic to peanuts”) while dropping noise.

• Conversation state: store intent, entities, last tool results, and pending clarifications.
• Summaries: periodically summarize older turns; store the summary as part of state.
• Retrieval for memory: index user notes and past resolutions; retrieve only what’s relevant.

Exam Tip: If the prompt is “too long” or “the model forgets earlier preferences,” the correct fix is usually memory management (summarize + retrieve) rather than simply increasing tokens (which increases cost and still has limits).

Common traps: (1) treating memory as ground truth—memories can be wrong or outdated; you may need timestamps, confidence, and confirmation prompts. (2) leaking sensitive memory across users/tenants—memory stores must be partitioned and access-controlled. (3) writing everything to memory—store only durable, useful facts and add retention policies to meet governance requirements.

Section 4.4: Orchestration and routing: multi-agent vs single-agent designs

Orchestration is the “traffic control” of an agentic system: deciding which prompt, tool, or specialized agent should handle a request. On AI-102, you must recognize when a single agent with multiple tools is sufficient versus when a multi-agent architecture (specialists) improves quality and safety.

A single-agent design is often best when the domain is narrow, tools are limited, and latency/cost must be minimized. Multi-agent designs become valuable when tasks require distinct competencies or policies—for example: a “Retrieval Agent” for knowledge base queries, a “Transaction Agent” for write operations with stricter confirmation, and a “Compliance Agent” for policy checks. Routing can be implemented via rules (keyword/intent classification), model-based routing (a classifier prompt), or hybrid approaches.

• Routing criteria: intent, risk level (read vs write), required data sources, user role.
• Control loops: coordinator agent assigns tasks; specialists return structured results.
• Failure isolation: if one specialist fails, fall back or request clarification without collapsing the entire run.

Exam Tip: If the scenario says “must ensure high-risk actions are gated,” a common correct design is a router that sends those requests to a restricted agent/toolset with extra validation and explicit user confirmation.

Common trap: “multi-agent equals better.” The exam may penalize unnecessary complexity. Extra agents increase latency, cost, and debugging difficulty. Choose multi-agent when it directly maps to requirements: separation of duties, specialized prompts, policy enforcement, or scalability of workflows.

Section 4.5: Grounding and guardrails: policies, allowed tools, and secure execution

Grounding is how you anchor the model’s responses in authoritative data (documents, databases, APIs). Guardrails are the safety and security controls that limit what the agent can do and what it can say. AI-102 frequently frames this as “reduce hallucinations safely” and “implement secure execution,” especially in enterprise contexts.

Grounding patterns include retrieval-augmented generation (RAG) from enterprise content, tool lookups for real-time data (order status, inventory), and citation requirements (“answer only from retrieved sources”). A strong exam answer typically combines grounding with a refusal policy: if no evidence is retrieved, the agent should ask for clarification or state it cannot answer.

• Allowed tools list: only expose the minimum tools required; separate read-only tools from write tools.
• Policy enforcement: role-based access, content safety checks, PII redaction where required.
• Secure execution: never pass secrets to the model; use managed identity/Key Vault on the server side.
• Prompt injection defenses: treat retrieved text as untrusted; do not allow documents to override system policies.

Exam Tip: If a question mentions “documents may contain malicious instructions,” the correct mitigation is to enforce tool allowlists and system-level policies, and to separate instructions (system) from data (retrieved content). Do not “just trust the document.”

Common traps: (1) assuming grounding alone prevents hallucinations—agents can still misread or overgeneralize; add citation checks and verification steps. (2) allowing the model to choose any URL/API—limit endpoints and validate destinations. (3) mixing tenants or departments in the same index without access filtering; the exam often expects per-user/role filtering in retrieval.

Section 4.6: Evaluation and observability: traces, test sets, and quality metrics

Agentic systems must be evaluated like software: with repeatable test sets, measurable metrics, and traces that show which tools were called and why. AI-102 expects you to recognize that “the model seemed fine in a demo” is not sufficient; you need systematic evaluation to detect regressions, reduce hallucinations, and optimize cost/latency.

Observability starts with tracing: log prompts (with redaction), tool calls, tool outputs, routing decisions, and iteration counts. This enables root-cause analysis of failure modes such as infinite loops, wrong tool selection, or stale memory retrieval. For evaluation, build representative test sets: common user intents, edge cases, and adversarial prompts (prompt injection attempts, ambiguous requests). Then measure quality with metrics like groundedness (are claims supported by sources?), task success rate, tool accuracy (correct arguments), and safety policy compliance.

• Quality metrics: task completion, factual accuracy vs sources, citation correctness, user-rated satisfaction.
• Operational metrics: latency, token usage, tool error rate, retry counts, cost per resolution.
• Hallucination reduction: enforce “answer from sources,” add verification steps, and penalize unsupported claims in eval.

Exam Tip: When the stem asks how to “improve reliability over time,” pick answers involving test sets + automated evaluation + tracing/monitoring, not only prompt tweaks. Prompting helps, but the exam favors measurable controls.

Common trap: evaluating only the final answer. Agent failures often occur mid-run (wrong tool arguments, misrouted intent, ignored guardrails). Traces and step-level scoring are what expose these issues. Another trap is ignoring data drift: tool schemas change, documents update, and policies evolve—evaluation pipelines should be run continuously after changes to prompts, tools, indexes, or models.

Section 5.1: Azure AI Vision: image analysis, detection, and responsible AI notes

AI-102 expects you to differentiate common image workloads and map them to Azure AI Vision capabilities: tagging/captioning (describe content), object detection (locate items), image classification (assign labels), and domain-specific features where appropriate. In practice, “image analysis” questions often test whether you know when a single synchronous API call is enough (e.g., analyze a photo uploaded by a user) versus when you should design a pipeline (e.g., process a blob container, persist results, and index them).

Look for wording like “identify objects and return bounding boxes” (detection) versus “generate a description or tags” (analysis). If the scenario includes video or continuous feeds, the exam may push you toward an architecture that samples frames and calls Vision, or uses a specialized approach; don’t assume a single still-image endpoint solves video analytics end-to-end.

Exam Tip: When a question mentions “minimum development effort,” choose managed Azure AI services over custom model training. When it mentions “custom classes,” “proprietary categories,” or “you must train on your own labeled data,” that’s when you consider custom vision/model options rather than generic tagging.

Responsible AI is a scored theme, even when not explicitly labeled. Be prepared to recommend mitigations: limit data retention, apply access controls, document limitations, and provide human review for sensitive decisions. Vision solutions frequently involve personal data (faces, license plates, workplace imagery). Even if the question is technical, a good answer often includes governance-friendly choices such as using private endpoints, customer-managed keys (where supported), or avoiding unnecessary storage of raw images.

Common traps include: assuming all features are available in all regions, ignoring input limits (image size/format), and forgetting that some tasks require structured output (boxes, polygons) rather than free text. On the exam, the “correct” answer is usually the one that meets the output requirement with the simplest supported service and a secure access pattern.

Section 5.2: OCR and document workflows: read, layout, and post-processing

OCR scenarios in AI-102 are rarely just “extract text.” They typically involve document workflows: scanning PDFs, photos of receipts, or forms; preserving reading order; extracting tables; and then post-processing into structured data. You should recognize the difference between basic OCR (plain text) and document-aware extraction (layout, lines, words, tables, and coordinates). The exam will often describe requirements like “keep the original document structure,” “extract tables,” or “map values to fields,” which signals a layout-aware approach and downstream parsing.

A robust OCR pipeline has clear stages: ingest (Blob Storage), run OCR, normalize the output, validate/clean (remove headers/footers, fix common OCR errors), and persist results (JSON in storage, or fields into a database/search index). If you see “batch of documents in a container,” think in terms of an asynchronous process or an indexing workflow rather than a single per-request call.

Exam Tip: Watch for “PDF with multiple pages” and “high volume.” These cues point to asynchronous operations and storage-based workflows. Also watch for “handwritten” versus “printed” text; the correct service/feature selection can change based on handwriting support and expected accuracy.

Post-processing is where many real solutions succeed or fail—and the exam reflects that by describing messy inputs: skewed scans, rotated pages, mixed languages, or noisy backgrounds. Your answer should lean on practical mitigation: pre-processing images (deskew, rotate), using confidence scores to route low-confidence documents to human review, and using regex/dictionaries for normalization (dates, currency, IDs). A classic trap is to assume OCR output is “final truth”; on the exam, the best design often includes validation steps and error handling, especially when OCR feeds downstream automation.

Section 5.3: NLP services: entity recognition, sentiment, summarization, translation

NLP questions in AI-102 commonly test your ability to pick the right capability for classification and extraction tasks: entity recognition (people, places, organizations, dates), key phrase extraction, sentiment analysis/opinion mining, summarization, and translation. The exam often embeds these requirements inside business outcomes: “route support tickets,” “detect complaints,” “mask PII,” or “summarize call transcripts for agents.” Your job is to map each outcome to a specific NLP function and identify how the results are used (store as metadata, trigger workflows, or power search filters).

Entity recognition is a frequent building block for information extraction and governance. If a scenario requires identifying PII for compliance, you should think about entity categories, confidence, and what to do next (redaction, encryption, access restrictions). Sentiment is often used for dashboards and triage, but be careful: sentiment is not the same as intent, and it does not replace classification. Summarization comes up when documents are long and users need quick previews; translation shows up in multilingual ingestion and cross-lingual search experiences.

Exam Tip: Pay attention to the output shape. If the question wants “a list of people and locations with offsets in the text,” that points to entity extraction output with positions. If it wants “a short paragraph capturing the main points,” that’s summarization. If it wants “convert Spanish to English before indexing,” that’s translation in the ingestion pipeline.

Common traps include confusing “key phrases” with “entities,” using sentiment when the requirement is to classify topics, and forgetting that language detection may be needed before selecting translation or a language-specific model. Also, don’t ignore latency: calling multiple NLP operations per document in real time can be expensive; batch processing via pipelines or enrichment can reduce cost and centralize processing. The strongest exam answers show an end-to-end view: ingest text, run extraction/classification, store results as structured fields, and then use those fields for search, filters, analytics, and downstream automation.

Section 5.4: Conversation and speech overview: bots, speech-to-text, text-to-speech

Conversation scenarios in AI-102 are about building user-facing experiences that combine NLP with orchestration: a bot that answers questions, collects details, escalates to a human, or summarizes interactions. The exam will test whether you understand the building blocks: a bot framework/channel integration, an NLP layer for understanding (or a generative model where allowed), and a backend integration layer (APIs, search, CRM). Speech adds another dimension: speech-to-text for transcription, and text-to-speech for voice responses.

Expect questions that describe call centers, voice assistants, or meeting transcription. The important decision points are: streaming vs batch transcription, handling punctuation and diarization (who spoke), and producing outputs that can be analyzed (sentiment, entities) or summarized. For text-to-speech, pay attention to requirements around voice selection, pronunciation, and whether the system must respond in near real time.

Exam Tip: If the scenario mentions “real-time captions” or “live call,” favor streaming speech-to-text patterns. If it mentions “process recordings overnight,” favor batch transcription and downstream NLP/enrichment. The exam often rewards recognizing the correct processing mode more than naming every feature.

Common traps: assuming a bot automatically “understands” user intent without an explicit NLP/LLM layer; ignoring authentication/authorization to backend tools; and neglecting conversation state. For exam-style architecture answers, include how you store context (session state, conversation history) and how you evaluate quality (sampling conversations, monitoring latency, tracking fallback rate). Even if the question focuses on a speech feature, the best solution usually shows the full loop: transcribe, analyze, respond, and log telemetry for improvement.

Section 5.5: Knowledge mining with Azure AI Search: indexes, fields, analyzers, vectors

Azure AI Search is the centerpiece of knowledge mining on AI-102. The exam expects you to understand index design: fields, data types, searchable/filterable/sortable/facetable flags, and analyzers for language-specific tokenization. A typical scenario: ingest documents, enrich them, and provide a search experience with filters (facets), security trimming, and relevance tuning. The key is to model your index around how users will query, not how the raw data arrives.

Fields are the most-tested detail. For example, if you need filtering by department or date, those fields must be marked filterable (and have appropriate types, like Edm.String or Edm.DateTimeOffset). If you need full-text search over content, mark it searchable, choose the right analyzer, and consider separate fields for raw text vs normalized text. If you need aggregations like “count by category,” mark the field facetable. Misconfigured field attributes are a common exam failure mode.

Vectors are increasingly prominent: vector fields enable similarity search for embeddings-based retrieval. On the exam, watch for “semantic similarity,” “find related documents,” or “RAG” cues. Your answer should include an index with a vector field, an embedding generation step (often at ingestion time), and a query strategy that combines vector search with keyword filters where needed.

Exam Tip: When you see “users must only see documents they have access to,” think about storing ACL/group fields in the index and applying security filters at query time. Don’t propose “separate indexes per user” unless the prompt forces it; that’s usually a scalability trap.

Common traps: using the wrong analyzer for the language, forgetting that a field can be searchable but not filterable, and assuming semantic ranking replaces good field design. Identify correct answers by matching the user experience requirements (filters, sorting, faceting, highlighting, fuzzy matching) to explicit index configuration.

Section 5.6: Information extraction and enrichment: skillsets, indexers, and debugging

Knowledge mining becomes “AI” when you add enrichment: skillsets that extract text, detect language, identify entities/PII, generate key phrases, or create custom projections. AI-102 tests whether you can assemble the ingestion pipeline: a data source (often Blob Storage), an indexer (to crawl and map), and a skillset (to enrich). The enriched outputs must be mapped into index fields via output field mappings. Many exam questions describe a pipeline that “runs successfully but the index is missing fields,” which is almost always an output mapping or field attribute issue.

Skillsets can chain steps: OCR to get text, then entity recognition on the text, then normalization, then push results to the index. The exam expects you to know that enrichment is typically performed during indexing (batch), not at query time. If the scenario requires the freshest results per query, that’s a clue to use real-time API calls instead of indexers/skillsets.

Exam Tip: Debugging enrichment on the exam is pattern recognition: (1) confirm the indexer ran and processed documents, (2) inspect enrichment outputs (enrichment tree/skill outputs), (3) verify output field mappings, and (4) verify the target index field is defined with the right type/collection and is retrievable/searchable as required.

Common traps include forgetting that many skills output collections (arrays) and your index field must match (e.g., Collection(Edm.String)), missing the correct field path in the mapping, and neglecting document cracking (PDF/image extraction) settings. For multi-service integration case scenarios, the best solution usually connects all lessons in this chapter: OCR/layout to extract text from documents, NLP to enrich and structure it, and Azure AI Search to index both keywords and vectors for retrieval. When you choose components, justify them by throughput, latency, and maintainability—those are the deciding factors in many AI-102 case studies.

Run your mock exam like the real thing: closed notes, single sitting, and a strict timebox. In the actual AI-102, you should expect a mix of multiple choice, scenario sets, and case-study style prompts. Practice under realistic conditions so your pacing becomes automatic rather than emotional.

Use a two-pass pacing plan. Pass 1: answer everything you can in under ~60–75 seconds per item. Mark the rest and move on. Pass 2: revisit marked items with deeper analysis, spending up to ~2–3 minutes each. If you still can’t decide, eliminate options based on service capability boundaries and security requirements, then commit. The biggest pacing trap is spending five minutes on a single ambiguous item early and then rushing later.

Scoring rubric: target 85%+ on the mock to create margin for exam-day variance. Categorize misses into (A) concept gap (didn’t know), (B) misread constraint (missed a detail), (C) Azure service confusion (picked wrong service), and (D) overthinking (changed from right to wrong). You’re not just collecting a score—you’re collecting diagnostic data.

Exam Tip: When a question mentions “minimize secrets,” “no hard-coded keys,” or “enterprise governance,” your default should shift toward Microsoft Entra ID + managed identity + Key Vault references, and away from API keys stored in config.

• Environment: quiet room, single screen if possible, no interruptions.
• Tools: simple timer, a scratchpad, and a marking strategy (e.g., “return later”).
• Mindset: choose the best answer for Azure, not the most generic AI answer.

After the mock, do not immediately reattempt. Your first action is to log errors while your reasoning is fresh—this is where your improvement actually happens.

Part 1 is designed to feel like a case study plus rapid multiple choice across all measured outcomes. You should practice extracting requirements and mapping them to the right Azure services and architecture patterns. The exam often hides key constraints in a single clause: “data must remain in region,” “private endpoint required,” “needs streaming,” or “must support multi-lingual.” Train yourself to underline constraints before evaluating answers.

Expect cross-domain combinations, such as: Azure AI Search indexing enterprise documents while Azure OpenAI performs RAG; Azure AI Vision OCR feeding an enrichment pipeline; or Azure AI Language extracting entities for downstream routing. The test is rarely about isolated service trivia. Instead, it checks if you can assemble a solution with correct authentication, content flow, and monitoring.

Common traps in this part include confusing Azure AI Search with vector databases in general, or assuming “OpenAI does the retrieval.” In Azure, retrieval is typically implemented with Azure AI Search (keyword + semantic + vector) and then grounded generation via Azure OpenAI. Another frequent trap is mixing up model deployment scope: you deploy models inside an Azure OpenAI resource, and you must select a deployment name used by your app—answers that treat “model name” as the runtime endpoint often miss this.

Exam Tip: For RAG scenarios, the best answer usually includes: chunking + embeddings generation, indexing vectors in Azure AI Search, a query-time vector+semantic retrieval step, and prompt assembly with citations/grounding. If an option skips retrieval but promises “accurate answers,” it’s likely wrong.

Also watch for governance: content filtering, logging strategy, and data handling. If the scenario mentions regulated data, look for Private Link, customer-managed keys (where applicable), and a plan for audit/telemetry that avoids logging sensitive prompts in plaintext. When asked how to monitor, prefer Application Insights and Azure Monitor with meaningful metrics (latency, throttling, token usage, search query latency, and failures), not “print statements.”

Part 2 simulates scenario sets and “hot-spot style” decisions where you choose components or configuration placements. This is where service boundaries and deployment details matter. You’ll see prompts that require selecting which service performs OCR, which stores extracted text, which indexes it, and where tool/function calling fits in an agentic workflow.

For agentic solutions, the exam checks whether you can separate orchestration from tools. The model (Azure OpenAI) decides which tool to call; your application enforces tool execution, validates inputs, and handles retries/timeouts. A common trap is assuming the model can directly access databases or internal APIs. In Azure, you implement function calling in your app layer (or orchestration framework), authenticate to tools via managed identity, and store memory/state in an appropriate store (e.g., Cosmos DB, SQL, or cache) depending on latency and retention needs.

Hot-spot items frequently probe security placement: where to use Key Vault, where to use private endpoints, or where to enable diagnostic settings. If a scenario mentions “no public internet,” be suspicious of any answer that uses public endpoints without Private Link. If it mentions “rotate secrets,” prefer managed identity over stored keys and use Key Vault for any unavoidable secrets.

Exam Tip: In configuration-selection questions, choose the minimal set that satisfies constraints. Extra services or overly complex pipelines are often distractors. The correct answer is typically the simplest architecture that meets security, scale, and quality requirements.

Computer vision traps: OCR vs. image analysis vs. document intelligence. If the requirement is extracting text from images and PDFs with layout/fields, don’t force-fit generic image labeling; likewise, if it’s just reading printed text in images, avoid heavyweight solutions. NLP traps: sentiment, key phrases, entity recognition, summarization, translation, and conversation features have different endpoints and limitations—read the ask carefully and match the capability, not the buzzword.

Your review process determines your score improvement more than the mock itself. Use an error log with four columns: (1) question theme (e.g., “RAG grounding,” “managed identity,” “OCR pipeline”), (2) why you chose your answer, (3) why it’s wrong in Azure terms, and (4) the rule you’ll apply next time. The point is to convert misses into reusable decision rules.

Then build a concept map that links exam objectives to services and patterns. Example: “Implement knowledge mining” links to Azure AI Search indexers, skillsets/enrichment, OCR integration, vector indexing, semantic ranker, and filters/security trimming. “Implement generative AI solutions” links to Azure OpenAI deployments, prompt patterns, embeddings, safety/content filters, and evaluation. Add operational links: monitoring, cost controls, and deployment strategies (blue/green, staging, rollback).

Exam Tip: Many candidates lose points by treating identity, networking, and monitoring as “non-AI.” AI-102 includes these because production AI solutions fail without them. If your miss involved security/ops, treat it as a core objective gap, not a side note.

Retake strategy: do not immediately redo the same mock. First, re-study the specific objective behind each miss (documentation + a quick lab or config walkthrough). After 24–48 hours, retake only the missed themes with fresh variants (or reorder questions if that’s your format). You want retrieval strength, not recognition. If you changed correct answers to incorrect ones, track that separately—your fix is often “commit after eliminating,” not “study more.”

This final review is your alignment check against the course outcomes and exam objectives. Use it as a pre-exam checklist and mark any item you cannot explain in two minutes—those become your final-study targets.

• Plan and manage an Azure AI solution: resource design, regions, quotas, RBAC, managed identity, Key Vault usage, Private Link, diagnostic settings, Application Insights, cost management (token usage, search replicas/partitions, vision transaction costs), and deployment strategies.
• Generative AI with Azure OpenAI: deployments vs. models, prompt orchestration patterns (system/context/user roles), grounding with retrieved data, safety/content filtering, and evaluation concepts (quality, groundedness, harmful content risk).
• Agentic solutions: function/tool calling boundaries, tool authentication, state/memory storage choices, retries/timeouts, and evaluation of agent behavior (hallucination control, tool-use correctness).
• Computer vision: OCR vs. image analysis vs. video analysis requirements; input formats; where to place preprocessing; and how to integrate outputs into search/enrichment.
• NLP: entity/key phrase/sentiment, summarization, translation, and conversation scenarios; selecting the correct capability based on the output required.
• Knowledge mining with Azure AI Search: index schema design, vector fields + embeddings, hybrid retrieval, semantic ranking, filters, indexers/skillsets, and security trimming patterns.

Exam Tip: If you’re stuck between two answers, pick the one that clearly addresses: (1) identity and access, (2) data flow end-to-end, and (3) operational monitoring. Those are high-frequency exam discriminators.

Finish by rehearsing “service selection sentences” out loud: “Because the requirement is X, I choose service Y, configured with Z.” If you can’t say it cleanly, you don’t own it yet.

Exam day is about execution. Bring compliant identification (matching your registration), confirm your testing environment (or test center rules), and remove anything that could trigger a proctor issue. If remote, pre-check your room, webcam, microphone, and network stability. Treat check-in as part of the exam clock mentally—stress spikes here can damage your first 10 questions.

Time strategy: use the same two-pass method from Section 6.1. Read the last line first when it states the task (“What should you do first?” “Which service should you use?”). Then scan for constraints: private networking, region, cost, latency, data residency, and governance. Avoid “solutioneering” beyond the question; Microsoft tests best-fit decisions under stated constraints.

Exam Tip: When you see words like “best,” “most secure,” or “minimize operational overhead,” those are tie-breakers. Choose managed services, least-privilege identity, and built-in monitoring over custom code—unless the scenario explicitly requires custom behavior.

Common operational traps: changing too many answers late, running out of time due to early perfectionism, and misreading “must” vs. “should.” If you have 10 minutes remaining, stop deep analysis—finish all unanswered items and only revisit those where you can articulate a concrete rule that flips the choice.

Next steps: after you pass, convert your mock error log into on-the-job guardrails (architecture checklists, IaC templates, and monitoring dashboards). If you don’t pass, your remediation plan is already defined by your weak-spot categories—re-lab the top two objective areas and retake with a schedule, not with hope.