AI-103 — Microsoft Azure AI Apps and Agents Developer Associate Scenario Practice Guide

How to use this guide

The Microsoft Azure AI Apps and Agents Developer Associate (AI-103) exam expects more than memorizing service names. Scenario questions usually ask you to choose the best Azure AI service, architecture, configuration, security control, troubleshooting step, or development approach based on a short business and technical situation.

This guide gives you a practical reading method for AI-103-style scenarios. Use it during final review to slow down, locate the actual decision point, and select the answer that is best supported by the facts provided.

This is an independent exam-preparation guide and is not affiliated with Microsoft.

What AI-103 scenarios are really testing

AI-103 scenarios often combine application development, Azure AI services, agentic workflows, retrieval-augmented generation, responsible AI controls, and production operations. The hard part is rarely a single vocabulary term. The challenge is matching the requirement to the most appropriate Azure capability while respecting constraints such as identity, networking, latency, governance, and maintainability.

A scenario may ask you to decide among:

• A generative AI application pattern, such as chat, summarization, extraction, code generation, or conversational agents.
• A grounding approach, such as using Azure AI Search for retrieval-augmented generation.
• A model interaction pattern, such as prompt engineering, tool calling, structured output, evaluation, or fine-tuning.
• A service choice, such as Azure AI Foundry, Azure OpenAI capabilities, Azure AI Search, Azure AI Document Intelligence, Azure AI Language, Azure AI Vision, Speech, Translator, or Content Safety.
• A security approach, such as managed identities, RBAC, Key Vault, private endpoints, content filtering, or least-privilege access.
• A troubleshooting step, such as resolving authentication failures, poor retrieval quality, hallucinated responses, throttling, missing index fields, or unsafe generated content.

Your job is to identify which of those decisions the question is actually asking.

The five-pass reading method for AI-103 scenarios

Do not read the options first and start matching keywords. Read the scenario in passes.

Pass 1: Identify the workload

Ask: “What is the application trying to do?”

Common AI-103 workloads include:

• Build a chat experience over public model knowledge.
• Build a chat experience grounded in private enterprise data.
• Create an agent that can call tools or interact with business systems.
• Extract structured information from documents, forms, images, audio, or text.
• Classify, summarize, translate, transcribe, or analyze language.
• Index content for semantic, vector, hybrid, or keyword retrieval.
• Evaluate, monitor, or improve model responses.
• Add safety, compliance, identity, networking, or operational controls.

This first pass prevents you from choosing a service that is technically related but not aligned with the workload.

For example:

• If the goal is to answer questions from internal PDFs with citations, the workload is likely grounded question answering or RAG, not simply “use a larger model.”
• If the goal is to extract invoice fields from scanned forms, the workload points toward document extraction, not a general chat completion pattern.
• If the goal is to let a chatbot check order status by calling an API, the workload includes tool calling or agent behavior, not only prompt wording.

Pass 2: Find the decision verb

Look for what the question is asking you to choose.

Typical decision verbs:

• “Which service should you use?”
• “Which component should you configure?”
• “Which authentication method should the application use?”
• “What should you do first?”
• “Which data store or index capability is required?”
• “Which step will reduce hallucinations?”
• “Which approach minimizes development effort?”
• “Which option provides the least privilege?”
• “Which troubleshooting action should you perform?”

The decision verb tells you the answer category. If the question asks for an authentication method, do not answer with a model tuning technique. If it asks for the first troubleshooting step, prefer diagnosis or the least disruptive configuration check before rebuilding the whole solution.

Pass 3: Separate hard constraints from preferences

Scenarios often include both strict requirements and helpful background. Mark the strict constraints.

Hard constraints usually include language such as:

• “Must”
• “Cannot”
• “Only”
• “No internet access”
• “No shared secrets”
• “Private network only”
• “Least privilege”
• “Minimize development effort”
• “Use existing index”
• “Responses must include citations”
• “Output must conform to a schema”
• “Data must remain in the organization’s Azure environment”
• “Users must authenticate with Microsoft Entra ID”

Preferences are useful but not absolute:

• “The team prefers”
• “Currently”
• “Where possible”
• “The application already uses”
• “The developers are familiar with”

When two answers both solve the business goal, the hard constraint usually decides the best answer.

Pass 4: Determine the current system state

AI-103 questions often describe an existing solution. Before choosing an answer, identify the current state.

Ask:

• Is this a new design or a troubleshooting scenario?
• Is the model already deployed?
• Is the data already indexed?
• Does the app already authenticate successfully?
• Are responses wrong, unsafe, slow, missing, or unavailable?
• Is the problem in retrieval, model generation, identity, networking, or application logic?
• Is the goal to improve quality, reduce risk, reduce cost, or fix an outage?

A poor answer may be a valid Azure AI feature but wrong for the current state. For example, fine-tuning may be useful in some cases, but if the scenario says the model cannot answer recent company policy questions, the immediate issue is likely grounding and retrieval, not model training.

Pass 5: Choose the least disruptive answer that satisfies all facts

The best AI-103 answer is usually the one that:

1. Directly addresses the stated goal or symptom.
2. Satisfies every hard constraint.
3. Uses the most appropriate Azure service or feature for the workload.
4. Avoids unnecessary re-architecture.
5. Applies least privilege, safe defaults, and operationally supportable design.
6. Can be defended using only the scenario facts.

If an answer requires assuming facts not given, be cautious. Exam scenarios reward defensible reasoning, not speculation.

Build a quick scenario scratchpad

For longer questions, mentally or physically create this compact scratchpad:

• Workload: What is the app doing?
• Data source: Where does the information come from?
• Decision point: Service, configuration, security, architecture, or troubleshooting?
• Constraint: What must or must not happen?
• State: New build, existing system, or failure?
• Best fit: Which option satisfies the requirement with the least unnecessary complexity?

Example scratchpad:

• Workload: Chat over internal HR documents.
• Data source: PDFs in storage.
• Decision point: Improve answer accuracy and citations.
• Constraint: Answers must be grounded in company docs.
• State: Chat app already exists, but gives generic answers.
• Best fit: Add retrieval over indexed company content, commonly using Azure AI Search with appropriate grounding and citation handling.

Match the scenario to the right AI pattern

Many AI-103 questions become easier when you first classify the pattern.

Pattern 1: General generative AI interaction

Use this pattern when the app needs to generate, summarize, rewrite, classify, or reason over user-provided text without a requirement to search private enterprise data.

Clues:

• Prompt and response interaction.
• Summarization, drafting, rewriting, extraction from a provided prompt.
• No separate knowledge base requirement.
• No need for citations from private documents.

Likely decision areas:

• Model deployment or endpoint selection.
• Prompt design and instructions.
• Response formatting.
• Temperature or generation settings, if the scenario is about output style.
• Content filtering and safety controls.
• Evaluation of response quality.

Pattern 2: Retrieval-augmented generation over private data

Use this pattern when the app must answer questions from documents, files, manuals, knowledge bases, tickets, policies, product catalogs, or other enterprise data.

Clues:

• “Internal documents”
• “Company knowledge base”
• “Must include citations”
• “Answers must be based only on provided content”
• “Model gives outdated or generic answers”
• “Users need answers from indexed files”
• “Search relevance is poor”

Likely decision areas:

• Indexing content with Azure AI Search.
• Chunking and embedding content.
• Vector search, keyword search, semantic ranking, or hybrid retrieval.
• Field mappings, filters, metadata, and citations.
• Retrieval parameters and grounding prompts.
• Document ingestion and refresh processes.

Key reasoning habit: if the problem is missing or ungrounded knowledge, improve retrieval and grounding before choosing training or prompt-only changes.

Pattern 3: Agent or tool-calling workflow

Use this pattern when the AI system needs to take actions, call APIs, query systems, orchestrate steps, or use tools.

Clues:

• “Agent”
• “Call an internal API”
• “Check order status”
• “Create a support ticket”
• “Use tools”
• “Invoke a function”
• “Plan multiple steps”
• “Connect to enterprise data or actions”

Likely decision areas:

• Defining tool/function schemas.
• Granting the app or agent access to required APIs.
• Validating tool inputs and outputs.
• Applying least privilege to tool execution.
• Adding human approval for sensitive actions.
• Logging tool calls for observability.

Key reasoning habit: an agent is not just a longer prompt. If the scenario requires interaction with external systems, look for tool, function, connector, identity, and permission choices.

Pattern 4: Document and content extraction

Use this pattern when the requirement is to extract structured data from forms, invoices, receipts, contracts, IDs, tables, or scanned documents.

Clues:

• “Extract fields”
• “Analyze forms”
• “Read scanned documents”
• “Return key-value pairs”
• “Recognize layout or tables”
• “Process invoices or receipts”
• “Convert documents into structured data”

Likely decision areas:

• Azure AI Document Intelligence for document analysis and extraction.
• Prebuilt versus custom extraction, depending on the scenario.
• OCR and layout analysis.
• Post-processing and validation.
• Storing structured results for search or downstream applications.

Key reasoning habit: if the output must be reliable structured fields from documents, a document intelligence approach is usually more direct than a generic chat prompt.

Pattern 5: Language, speech, vision, and translation services

Use this pattern when the task maps clearly to a specialized AI capability.

Clues:

• Sentiment, key phrase extraction, language detection, named entity recognition, PII detection.
• Speech-to-text or text-to-speech.
• Image analysis, tagging, captioning, OCR, or visual recognition.
• Translation between languages.

Likely decision areas:

• Azure AI Language.
• Azure AI Speech.
• Azure AI Vision.
• Azure AI Translator.
• Authentication, endpoints, SDK usage, and result handling.

Key reasoning habit: specialized Azure AI services can be more appropriate than a general generative model when the scenario asks for a well-defined recognition, extraction, translation, or analysis task.

Pattern 6: Safety, evaluation, and monitoring

Use this pattern when the question focuses on responsible AI, harmful content, response quality, observability, or production validation.

Clues:

• “Unsafe responses”
• “Jailbreak attempts”
• “Prompt injection”
• “Toxic content”
• “Evaluate answers”
• “Monitor quality”
• “Compare prompts or models”
• “Detect groundedness issues”
• “Review failed conversations”

Likely decision areas:

• Content filtering or Azure AI Content Safety.
• Prompt shields or prompt-injection mitigation patterns, where applicable.
• Evaluation datasets and automated evaluations.
• Logging prompts, responses, retrieval results, and tool calls in a privacy-aware way.
• Human review workflows for high-risk outputs.
• Guardrails in both system instructions and application logic.

Key reasoning habit: safety is not only a prompt issue. Look for controls at input, retrieval, model response, tool execution, and monitoring layers.

Identify the environment before choosing the answer

AI-103 scenarios often include Azure context that narrows the best answer. Identify the environment details early.

Look for:

• Where the app runs: App Service, Azure Functions, containers, AKS, local development, or another hosting platform.
• Where the model is accessed: an Azure AI project, model deployment, endpoint, or service resource.
• Where data lives: Azure Storage, databases, documents, APIs, search indexes, or external systems.
• How users authenticate: Microsoft Entra ID, application identity, service principals, managed identities, or keys.
• Network posture: public endpoint, private endpoint, virtual network integration, firewall restrictions, or private-only access.
• Operational needs: logging, monitoring, scaling, retry behavior, CI/CD, or environment separation.

Environment facts are not filler. They often explain why one option is more secure or more feasible than another.

Example: environment fact changes the answer

Scenario clue:

• The application is hosted in Azure.
• It accesses Azure AI services.
• The company does not allow secrets in application settings.
• Access must use least privilege.

Reasoning:

• The environment supports managed identity.
• The constraint rejects stored API keys or shared secrets.
• The best answer will likely involve assigning the application a managed identity and granting only the required role permissions.

Find the symptom or goal

Every scenario has a center of gravity. You need to determine whether the question is about design or troubleshooting.

If it is a design scenario

Ask:

• What capability must be added?
• What service or component naturally provides that capability?
• What constraints limit the architecture?
• What is the simplest production-ready design?

Design examples:

• “Build an app that answers questions from internal manuals.”
• “Create an agent that can call a shipping API.”
• “Extract fields from invoices.”
• “Generate speech from text.”
• “Prevent harmful user prompts from producing unsafe responses.”

If it is a troubleshooting scenario

Ask:

• What changed?
• What is failing?
• Is the failure before the model call, during retrieval, during generation, or after response processing?
• What is the lowest-risk diagnostic or corrective action?
• Does the answer fix the root cause or only hide the symptom?

Troubleshooting examples:

• “The app receives 403 errors when calling an Azure AI resource.”
• “The model answers but ignores internal documents.”
• “Search returns no results after new documents are uploaded.”
• “The agent calls the wrong tool.”
• “Responses are not valid JSON.”
• “Users receive throttling errors during peak usage.”

Separate requirement types

A useful AI-103 habit is to label facts by requirement type. This keeps you from treating every sentence equally.

Functional requirements

These describe what the application must do.

Examples:

• Answer questions.
• Summarize conversations.
• Extract document fields.
• Classify support tickets.
• Translate text.
• Generate speech.
• Call a business API.
• Return structured JSON.

Data requirements

These describe what information the application must use.

Examples:

• Internal PDFs.
• Uploaded images.
• Audio recordings.
• Customer support transcripts.
• Product catalog data.
• Existing search index.
• Real-time API data.
• Documents with metadata filters.

Security requirements

These describe access, protection, and governance.

Examples:

• Use Microsoft Entra ID.
• Avoid storing secrets.
• Use managed identity.
• Restrict access to private network paths.
• Apply least privilege.
• Store secrets in Key Vault when secrets are unavoidable.
• Prevent unauthorized access to data sources.
• Filter harmful content.

Quality requirements

These describe how good, reliable, or controlled the output must be.

Examples:

• Include citations.
• Use only provided documents.
• Return a fixed schema.
• Minimize hallucinations.
• Improve search relevance.
• Support multilingual input.
• Reduce latency.
• Improve consistency.
• Evaluate responses before deployment.

Operational requirements

These describe production behavior.

Examples:

• Monitor failures.
• Log prompts and responses appropriately.
• Retry transient errors.
• Handle rate limits.
• Scale during peak usage.
• Separate development, test, and production resources.
• Automate deployment.
• Refresh indexes when documents change.

Once you label the requirement type, the answer category becomes clearer.

Decision sequence for service selection

When the options are services or major components, use this sequence.

Step 1: Is the task specialized or generative?

If the task is a standard AI recognition or extraction task, a specialized service may be best.

• Forms and document fields: consider document intelligence capabilities.
• Language analysis: consider language capabilities.
• Speech input or output: consider speech capabilities.
• Image analysis or OCR: consider vision capabilities.
• Translation: consider translator capabilities.

If the task requires open-ended generation, conversational reasoning, summarization, or natural language interaction, consider a generative AI model pattern.

Step 2: Does the model need external or private knowledge?

If yes, choose a grounding and retrieval pattern.

• Use a search index or retrieval layer for enterprise data.
• Generate embeddings where vector retrieval is required.
• Preserve metadata for filtering and citations.
• Update indexes as source content changes.
• Prompt the model to answer from retrieved context.

If no, focus on the model call, prompt, response format, and safety controls.

Step 3: Does the app need to perform actions?

If yes, evaluate agent and tool-calling design.

• Define tools with clear schemas.
• Authenticate tool access securely.
• Limit tool permissions.
• Validate tool inputs and outputs.
• Add approval or review for sensitive operations.

If no, avoid overcomplicating the design with agents.

Step 4: What identity and network model is required?

Before selecting an answer that uses keys or public endpoints, check the constraints.

• If the app runs in Azure and secrets are prohibited, managed identity is often the strongest fit.
• If access must be private, look for private endpoint or network integration choices.
• If users need delegated access, consider how Microsoft Entra ID and RBAC apply.
• If service-to-service access is needed, prefer least-privilege application identity.

Step 5: What is the minimum change that satisfies the requirement?

Avoid answers that rebuild a working system unless the scenario requires it. In troubleshooting, the least disruptive effective fix is often preferred.

Examples:

• If authentication fails, fix identity or permissions before changing the model.
• If retrieval misses documents, fix indexing, chunking, field mappings, or filters before changing the hosting platform.
• If output format is inconsistent, use structured output controls or validation before replacing the entire model architecture.
• If unsafe content appears, add appropriate safety controls and evaluation rather than only changing user instructions.

Reading Azure AI Search and RAG scenarios

RAG scenarios are common because they combine AI application logic, search, embeddings, security, and quality.

Key facts to locate

When you see a RAG scenario, find:

• Source content: documents, database rows, tickets, product pages, or blob files.
• Ingestion method: manual upload, indexer, pipeline, or custom code.
• Index fields: content, title, metadata, permissions, vectors, filters.
• Retrieval type: keyword, vector, semantic, or hybrid.
• Grounding requirement: answer only from retrieved content, include citations, or say “I do not know.”
• Refresh requirement: how new or updated documents become searchable.
• Access control: whether users should see only authorized documents.
• Quality issue: no results, irrelevant results, hallucinations, missing citations, or stale answers.

Common RAG decision points

Use these reasoning links:

• Need private document answers: add retrieval over indexed content.
• Need similarity search: generate embeddings and store vectors in an index that supports vector search.
• Need both exact terms and semantic similarity: consider hybrid retrieval.
• Need citations: preserve source metadata and pass retrieved references into the response workflow.
• Need user-specific document access: include security trimming or filtering based on permissions.
• New documents are not searchable: check ingestion, indexer execution, data source connection, and index refresh.
• Search results are irrelevant: examine chunking, field selection, analyzers, vector fields, semantic configuration, filters, and ranking approach.

RAG example

Scenario:

An internal support chatbot answers questions about troubleshooting procedures. Users report that it gives plausible but incorrect answers for recently updated procedures. The source documents are stored in a company knowledge base. The app currently sends user questions directly to a model without retrieving documents.

Decision:

The issue is not primarily model creativity. The app lacks grounding in current company content. The defensible answer is to index the knowledge base, retrieve relevant passages, and include them as grounding context for the model, with citations if required.

Reading agent scenarios

Agent scenarios require careful separation of conversation, reasoning, and action.

Identify the agent’s job

Ask whether the agent must:

• Answer questions only.
• Retrieve knowledge.
• Call tools.
• Execute business actions.
• Coordinate multiple steps.
• Ask clarifying questions.
• Escalate to a human.
• Follow approval rules.

A scenario that says “agent” may still only require retrieval and response. Conversely, a scenario that says “chatbot” may actually require tool calling if it needs to act on external systems.

Check tool requirements

If a scenario includes tools or APIs, identify:

• Which tool is needed for which task.
• What input parameters the tool requires.
• Whether the model should choose the tool or the app should route explicitly.
• What permissions the tool has.
• How tool output is validated.
• What happens if the tool fails.
• Whether the action is read-only or modifies data.

Read-only tool calls, such as checking order status, require different controls than write actions, such as issuing refunds or changing account settings.

Agent example

Scenario:

A customer service app must allow users to ask about order status. Order status is stored in an internal API. The AI response must use live order data and must not invent status values.

Decision:

The best answer should connect the model or agent workflow to the internal API through a defined tool or function, validate the returned data, and use that tool output in the response. A prompt that asks the model to “be accurate” is not enough because the model does not have live order data by default.

Reading security and least-privilege scenarios

Security facts can override otherwise correct technical answers. In AI-103 scenarios, always check identity, network, data access, and safe output.

Identity and access

Prefer answers that align with least privilege.

Strong signals:

• “No secrets in code”
• “No API keys in configuration”
• “Use Microsoft Entra ID”
• “Access must be limited to the application”
• “Developers should not have production keys”
• “Grant only the permissions required”

Likely reasoning:

• Use managed identities for Azure-hosted workloads when supported.
• Use RBAC to grant only required roles.
• Store unavoidable secrets in Key Vault rather than code or plain configuration.
• Avoid broad admin keys when a narrower identity-based permission works.
• Separate human developer access from application runtime access.

Network isolation

Network facts matter when resources are private.

Strong signals:

• “Private endpoint”
• “Disable public network access”
• “Virtual network”
• “Firewall”
• “No public internet”
• “On-premises connectivity”
• “Corporate network only”

Likely reasoning:

• Ensure the app can reach the service through the allowed network path.
• Configure private endpoint and DNS correctly when required.
• Avoid answers that rely on public endpoints if the scenario prohibits them.
• Consider how data ingestion services reach source data.

Data protection and responsible AI

AI applications handle prompts, documents, responses, and tool outputs. Scenarios may require controls around:

• PII detection or redaction.
• Harmful content detection.
• Prompt injection defense.
• Grounding restrictions.
• Logging that avoids exposing sensitive data.
• Human review for high-risk cases.
• Evaluation before production release.

If the question asks for a safe production design, do not stop at the model call. Think about the full path from user input to model output to tool action.

Reading troubleshooting scenarios

Troubleshooting questions usually reward root-cause thinking. Start by locating where the failure occurs.

Authentication or authorization failures

Symptoms:

• 401 Unauthorized.
• 403 Forbidden.
• Works locally but fails in Azure.
• App cannot access an AI resource, search index, storage account, or API.
• User or managed identity lacks access.

Reasoning sequence:

1. Identify the caller: user, app registration, managed identity, service principal, or key.
2. Identify the target resource.
3. Check whether authentication is configured.
4. Check whether authorization grants the required role or permission.
5. Prefer least-privilege correction over broad administrative access.

Retrieval failures

Symptoms:

• The model responds, but ignores company documents.
• Search returns no results.
• New documents are missing.
• Results are unrelated.
• Citations are missing or wrong.
• Filters exclude expected documents.

Reasoning sequence:

1. Confirm the documents were ingested.
2. Confirm content fields and metadata are mapped.
3. Confirm vector fields and embeddings are compatible when vector search is used.
4. Check filters, security trimming, and metadata values.
5. Check chunking and retrieval settings.
6. Confirm retrieved context is actually passed to the model.

Generation quality failures

Symptoms:

• Hallucinated answers.
• Inconsistent formatting.
• Verbose or off-topic responses.
• Missing required JSON fields.
• Unsafe responses.
• Refusal when a safe answer is expected, or unsafe answer when refusal is required.

Reasoning sequence:

1. Determine whether the model has the required context.
2. Improve grounding before changing model size or training.
3. Use clearer system and developer instructions.
4. Use structured output controls or validation when schema compliance is required.
5. Use safety filters and content-safety checks where required.
6. Evaluate responses with representative test cases.

Rate limit, quota, or transient failures

Symptoms:

• 429 errors.
• Intermittent failures under load.
• Requests fail during peak traffic.
• Latency increases sharply.
• Retryable service errors.

Reasoning sequence:

1. Confirm whether the error is transient, throttling, or capacity-related.
2. Use retry with exponential backoff for transient failures.
3. Review concurrency and request volume.
4. Optimize request size and batching when appropriate.
5. Consider quota, scaling, or deployment capacity options based on the scenario.
6. Avoid changing prompts as the primary fix for throttling.

Tool-calling failures

Symptoms:

• The agent calls the wrong tool.
• Tool inputs are incomplete.
• Tool output is ignored.
• Tool call succeeds but response is inaccurate.
• Sensitive action is performed without approval.

Reasoning sequence:

1. Check tool descriptions and schemas.
2. Ensure required parameters are available or collected.
3. Validate tool output before using it.
4. Restrict tool permissions.
5. Add approval steps for sensitive actions.
6. Log tool calls for diagnosis.

How to evaluate answer options

After reading the scenario, evaluate each option using these questions.

Does the option answer the exact question?

If the question asks “Which service should you use?”, eliminate answers that describe monitoring, prompts, or permissions unless they are the service choice being tested.

If the question asks “What should you configure?”, choose the specific component, not a broad architecture statement.

Does the option satisfy all hard constraints?

An answer that solves the business problem but violates a security, network, or data requirement is not the best answer.

Examples:

• Using an API key may work technically but fail a “no secrets” requirement.
• Sending requests to a public endpoint may fail a private-network requirement.
• Using general model knowledge may fail a “must answer only from company documents” requirement.
• Giving a broad role may fail a least-privilege requirement.

Is the option appropriately scoped?

Prefer specific, targeted answers over vague ones.

Less defensible:

• “Use AI.”
• “Retrain the model.”
• “Increase the maximum tokens.”
• “Give the app admin access.”
• “Move all data to a new platform.”

More defensible:

• “Index the documents and retrieve relevant chunks as grounding context.”
• “Assign the app’s managed identity the required role on the target resource.”
• “Define a tool for the order-status API and validate its returned values.”
• “Use structured output and schema validation for required JSON.”
• “Configure content safety checks for user input and model output.”

Does the option minimize unnecessary change?

In final review, train yourself to prefer the smallest correct production-grade change.

Examples:

• If an existing app only needs secure access to an Azure AI resource, configure identity and RBAC rather than redesigning the app.
• If documents are not searchable, fix the ingestion or index configuration rather than replacing the model.
• If the output must be valid JSON, use response formatting and validation rather than adding a search index.
• If users require document-specific answers, add retrieval rather than increasing temperature.

Is the option operationally supportable?

Production AI apps need more than a demo path.

Supportable answers often include:

• Secure authentication.
• Proper role assignment.
• Observability.
• Evaluation.
• Retry handling.
• Controlled access to data.
• Safety filters.
• Clear separation of application logic, retrieval, and model interaction.

If two answers appear correct, the one that is more secure, maintainable, and aligned with Azure operational practices is usually stronger.

Small scenario drills

Use these examples to practice the reasoning sequence.

Drill 1: Internal knowledge answers

A company wants a chat application that answers employee questions using internal policy documents. Answers must include citations and must not rely on general model knowledge.

Reasoning:

• Workload: grounded chat over private documents.
• Data requirement: internal policy documents.
• Quality requirement: citations and document-grounded answers.
• Best direction: index and retrieve relevant document passages, pass them as context, preserve citation metadata, and instruct the model to answer from retrieved content.

Avoid choosing an answer that only changes the prompt without adding access to the documents.

Drill 2: Secure Azure-hosted app

An Azure-hosted web app calls an Azure AI service. The organization prohibits secrets in application settings and requires least privilege.

Reasoning:

• Workload: service-to-service access.
• Constraint: no stored secrets.
• Security requirement: least privilege.
• Best direction: use the app’s managed identity and grant only the required RBAC permissions to the target resource.

Avoid choosing broad admin access or embedding keys in configuration.

Drill 3: Structured extraction from invoices

A finance team needs to extract vendor name, invoice date, line items, and totals from uploaded invoice PDFs.

Reasoning:

• Workload: document extraction.
• Data type: invoices in PDF form.
• Output: structured fields.
• Best direction: use document analysis or document intelligence capabilities designed for structured extraction, then validate and store the extracted fields.

Avoid treating the invoice as a general conversation unless the scenario specifically asks for conversational analysis.

Drill 4: Live order status agent

A customer asks a support assistant for the status of an order. The current model sometimes guesses the status. The order state is stored in an internal API.

Reasoning:

• Workload: agent/tool use with live data.
• Symptom: model guesses.
• Data source: internal API.
• Best direction: define a tool or function for the order-status API, authenticate securely, call it when needed, and generate the response from the returned data.

Avoid relying on prompt wording alone.

Drill 5: Unsafe user prompts

A public-facing app receives prompts that attempt to produce harmful content and manipulate system instructions.

Reasoning:

• Workload: generative app with safety risk.
• Symptom: unsafe or adversarial inputs.
• Requirement: protect input and output behavior.
• Best direction: combine clear instructions, content safety controls, prompt-injection mitigation patterns, output checks, logging, and evaluation with representative adversarial examples.

Avoid assuming a single instruction will fully solve safety and abuse scenarios.

Final-review checklist for AI-103 scenarios

Before selecting an answer, ask:

• What is the actual workload: generation, RAG, agent, extraction, search, speech, vision, translation, or safety?
• What is the exact decision point: service, configuration, identity, tool, index, model interaction, or troubleshooting step?
• Which facts are hard constraints?
• What data must the app use?
• Does the model already have access to that data?
• Is the current issue in authentication, retrieval, generation, tool execution, networking, or monitoring?
• Does the answer use least privilege?
• Does the answer avoid unnecessary secrets?
• Does the answer respect private networking or data boundaries?
• Does the answer produce the required output format?
• Does the answer improve quality in the layer where the problem exists?
• Can you justify the answer using only the scenario facts?

Practice strategy for scenario mastery

For each AI-103 practice question, do more than mark right or wrong. After answering, write one sentence for each of these:

• “The workload was…”
• “The key constraint was…”
• “The decision point was…”
• “The correct answer worked because…”
• “The other plausible answer failed because…”

Then group missed questions by reasoning category:

• Service selection.
• RAG and Azure AI Search.
• Agents and tool calling.
• Identity and least privilege.
• Networking and private access.
• Prompting and structured output.
• Safety and evaluation.
• Troubleshooting and operations.

For your next study session, complete a short topic drill in your weakest category, then take a timed mixed scenario set. Use the five-pass method until it becomes automatic, especially on longer questions where the best answer depends on one constraint hidden in the middle of the scenario.