AI-102: Become An Azure AI Engineer In One Weekend [2025]

From classical AI to generative AI: How Azure evolved from “Cognitive Services” to Azure AI services that add intelligence without deep data-science skills.

Generative AI on Azure: Where Azure OpenAI Service fits (enterprise security + OpenAI models like GPT-4, Whisper, DALL·E).

Modern tooling: The Azure AI Foundry/portal experience for organizing hubs and projects to build, deploy, and manage AI solutions.

Certification context: The AI-102 role and solution lifecycle you’re preparing for.

Language (NLP): Classification, summarization, translation, and conversational systems.

Vision: Image/video analysis, OCR, and multimodal understanding.

Speech: Speech-to-text, text-to-speech, pronunciation assessment.

Search/Retrieval: Indexing and semantic search for knowledge mining.

Document Intelligence: Key-value, table, and form extraction.

Generative AI: Prompting and grounding large models with enterprise controls.
These sub-domains map directly to Azure AI services such as Language, Vision, Speech, Document Intelligence, Azure AI Search, and Azure OpenAI, which you’ll use throughout the course.

The six Microsoft Responsible AI principles and why they matter: fairness; reliability & safety; privacy & security; inclusiveness; transparency; accountability.

How principles become practice: Oversight, documentation (e.g., Transparency Notes), and engineering tooling in Azure to operationalize responsibility.

Exam-relevant scenarios: Risk identification, mitigations (human-in-the-loop, evaluation), and compliance alignment when designing Azure AI solutions.

Service families & use cases (with examples):

Language (NLP, translation), Speech (STT/TTS), Vision, Document Intelligence, Content Safety, Azure AI Search, Azure OpenAI.

Prebuilt vs. customizable models: When to use out-of-the-box APIs vs. fine-tuning or prompt-engineering with Azure OpenAI.

Solution patterns: Retrieval-augmented generation (RAG) with Azure AI Search + Azure OpenAI for grounded answers. (Inference based on official product docs.)

Create a multi-service resource: In the Azure portal/AI Foundry, provision an Azure AI services (AIServices) resource to access multiple APIs with a single key/endpoint.

AI Foundry workflow: Create a hub (or start with a project), add connections, and manage deployments centrally—ideal for team collaboration.

Azure OpenAI quick start: Deploy a model (e.g., GPT-4) and make your first API call from the portal or CLI.

Next steps: Keys/secrets management, price planning, and region/availability considerations before production.

State of the service: Content Moderator is deprecated and scheduled for retirement on Mar 15, 2027; use Azure AI Content Safety going forward.

Modern replacement: Content Safety’s text moderation flags harmful content and supports Studio, REST, and SDK workflows for rapid adoption.

Harm categories & signals: Understand categories such as Hate & Fairness, Sexual, Violence, Self-harm and how severity levels inform actions.

Customization: Apply custom categories and blocklists to align moderation with your domain and compliance needs.

Takeaway: Map legacy Moderator concepts to Content Safety and prepare migration steps for AI-102 projects.

Capabilities overview: Use Azure AI Language for Sentiment & Opinion Mining, NER, PII detection, Key Phrases, Summarization and more.

NER deep-dive: Identify and categorize entities in unstructured text; learn typical workflows and when to customize.

Developer view: Pick REST/SDKs, understand request/response shapes, and production considerations (throughput, latency, regions).

Hands-on focus: Evaluate sample text, interpret confidence scores, and plan error handling for noisy input.

Pattern: Build a serverless pipeline—HTTP/ingest → Queue → Function (Queue Trigger) → Text Analytics → Storage—to triage feedback at scale.

Triggers & bindings: Use the Azure Queue Storage trigger (and output bindings) to process messages automatically as they arrive.

Reliability: Understand built-in retry behavior and poison queues for failed messages (default up to five attempt.

Choosing a queue: When to use Storage Queues (simple, cost-effective) vs Service Bus queues (advanced features, transactions, ordering).

Exam-ready tips: Instrument logging/metrics, validate payloads, and design idempotent handlers for safe reprocessing.

Core model terms: Intent (user goal), Entities (data to extract), Utterances (examples), and schema design basics.

Lifecycle: Train, test, publish; collect real utterances to improve coverage and disambiguation.

Roadmap reality: LUIS is retiring; the portal won’t be available after Oct 31, 2025—plan to migrate.

Next-gen path: Conversational Language Understanding (CLU) in Azure AI Language is the recommended successor.

Migration notes: Import LUIS apps into CLU; review accuracy differences and entity configurations post-migration.

Today’s best practice: Integrate CLU with the Bot Framework SDK as the modern, supported approach for NLU in bots.

Legacy reference: Understand historical LuisRecognizer patterns in Bot Framework, for maintaining existing solutions.

Design pattern: Add a recognizer layer, route intents to dialogs/handlers, handle None/low-confidence paths, and log telemetry.

Implementation steps: Create a Language resource, connect keys/endpoints, and wire predictions to dialog logic in code. Microsoft Learn

Future-proofing: Prioritize CLU for new builds and plan LUIS-to-CLU migration for existing bots ahead of the LUIS retirement window.

Capabilities & modes: Real-time streaming, batch transcription, punctuation, profanity masking, and diarization (who-spoke-when).

Accuracy levers: Audio capture basics (mic choice, sampling rate), noise reduction, language/locale selection, and phrase hints.

Customization: When to use Custom Speech for domain jargon, accents, and environment-specific audio.

Security & deployment: Keys and endpoints, regional selection, and secure secret management.

Hands-on: Make a first STT call with the Speech SDK/CLI; inspect partial vs. final results and confidence scores.

Quality checklist: Handle timeouts, retries, and empty/short utterances; log transcripts and errors for post-run review.

Pipeline design: Mic/stream → source STT → translation to one or many targets → optional TTS playback.

Real-time UX: Work with interim results, latency trade-offs, and end-of-speech detection.

Language handling: Set source/auto-detect, manage target locales, and format output for UI and captions.

Reliability: Implement retries, throttling awareness, and graceful fallbacks (e.g., text translation).

Dev paths: Use the Speech SDK or CLI for rapid prototyping; test with scripted audio for repeatable outcomes.

Delivery patterns: Multilingual subtitles, cross-language voice chat, and agent-assist translation.

Neural TTS basics: Choose voices/locales; tune rate, pitch, and prosody with SSML for natural delivery.

Styles & roles: Apply voice styles (e.g., customer service, news) to match scenario tone.

Long-form: Batch synthesis for audiobooks/training content; stream playback for responsive apps.

Custom Neural Voice (CNV): When branding a unique voice makes sense—and required consent/governance considerations.

Engineering tips: Cache audio, segment long text, sanitize inputs, and monitor costs.

Hands-on: Synthesize a prompt, compare two voices/styles, and export audio suitable for web or IVR.

End-to-end intent flow: Use the Speech SDK’s intent recognition to send audio directly to a LUIS app and receive intent + entities.

Model design: Define intents, utterances, and entities (simple vs. composite) and test with spoken variants.

Confidence strategies: Route None/low-confidence to clarification prompts; log and retrain from real utterances.

Latency & UX: Warm up recognizers, debounce wake words, and display both transcript and parsed entities for transparency.

Roadmap: LUIS is retiring on October 1, 2025—plan to migrate to CLU while preserving the same speech-to-intent pattern.

Architectures: Browser/mobile/IVR → Speech SDK (streaming) → STT → storage/search; or Call Automation + real-time transcription for PSTN/VoIP.

Meetings & diarization: Use conversation/meeting transcription to attribute text to speakers and manage voice signatures when needed.

Scalability: Horizontal scale with Functions/Kubernetes; partition by session; handle back-pressure with queues.

Data handling: Segment and timestamp transcripts; redact PII; archive to Blob/Data Lake; index with search for retrieval.

Observability: Track word-error-rate proxies, partial/final result counts, latency, and failure modes.

Hands-on: Deploy a minimal web app for live captions; add diarization; export text and captions (WebVTT/SRT).

Capabilities at a glance: Image description, tags, objects, adult/racy checks, brand/logo, people detection, and unified OCR in Image Analysis 4.x.

When to use what: Image Analysis vs. specialized services (Face, Custom Vision, Video Indexer).

Inputs & limits: Supported formats, size/resolution considerations, synchronous vs. batch flows.

Quality levers: Crop/resize, EXIF orientation, background clutter, prompt design for tags/captions.

Security & regions: Keys/endpoints, data residency, and built-in content filtering options.

Hands-on: Call the Image Analysis API to extract captions, tags, and text from sample images; interpret confidence scores and bounding boxes.

Face API today: Detect faces, get landmarks/pose, and perform identify/verify/find-similar; explore liveness detection scenarios.

Responsible use: Understand Limited Access requirements and compliance constraints before enabling face recognition.

What’s not supported: Emotion, age, gender, smile, hair/makeup attributes are deprecated; plan alternatives for “emotion” needs.

Design patterns: Person directory, watchlist, login/verify flows; TTL for face IDs; no image storage by default.

Reliability: Deal with occlusions, low light, angles; implement retries and thresholding; handle “No match” paths.

Alternatives for emotion: Use text-based emotion from transcripts or sentiment analysis in downstream services when appropriate.

Service choice: Use Azure AI Custom Vision for domain-specific classifiers (and object detection).

Dataset design: Balanced classes, diverse angles/backgrounds, ≥30–50 images per tag to start; train/validation split and iteration strategy.

Training & evaluation: Quick Training vs. Advanced; read precision/recall/F1, confusion matrix; address bias and drift.

Optimization: Hard-negative mining, image augmentation, active learning from misclassified images.

Operationalizing: Version models, export to containers or edge (where supported), manage keys/quotas.

Hands-on: Create a project, upload/tag images, train, and compare iterations to select a champion model.

End-to-end: Ingest video → automatic analysis → searchable insights JSON.

Visual insights: Faces (detection & grouping), labels/objects, observed people, OCR, scenes/shots/keyframes.

Audio/NLP insights: Transcription, translation, keywords, named entities, text-based emotions, topics.

Use cases: Deep search across libraries, highlight reels, compliance review, content moderation support, and metadata enrichment.

Dev workflow: Portal vs. API; indexing presets; throttling and cost controls for long videos.

Accessibility: Generate captions/subtitles (SRT/WebVTT) and thumbnails to improve discoverability and inclusion.

From model to app: Deploy your Custom Vision model and call the Prediction endpoint from web/mobile/edge.

Request/response design: Image bytes vs. URL, top-N results, thresholds, bounding boxes for detectors.

Security & scale: Store keys securely, rotate regularly, use regional endpoints; batch/async patterns for high volume.

Ops & reliability: Timeouts/retries, idempotency, circuit breakers, and A/B or shadow testing across model iterations.

Cost awareness: Control image size, caching, and concurrency; log payload sizes and response times.

Hands-on: Wire a minimal API client, run smoke tests, and add telemetry (precision/recall proxies) to monitor in production.

Core building blocks: intents, utterances, and entity types (machine-learned, list, regex, composite, hierarchical, pattern.any).

Phrase lists & patterns: when and why they were used in LUIS; strengths and pitfalls.

Migration reality: LUIS retirement timeline; how CLU maps intents/entities and where patterns are replaced by stronger ML generalization and regex components.

Schema design for CLU: turning legacy entities into CLU components; handling nested data; capturing values and roles cleanly.

Authoring tips: naming conventions, disambiguation utterances, test sets, and evaluation metrics to iterate safely.

Hands-on: import/export flow, quick migration of a LUIS app to CLU, and sanity checks on predictions.

Orchestration workflow: route to CLU, Question Answering, or legacy LUIS from a single endpoint.

Dialog strategies: slot filling, clarification prompts, “None/low-confidence” handling, interruptions, and escalation to human agents.

Experience design: set expectations, summarize context, and make recovery paths obvious and inclusive.

Telemetry-driven iteration: log intents/entities/ambiguity, trace conversation paths, and A/B responses.

Bot integration: recognizer layer, intent routing, fallback knowledge, and guardrails for scope.

Hands-on: create an orchestration project that dispatches between intents and a knowledge base.

Summarization options: extractive vs. abstractive; conversation vs. document summaries.

Entity Linking: disambiguate entities and attach knowledge-base IDs for downstream search and analytics.

Input formats: native documents (PDF, DOCX, TXT) vs. plain text; when to chunk content.

Quality levers: sectioning, prompt-like instructions (titles/heads), and multilingual considerations.

Operational tips: manage long documents, preserve structure with sentence boundaries, and cache stable outputs.

Hands-on: build a pipeline that links entities, then summarizes text and produces a clean study note.

Scale pattern: submit long-running Analyze Text jobs with multiple actions (sentiment, key phrases, NER).

Throughput & limits: understand text-record sizing, batching, and pagination; design for retries and backoff.

Costs & quotas: estimate by text-records; choose tiers and regions wisely; monitor usage.

Data engineering: normalize language/encoding, segment large payloads, deduplicate, and store lineage.

Observability: track latency, failure codes, and quality proxies (agreement between models, drift alerts).

Hands-on: spin up a queue-driven batch that processes thousands of records and writes results to a lake.

Network isolation: private endpoints, firewalls, and VNet integration to block public access.

Encryption & keys: Microsoft-managed vs. customer-managed keys (CMK) with Key Vault; key rotation.

Identity & access: managed identities and RBAC for apps, storage, and data pipelines.

Resource choices: single-service Language vs. multi-service Azure AI resource; region and tier selection.

Deployments: blue/green model versions, canary traffic, and (where supported) CLU containers for on-prem/edge.

Compliance: logging, data retention, and least-privilege patterns across environments.

Hands-on: lock down a Language resource with Private Link, CMK, and managed identities; deploy a new model version.

Global frameworks: How GDPR, ISO 27001, SOC, NIST 800-53 and industry regs map to Azure.

Built-in governance: Use Azure Policy regulatory initiatives and Defender for Cloud’s compliance dashboard to measure and report posture.

Benchmarks: Apply the Microsoft Cloud Security Benchmark and service baselines to standardize controls (identity, data, network, logging).

Shared responsibility: Distinguish Microsoft- vs. customer-owned controls; document compensating controls.

Practical workflow: Select a standard → assign initiatives at subscription/management-group → remediate with policy assignments and alerts.

Outcome: A repeatable, auditable control set aligned to your target certifications.

Minimize first: Collect only needed fields; redact PII; prefer short-lived tokens and ephemeral storage.

Service behaviors:

Azure OpenAI: retains prompts/outputs for limited periods for abuse monitoring; data isn’t used to train base models.

Language service: optional temporary storage with opt-out controls (e.g., logging flags).

Document Intelligence: input/results purged rapidly; trained custom models stored in your storage account.

Face: biometric data has extra legal obligations—validate lawful basis, consent, and retention policies.

Controls: Choose regions for residency; enable CMK; set Storage lifecycle rules; turn off diagnostic payload collection where unnecessary.

Outcome: A documented data-flow with retention SLAs and deletion procedures per service.

Signals to collect: Metrics (throughput, latency, rate-limits, tokens), resource logs, activity logs.

Plumbing: Configure Diagnostic settings to send data to Log Analytics, Storage, or Event Hubs.

Service specifics: Azure OpenAI provides model/operation metrics and log tables for usage and throttling analysis.

Dashboards & alerts: Build Kusto queries, alert on saturation (e.g., 429s, queue depth), and track SLOs.

At scale: Use Azure Policy to enforce diagnostics by default across subscriptions.

Outcome: Actionable observability for capacity planning, incident response, and cost governance.

SDK setup: Install Azure.AI.ContentSafety; authenticate via Microsoft Entra ID or API key.

Core calls: Analyze text or images; read severity by harm category (Hate & Fairness, Sexual, Violence, Self-harm).

Customization: Create blocklists and thresholds; combine with app-level policy (warn, blur, block, escalate).

Reliability: Add retries/backoff; handle timeouts and large payloads; log decisions for review.

Dev workflow: Start in Content Safety Studio, export code, then integrate into APIs/bots/apps.

Outcome: A production-ready moderation layer with clear behaviors and test coverage.

Network isolation: Disable public access; use Private Endpoints/Private Link; restrict by VNet/subnets and IP rules.

Identity over keys: Prefer Microsoft Entra auth and managed identities; apply RBAC least-privilege to resources.

Encryption: Enable Customer-Managed Keys (CMK) with Key Vault; enforce via Azure Policy where available.

Per-service hardening: Configure service-specific firewalls (e.g., AI Search), custom subdomains, and TLS.

Operations: Rotate secrets, alert on unauthorized access, and validate egress paths.

Outcome: Locked-down endpoints that meet enterprise security and compliance requirements.

How bots work: Activities, adapters, middleware, dialogs, and the Azure Bot Service connector that delivers messages between users and your bot.

SDK overview: Bot Framework SDK (C#, JavaScript/TypeScript, Python) structure, state storage, and common packages.

Tools: Bot Framework Emulator for local testing; Composer for visual authoring.

Hosting model: Typical deployment on Azure App Service (or Functions), messaging endpoint /api/messages, and channel configuration in the Azure portal.

Design patterns: Turn context, dependency injection, configuration via app settings, and environment-based configuration.

Hands-on: Run a sample bot locally, inspect JSON activities, and trace middleware/handler flow.

Starter options: Visual Studio/VS Code Echo Bot and Core Bot templates; Composer quickstarts (dialogs, interruptions, cards).

Project structure: Dialogs, bots, adapters, and configuration files; where to add services and telemetry.

Local run & debug: Emulator setup, ngrok/tunneling basics, and using inspection tools.

First publish: Create an Azure Bot resource and deploy your bot to App Service.

Good practices: Use app secrets (not hard-coded), environment variables, and sample settings for team onboarding.

Hands-on: Create a bot from a template, customize a greeting, deploy once to Azure, and validate with Test in Web Chat.

Language understanding: Connect CLU (orchestration/intent) for intent + entity extraction.

Generative AI: Call Azure OpenAI for responses, summaries, and tool/knowledge orchestration (RAG).

Safety: Add Content Safety to classify or block harmful inputs/outputs.

Speech: Enable STT/TTS in Web Chat or clients via Direct Line Speech patterns.

Reliability: Timeouts, retries, request shaping (max tokens, temperature), backoff on 429s, and circuit breakers.

State & grounding: Persist conversation context, add citations/links, and store transcripts securely.

Hands-on: Add an AI service call to a turn handler and log model usage and latency.

Channels 101: Enable Teams, Web Chat/Direct Line, and other channels (email, SMS, Telegram, LINE) from the Azure portal or CLI.

Direct Line best practices: Exchange secret → short-lived token on a server; never expose secrets in the browser; consider Enhanced Authentication and trusted origins.

Teams specifics: App manifest, SSO/OAuth connections, and Teams-only behaviors vs. generic bot features.

Custom clients: Use Web Chat or native apps via Direct Line to embed bots in websites/mobile with full UX control.

Release flow: Dev → Test → Prod channels and tenant scoping; channel-specific settings and rate limits.

Hands-on: Connect Direct Line for a web client and enable Teams; verify conversations in both.

Telemetry signals: Availability, latency, turn counts, errors/429s, user/session IDs, and model usage metrics.

Plumbing: Configure Application Insights via SDK middleware and diagnostic settings; build KQL dashboards and alerts.

Logs you’ll want: Transcript events, exceptions, channel IDs, conversation references, and AI call costs.

DevOps: Set up continuous deployment (GitHub Actions or Azure DevOps) to App Service; parameterize environment settings and secrets.

Quality gates: Smoke tests after deployment, canary slots, automatic rollbacks on failing health probes.

Hands-on: Add telemetry to a bot, publish from a repo, and create alerts for failure spikes or throttling.

Identity first: Use OAuthPrompt/SSO; rely on provider tokens (Microsoft Entra ID, etc.)—don’t store tokens in bot state.

Keys & secrets: Keep secrets in Key Vault; rotate Direct Line secrets; issue per-user tokens from your server.

Network & access: Understand what can/can’t be privatized; when Direct Line App Service extension + private endpoints fits; restrict Web origins.

Baseline controls: Follow the Azure Bot Service security baseline; apply RBAC, TLS, and minimal outbound permissions.

Governance: Tenant restrictions, content policies, data retention, auditing, and incident playbooks; document channel-specific requirements.

Hands-on: Lock down Direct Line, enable enhanced auth, wire OAuth, and run a security checklist before go-live.