AI-200 — Microsoft Azure AI Cloud Developer Associate Scenario Practice Guide

How to approach AI-200 scenario questions

Scenario questions on the Microsoft Azure AI Cloud Developer Associate exam are usually asking you to make a practical cloud development decision. The question may describe an application, a data source, a user requirement, an Azure AI service, an error condition, or a security constraint. Your job is not to pick the most familiar tool. Your job is to choose the answer that best fits the facts given.

For AI-200, read each scenario as an implementation problem:

• What is the application trying to do?
• What type of AI workload is involved?
• What Azure environment already exists?
• What must be preserved, secured, minimized, or improved?
• Is the question asking for a service, an API operation, an authentication method, a configuration, an architecture, or a troubleshooting step?

This guide is independent exam-preparation guidance. It does not claim affiliation with Microsoft. Use it to build a disciplined way to slow down, identify the decision point, and select the most defensible answer.

The AI-200 scenario reading routine

Use the same reading sequence every time. It reduces overthinking and helps you avoid choosing an answer based on one isolated keyword.

1. Classify the workload

Before reading the answer choices closely, decide what kind of AI task the scenario describes.

Common AI-200 workload patterns include:

• Conversational or generative AI: chat, summarization, content generation, prompt-based reasoning, embeddings, or grounded responses.
• Search and retrieval: indexing documents, semantic search, vector search, retrieval-augmented generation, or enterprise knowledge lookup.
• Language understanding: sentiment, key phrases, named entities, PII detection, classification, translation, or text analytics.
• Document processing: extracting fields, tables, layouts, or values from forms, invoices, receipts, PDFs, or scanned documents.
• Vision: image analysis, OCR, object detection, image tagging, or visual content interpretation.
• Speech: speech-to-text, text-to-speech, translation, transcription, or voice-enabled applications.
• Safety and moderation: detecting harmful text or image content, filtering outputs, or enforcing responsible AI controls.
• Integration and deployment: connecting an application to an Azure AI endpoint, deploying a model, securing access, monitoring behavior, or troubleshooting calls.

This first classification keeps you from confusing related services. For example, a scenario about extracting invoice fields is not just “text analysis”; it is likely a document intelligence problem. A scenario about answering questions from internal policy documents is not only “chat”; it may require retrieval and grounding.

2. Identify the existing environment

Scenario facts often tell you what already exists. Do not ignore them.

Look for:

• The application type: web app, API, bot, mobile app, background job, containerized service, or serverless function.
• The Azure resources: Azure AI services, Azure AI Search, Azure OpenAI, Azure AI Foundry resources, storage accounts, Key Vault, App Service, Azure Functions, containers, or virtual networks.
• The data source: PDFs, images, transcripts, logs, documents, databases, blob storage, SharePoint-like repositories, or user-generated prompts.
• The authentication model: keys, Microsoft Entra ID, managed identity, service principal, role-based access control, or Key Vault.
• Network posture: public endpoint, private endpoint, restricted network, private data, or compliance-sensitive environment.
• Current state: service already deployed, index already built, model already selected, errors occurring, latency problem, or new requirement being added.

The existing environment matters because the best answer is often the one that changes the fewest parts while meeting the requirement.

3. Find the actual decision point

Many scenarios include background information that is useful but not decisive. Ask: “What decision am I being asked to make?”

The decision point may be:

• Service selection: Which Azure AI service best satisfies the requirement?
• Architecture choice: How should the application combine services?
• Configuration: Which feature, setting, index, deployment, or resource configuration is needed?
• Security control: Which identity, permission, secret-handling method, or network control should be used?
• Development step: Which SDK call, endpoint, prompt pattern, or API interaction is appropriate?
• Troubleshooting action: What should be checked or changed first?
• Operational improvement: How should monitoring, evaluation, content filtering, scaling, or reliability be handled?

If you cannot express the decision point in one sentence, reread the final sentence of the question. It usually tells you whether you are choosing a service, a configuration, a fix, or an implementation approach.

4. Separate hard constraints from preferences

A hard constraint must be satisfied. A preference is useful but may not decide the answer.

Hard constraints often include:

• Must use private data without exposing it publicly.
• Must avoid storing secrets in application code.
• Must support a specific input type, such as audio, image, PDF, or unstructured text.
• Must preserve existing application architecture.
• Must minimize development effort.
• Must meet least-privilege access requirements.
• Must process documents with variable layouts or known templates.
• Must provide grounded answers from enterprise documents.
• Must detect or block unsafe user-generated content.
• Must diagnose an authentication, endpoint, deployment, or configuration failure.

Preferences are weaker phrases such as “prefer,” “ideally,” “where possible,” or “the team is considering.” Do not let a preference override a hard requirement.

5. Choose the answer that satisfies all decisive facts

The best answer is usually the one that:

• Directly addresses the stated goal or symptom.
• Uses the service or feature designed for that workload.
• Respects security and access constraints.
• Avoids unnecessary migration, retraining, or rearchitecture.
• Fits the existing environment.
• Is operationally reasonable for a production Azure application.

If two answers seem plausible, compare them against each hard constraint. The better answer usually satisfies more constraints with fewer assumptions.

Reading Azure AI service scenarios

AI-200 scenarios often test whether you can map a requirement to the right Azure AI capability. The key is to translate the business requirement into a technical workload.

When the scenario is about text

Ask what the application needs to do with the text.

• For extracting sentiment, key phrases, entities, PII, or classification from plain text, think about Azure AI Language capabilities.
• For translating text between languages, think about translation services.
• For generating, summarizing, rewriting, or conversing with natural language, think about generative AI model access through Azure.
• For answering questions from private documents, think beyond the model itself. The application may need retrieval, indexing, and grounding.
• For moderating prompts or responses, consider content safety controls rather than a general text analytics feature.

Do not stop at the word “language.” Decide whether the task is analysis, translation, generation, search, grounding, or safety.

When the scenario is about documents

Document scenarios often contain clues such as invoices, receipts, forms, tax documents, contracts, PDFs, scans, or tables.

Read for:

• Whether the document is structured, semi-structured, or unstructured.
• Whether the fields are known in advance.
• Whether the document layout varies.
• Whether the task is OCR only or field extraction.
• Whether a prebuilt model might fit the document type.
• Whether a custom extraction approach is needed.

A scenario asking for text from an image or PDF may only require OCR. A scenario asking for specific invoice fields, totals, dates, vendor names, or line items is a stronger signal for document intelligence.

When the scenario is about images

Vision scenarios usually describe image input and a desired interpretation.

Look for whether the application needs to:

• Extract printed or handwritten text from images.
• Generate tags or captions.
• Identify objects or visual features.
• Analyze user-uploaded images.
• Moderate image content.
• Combine image understanding with another workflow.

If the requirement is safety review of user content, the best answer may involve content safety rather than general image analysis. If the requirement is text extraction from a scanned image, OCR is the decisive capability.

When the scenario is about speech

Speech scenarios are usually decided by the direction of conversion and the user experience.

Ask:

• Is the application converting speech to text?
• Is it converting text to speech?
• Is translation required?
• Is the scenario about live interaction, batch transcription, or accessibility?
• Is speaker separation, custom vocabulary, or pronunciation important?
• Is the output used downstream by a language, search, or generative AI component?

The most defensible answer should match the input and output format. For example, an audio recording that must become searchable text first needs transcription before indexing or analysis.

When the scenario is about search and grounding

Search scenarios often mention internal documents, product manuals, policies, knowledge bases, support articles, or “answers must be based on company data.”

Read for:

• Where the source content lives.
• Whether the content must be indexed.
• Whether semantic or vector retrieval is needed.
• Whether the application needs citations or source grounding.
• Whether the model should answer only from retrieved content.
• Whether updates to documents must be reflected in future answers.

For generative AI questions that require current or private knowledge, the answer is often not “train a new model.” A more defensible approach is frequently to retrieve relevant content from an index and use it to ground the model response, if that satisfies the scenario.

Reading generative AI scenarios

Generative AI scenarios require careful separation between model behavior, data access, safety, and application integration.

Identify what the model lacks

If responses are inaccurate or missing company-specific facts, ask whether the model needs:

• Better prompt instructions.
• Retrieved context from a trusted data source.
• A search index or embedding-based retrieval flow.
• A different model deployment appropriate for the task.
• Output validation or content filtering.
• Monitoring and evaluation of responses.

A model cannot reliably answer from documents it cannot access. If the scenario says answers must come from internal content, the architecture must include a way to retrieve or provide that content.

Distinguish prompting from grounding

Prompting is useful when the issue is response style, format, tone, or task instruction.

Grounding is needed when the issue is knowledge. If the question says responses must reflect current product documentation, policy files, or enterprise content, look for an answer that connects the model to authoritative sources through retrieval or context.

Distinguish grounding from model customization

Some scenarios may mention customization, fine-tuning, or training. Decide why customization is proposed.

• If the application needs domain-specific knowledge that changes frequently, retrieval and grounding may be more appropriate.
• If the application needs consistent output format, style, or task behavior, prompt design, examples, or evaluation may be relevant.
• If the scenario specifically requires adapting model behavior based on examples, a customization approach may be considered if supported and appropriate.

Do not assume every generative AI issue requires training. Also do not assume prompting alone solves missing data access.

Check safety and responsible AI requirements

When the scenario mentions harmful content, policy enforcement, unsafe prompts, regulated data, or user-generated content, include safety controls in your reasoning.

Strong safety-related facts include:

• Block or flag harmful input.
• Prevent unsafe generated output.
• Detect protected or sensitive information.
• Log or review content for moderation workflows.
• Apply safety filters consistently across channels.
• Reduce risk before publishing or returning content to users.

If the scenario includes both generation and moderation, the correct architecture may combine a model with content safety controls rather than rely on either one alone.

Reading security and access scenarios

Security facts are often decisive on AI-200 because Azure AI applications must access services, data, and model deployments safely.

Start with identity

Ask how the application should authenticate.

Common patterns to reason through:

• If the app runs in Azure and the service supports identity-based access, managed identity plus role assignment is often more defensible than hard-coded secrets.
• If a key is required, storing it in a secure secret store such as Key Vault is generally better than storing it in source code or configuration files exposed to developers.
• If users need different levels of access, think in terms of role-based access and least privilege.
• If automation deploys or updates resources, consider service principals, managed identities, and scoped permissions.

The best answer should match the application runtime and avoid unnecessary credential exposure.

Apply least privilege

Least privilege means granting only the access needed for the task.

When comparing answers, ask:

• Does the application need read-only access or management access?
• Does it need access to all resources or only one resource?
• Does the user need to call the service, deploy models, manage keys, or view monitoring data?
• Does the answer grant broad administrative privileges when a narrower role would work?

Broad access may be convenient, but exam scenarios usually favor a secure, scoped approach when the requirement mentions security.

Respect network and data boundaries

If the scenario mentions private endpoints, restricted networks, sensitive data, or no public internet exposure, treat that as a hard constraint.

Read for:

• Whether the application and service can communicate privately.
• Whether public network access should be disabled or restricted.
• Whether data should remain in a specific storage or network boundary.
• Whether traffic should use private connectivity where required.
• Whether the answer accidentally routes data through an unnecessary public path.

Do not choose an answer that satisfies the AI task while violating the security boundary.

Reading troubleshooting scenarios

Troubleshooting questions are not asking for the most powerful change. They ask for the most likely or most appropriate next step based on the symptom.

Name the symptom precisely

Convert the scenario into a short statement:

• The app receives an authentication error.
• The app receives a not found or deployment error.
• The model returns irrelevant answers.
• The search results are empty.
• The document extraction output is missing fields.
• The speech transcription is inaccurate.
• The service call works locally but fails in Azure.
• Latency increased after a configuration change.
• Content is blocked unexpectedly.

A precise symptom helps you avoid unrelated fixes.

Check the request path

For Azure AI development scenarios, verify the path from application to service:

• Correct endpoint.
• Correct resource or deployment name.
• Correct region or service instance.
• Correct API version or SDK configuration.
• Correct authentication method.
• Correct permissions.
• Correct input format.
• Correct index, model, or project reference.
• Correct network route.

Many scenario answers differ by only one configuration detail. Choose the answer that matches the failing part of the request path.

Choose the least disruptive effective fix

If a production app is failing, a defensible answer usually fixes the immediate cause without unnecessary rearchitecture.

Examples of least-disruptive reasoning:

• If a credential expired, rotate or update the credential securely rather than rebuild the service.
• If a managed identity lacks permission, assign the required role rather than store an admin key in code.
• If an index has no documents, configure ingestion or rebuild the index rather than change the generative model.
• If a request references the wrong deployment name, update the application setting rather than create a new Azure subscription.
• If unsafe content is not being blocked, add or configure moderation controls rather than rely only on user instructions.

Matching answer choices to scenario facts

When you reach the answer choices, compare them using a structured process.

Look at the verb first

The verb tells you what kind of action the answer proposes.

Examples:

• Create a service, index, deployment, or resource.
• Configure authentication, networking, logging, safety, or indexing.
• Assign a role or permission.
• Call an API or SDK method.
• Store a secret or configuration value.
• Train or customize a model.
• Add retrieval, moderation, monitoring, or validation.
• Replace an architecture component.

If the scenario asks for a minimal fix, an answer that replaces the architecture may be excessive. If the scenario asks for a new capability, an answer that only changes logging may not address the requirement.

Compare each answer against the hard constraints

Use a quick elimination sequence:

1. Does it solve the stated goal or symptom?
2. Does it support the input data type?
3. Does it fit the existing Azure environment?
4. Does it meet security and least-privilege requirements?
5. Does it avoid unnecessary operational disruption?
6. Does it use the Azure AI service or feature designed for the task?

The answer that survives all six checks is usually the most defensible.

Be careful with broad answers

Some answer choices sound powerful but do not match the scenario.

Examples:

• Training a model when the real issue is missing access to current documents.
• Adding a general language service when the task is structured document extraction.
• Using keys in application code when the requirement says no stored secrets.
• Changing the model when the issue is an empty search index.
• Adding monitoring when the question asks how to authenticate.

Broad answers are not automatically wrong, but they must directly satisfy the facts.

Mini scenario walkthroughs

Use these examples to practice the reasoning style, not to memorize exact answers.

Example 1: Internal policy chatbot

A company wants a chatbot to answer employee questions using HR policy documents stored in a secure repository. Answers must be based on the latest approved documents.

Reasoning sequence:

• Workload: conversational generative AI.
• Key requirement: answers must use internal, current documents.
• Decision point: architecture for grounding.
• Hard constraint: approved documents are authoritative.
• Defensible direction: index or retrieve relevant policy content and provide it as grounding context for the model response. Include access control and update handling as required.

A pure prompt change may improve style, but it does not give the model access to the latest policy documents.

Example 2: Invoice field extraction

An application receives PDF invoices from multiple vendors and must extract invoice numbers, dates, totals, and line items.

Reasoning sequence:

• Workload: document processing.
• Input: PDFs with structured business fields.
• Decision point: service or capability selection.
• Hard requirement: extract specific fields, not just raw text.
• Defensible direction: use a document intelligence capability suited to field extraction, choosing a prebuilt or custom approach based on document type and variability.

Generic OCR may extract text but may not satisfy field-level extraction requirements by itself.

Example 3: No secrets in code

A web application hosted in Azure calls an Azure AI service. Security policy says credentials must not be stored in source code or application settings when identity-based access is available.

Reasoning sequence:

• Workload: secure service access.
• Decision point: authentication method.
• Hard constraint: no stored secrets when identity is available.
• Defensible direction: use a managed identity for the application and grant the required role to access the Azure AI resource. If a key is unavoidable for a specific component, protect it with a secure secret-management pattern.

The answer should not introduce hard-coded keys if the scenario emphasizes identity-based security.

Example 4: Search results are empty

A generative AI application uses a search index to ground responses, but users receive answers saying no relevant information was found. The documents exist in storage.

Reasoning sequence:

• Workload: retrieval and grounding.
• Symptom: retrieval returns no useful content.
• Decision point: troubleshooting step.
• Check path: data source, indexer, index fields, ingestion status, query configuration, permissions.
• Defensible direction: verify that the documents are ingested and searchable in the index before changing the model.

Changing the model may not help if the retrieval layer has no indexed content.

Example 5: User-uploaded content must be screened

A public-facing app allows users to submit text and images. The company must detect harmful content before it is displayed to other users.

Reasoning sequence:

• Workload: safety and moderation.
• Input: user-generated text and images.
• Decision point: control selection.
• Hard requirement: detect harmful content before publication.
• Defensible direction: use content safety or moderation controls appropriate to the content types and integrate them into the upload workflow before content is displayed.

A general vision or language feature may analyze content, but the safety requirement is the decisive fact.

A compact checklist for final review

Before choosing an answer, pause and ask:

• What is the AI workload: language, document, vision, speech, search, generation, safety, or integration?
• What already exists in Azure?
• What is the scenario asking me to choose: service, configuration, code step, security control, or troubleshooting action?
• What is the hard requirement?
• What input type must be supported?
• What output does the application need?
• Is the data private, current, sensitive, or user-generated?
• Is retrieval or grounding required?
• Is identity, least privilege, or network isolation decisive?
• Is the answer a minimal effective fix or an unnecessary redesign?
• Does the answer satisfy every stated constraint without adding assumptions?

How to use scenario practice before the exam

For final review, do not only check whether you got a question right. Review how you read it.

A good practice routine:

1. Read the scenario once without looking at the answers.
2. Write a one-sentence decision point.
3. Mark the hard constraints.
4. Predict the likely service, feature, or action.
5. Compare your prediction to the answer choices.
6. Explain why the correct answer is more defensible than the closest alternative.
7. Revisit the related Azure AI topic if your reasoning depended on guessing.

Use topic drills to strengthen weak service mappings, then use mixed scenario sets to practice switching between language, document, vision, speech, search, generative AI, security, and troubleshooting decisions. Finish with timed mock exams so you can apply the same reading routine under exam conditions.