Scenario practice questions

You are building a custom text classification solution using Azure AI Language in Language Studio. You have a dataset where each document can belong to multiple categories simultaneously (e.g., a news article can be tagged as both 'Technology' and 'Finance'). What classification type should you configure?

Trap 1: Custom named entity recognition

Custom NER extracts entity spans (people, places, dates) from text; it assigns no document-level category labels. Multi-label classification requires the multi-label classification project type, which outputs independent per-category probabilities. NER would be correct for locating and tagging specific entities inside documents, not for classifying whole documents into overlapping categories.

Trap 2: Single-label classification

Single-label classification assigns exactly one category per document, so it cannot represent articles tagged both Technology and Finance. It is tempting because it is the default project type in Language Studio, but multi-label classification is the correct choice when categories co-occur.

Trap 3: Extractive summarization

Extractive summarization selects and returns salient sentences from a document; it produces no category labels at all. The stem demands assigning multiple simultaneous categories per document, which only the multi-label classification project type supports. Summarization would be the right choice when the goal is condensing a document into its key sentences.

A
Custom named entity recognition
Why it fails: Custom NER extracts entity spans (people, places, dates) from text; it assigns no document-level category labels. Multi-label classification requires the multi-label classification project type, which outputs independent per-category probabilities. NER would be correct for locating and tagging specific entities inside documents, not for classifying whole documents into overlapping categories.
B
Multi-label classification
Multi-label classification assigns every applicable category to a document independently, rather than forcing a single mutually exclusive choice. This directly satisfies the stem's constraint that a news article can be tagged as both 'Technology' and 'Finance' simultaneously, which single-label classification cannot represent.
C
Single-label classification
Why it fails: Single-label classification assigns exactly one category per document, so it cannot represent articles tagged both Technology and Finance. It is tempting because it is the default project type in Language Studio, but multi-label classification is the correct choice when categories co-occur.
D
Extractive summarization
Why it fails: Extractive summarization selects and returns salient sentences from a document; it produces no category labels at all. The stem demands assigning multiple simultaneous categories per document, which only the multi-label classification project type supports. Summarization would be the right choice when the goal is condensing a document into its key sentences.

Question 2hardmultiple choice

You are managing a multi-tenant SaaS application that uses Azure AI Vision. Each tenant has their own isolated data, and you want to track costs per tenant. How should you provision Azure AI services to achieve granular cost attribution?

Trap 1: Use a single global Azure AI Services resource and parse tenant IDs…

A single shared resource aggregates all tenants' consumption into one billing meter, so per-tenant costs cannot be separated; user-agent headers are not a billing dimension. It is tempting because one resource is cheap to operate, but granular attribution requires a separate Azure AI Services resource per tenant.

Trap 2: Store tenant IDs in Custom Vision project tags.

Custom Vision project tags label training images and model metadata; they carry no billing or usage telemetry, so Azure Cost Management cannot attribute spend by them. Tags are tempting because they do organise projects, but cost attribution needs distinct Azure AI Services resources per tenant, each with its own meter.

Trap 3: Use Azure Blob Storage cost allocation tags to cover AI API costs.

Blob Storage allocation tags only attribute storage consumption; Azure AI Vision API calls are billed against the Cognitive Services resource, not the storage account, so those charges remain unattributed. Storage tags are tempting because they do split costs, but they cannot reach AI transaction meters.

A
Use a single global Azure AI Services resource and parse tenant IDs from request user-agent headers for billing.
Why it fails: A single shared resource aggregates all tenants' consumption into one billing meter, so per-tenant costs cannot be separated; user-agent headers are not a billing dimension. It is tempting because one resource is cheap to operate, but granular attribution requires a separate Azure AI Services resource per tenant.
B
Store tenant IDs in Custom Vision project tags.
Why it fails: Custom Vision project tags label training images and model metadata; they carry no billing or usage telemetry, so Azure Cost Management cannot attribute spend by them. Tags are tempting because they do organise projects, but cost attribution needs distinct Azure AI Services resources per tenant, each with its own meter.
C
Deploy a dedicated Azure AI Services resource per tenant and use Azure Cost Management for billing attribution.
A dedicated Azure AI Services resource per tenant creates a separate billing boundary, so each tenant's consumption maps to its own resource and cost data. Azure Cost Management then attributes spend per resource, satisfying the requirement for granular per-tenant cost tracking in the multi-tenant SaaS application.
D
Use Azure Blob Storage cost allocation tags to cover AI API costs.
Why it fails: Blob Storage allocation tags only attribute storage consumption; Azure AI Vision API calls are billed against the Cognitive Services resource, not the storage account, so those charges remain unattributed. Storage tags are tempting because they do split costs, but they cannot reach AI transaction meters.

Question 3easymultiple choice

Your company wants to generate descriptive captions for thousands of product images automatically using Azure AI Vision. Which visual feature parameter should you specify in the analyze request?

Trap 1: features=read

features=read runs Optical Character Recognition, returning extracted text rather than natural-language descriptions, so no captions are produced. It tempts because OCR is a common Vision feature, and read would be correct when the goal is transcribing text from scanned documents or signage instead of describing image content.

Trap 2: features=smartCrops

features=smartCrops returns suggested crop rectangles and aspect-ratio coordinates, not descriptive text, so no caption is generated. It tempts because smartCrops is genuinely useful for automated image thumbnailing and resizing pipelines, but it yields bounding boxes rather than the natural-language description this scenario requires.

Trap 3: features=objects

features=objects returns detected object names with bounding-box coordinates, not a grammatical sentence describing the whole image. It tempts because object detection is a Vision capability, and it would be correct when the requirement is locating and labelling individual items within an image rather than producing captions.

A
features=read
Why it fails: features=read runs Optical Character Recognition, returning extracted text rather than natural-language descriptions, so no captions are produced. It tempts because OCR is a common Vision feature, and read would be correct when the goal is transcribing text from scanned documents or signage instead of describing image content.
B
features=smartCrops
Why it fails: features=smartCrops returns suggested crop rectangles and aspect-ratio coordinates, not descriptive text, so no caption is generated. It tempts because smartCrops is genuinely useful for automated image thumbnailing and resizing pipelines, but it yields bounding boxes rather than the natural-language description this scenario requires.
C
features=caption
Specifying features=caption invokes the Caption visual feature, which returns a single-sentence natural-language description of an image via the Azure AI Vision analyse endpoint. This directly satisfies the stem's requirement to generate descriptive captions for thousands of product images automatically, without custom model training.
D
features=objects
Why it fails: features=objects returns detected object names with bounding-box coordinates, not a grammatical sentence describing the whole image. It tempts because object detection is a Vision capability, and it would be correct when the requirement is locating and labelling individual items within an image rather than producing captions.

Question 4hardmultiple choice

You are building an agentic workflow in Azure AI Foundry. You need the agent to perform a multi-step task: search a database, summarize results, and then send an email. Which component is best suited to manage this orchestration?

Trap 1: Azure OpenAI fine-tuning service.

Fine-tuning alters model weights for response style or domain tone; it executes no steps, calls no database and sends no email. It is correct when adapting a base model's behaviour, not for orchestrating tool calls across a workflow.

Trap 2: Azure AI Search indexer.

An Azure AI Search indexer populates and refreshes a search index from data sources; it performs retrieval only, with no branching, sequencing or tool invocation. It is correct for grounding retrieval, not for coordinating database, summarisation and email steps.

Trap 3: Azure AI Content Safety API.

Content Safety screens prompts and outputs for harmful content; it does not sequence tool calls, so it cannot orchestrate search, summarisation and email steps. It is tempting because it governs agent behaviour, and it would be correct when the requirement is filtering toxic or unsafe text rather than managing multi-step execution.

A
Azure AI Agent Service.
Azure AI Agent Service provides built-in orchestration for multi-step tool use, chaining database search, summarisation and email sending through its thread and tool-calling runtime. It satisfies the requirement to manage sequential task orchestration without custom glue code.
B
Azure OpenAI fine-tuning service.
Why it fails: Fine-tuning alters model weights for response style or domain tone; it executes no steps, calls no database and sends no email. It is correct when adapting a base model's behaviour, not for orchestrating tool calls across a workflow.
C
Azure AI Search indexer.
Why it fails: An Azure AI Search indexer populates and refreshes a search index from data sources; it performs retrieval only, with no branching, sequencing or tool invocation. It is correct for grounding retrieval, not for coordinating database, summarisation and email steps.
D
Azure AI Content Safety API.
Why it fails: Content Safety screens prompts and outputs for harmful content; it does not sequence tool calls, so it cannot orchestrate search, summarisation and email steps. It is tempting because it governs agent behaviour, and it would be correct when the requirement is filtering toxic or unsafe text rather than managing multi-step execution.

Question 5hardmulti select

You are troubleshooting a Custom Vision object detection model that exhibits poor performance in production. Which THREE actions can you take using the Custom Vision portal or APIs to diagnose and improve the model? (Choose three.)

Trap 1: Delete all project iteration history to reset model weights to…

Deleting iterations removes trained snapshots and their performance metrics; it does not reset weights to random initialisation, and it destroys the evidence needed to compare models. It is tempting as a clean-slate remedy, but retraining with additional labelled images is the actual mechanism for improving a poorly performing detector.

Trap 2: Manually edit model neural network weights via the REST API.

Custom Vision exposes training, prediction and iteration endpoints; no REST API permits editing neural network weights, which are learned internally during training. It is tempting because the REST API does allow programmatic control of projects, and it would be correct for automating training, publishing or exporting an iteration as a model.

A
Delete all project iteration history to reset model weights to random initialization.
Why it fails: Deleting iterations removes trained snapshots and their performance metrics; it does not reset weights to random initialisation, and it destroys the evidence needed to compare models. It is tempting as a clean-slate remedy, but retraining with additional labelled images is the actual mechanism for improving a poorly performing detector.
B
Examine prediction suggestions to find low-confidence or incorrectly predicted images and add them to training data.
Examining prediction suggestions surfaces production images where confidence scores fall below threshold or labels diverge from ground truth, exposing distribution gaps between training and live data. Adding these misclassified samples to the training set directly addresses the poor production performance constraint by retraining the model on representative edge cases it previously never encountered.
C
Review precision and recall metrics per tag in the Performance tab.
Reviewing per-tag precision and recall in the Performance tab exposes which object classes the model detects poorly, satisfying the need to diagnose weak performance. Precision reveals false positives and recall reveals missed detections, so you can pinpoint underperforming tags before adding training data or adjusting the domain.
D
Adjust the probability threshold on the performance page to evaluate precision/recall trade-offs.
Adjusting the probability threshold on the performance page directly addresses the precision/recall trade-off, letting you tune how confidently detections are accepted without retraining. This satisfies the diagnostic constraint: it reveals whether poor production performance stems from an ill-suited threshold rather than genuine model weakness, guiding whether retraining or recalibration is needed.
E
Manually edit model neural network weights via the REST API.
Why it fails: Custom Vision exposes training, prediction and iteration endpoints; no REST API permits editing neural network weights, which are learned internally during training. It is tempting because the REST API does allow programmatic control of projects, and it would be correct for automating training, publishing or exporting an iteration as a model.

Question 6hardmultiple choice

You are processing customer feedback using sentiment analysis in the Azure AI Language service. You need to extract finer-grained information about specific product attributes mentioned in the reviews (e.g., finding out that the screen is bright but the battery life is poor). Which feature should you enable in your API request?

Trap 1: PII detection

PII detection identifies and redacts personal data such as names and addresses; it returns no attribute-level sentiment, so it cannot link opinions to product features. It is tempting because it is a built-in Azure AI Language feature, and it would be correct when anonymising reviews before storage or analysis.

Trap 2: Language detection

Language detection only identifies the language of the input text; it returns a language code and confidence score, not attribute-level opinions. It is tempting because multilingual reviews genuinely require it before analysis, but opinion mining, not language detection, extracts per-aspect sentiment such as screen versus battery.

Trap 3: Custom text classification

Custom text classification assigns whole documents to user-defined labels; it does not return per-attribute sentiment, so it cannot separate screen praise from battery criticism. It is tempting because custom models handle domain-specific categories, and it would be correct when routing feedback into bespoke topic buckets.

A
Opinion mining
Opinion mining extends sentiment analysis by linking each detected sentiment to the specific target it describes, so 'screen' is scored positive while 'battery life' is scored negative. Plain sentiment analysis returns only document or sentence-level polarity.
B
PII detection
Why it fails: PII detection identifies and redacts personal data such as names and addresses; it returns no attribute-level sentiment, so it cannot link opinions to product features. It is tempting because it is a built-in Azure AI Language feature, and it would be correct when anonymising reviews before storage or analysis.
C
Language detection
Why it fails: Language detection only identifies the language of the input text; it returns a language code and confidence score, not attribute-level opinions. It is tempting because multilingual reviews genuinely require it before analysis, but opinion mining, not language detection, extracts per-aspect sentiment such as screen versus battery.
D
Custom text classification
Why it fails: Custom text classification assigns whole documents to user-defined labels; it does not return per-attribute sentiment, so it cannot separate screen praise from battery criticism. It is tempting because custom models handle domain-specific categories, and it would be correct when routing feedback into bespoke topic buckets.

Question 7hardmultiple choice

You are building an Azure AI Document Intelligence solution to process complex financial statements. Due to varying layouts across different financial institutions, you decide to use a custom neural model instead of a custom template model. What is a key architectural advantage of the custom neural model in this scenario?

Trap 1: It requires significantly fewer training documents than a template…

Custom neural models still require labelled samples, typically five or more per field, so they do not reduce training-document volume. The temptation is understandable because neural models generalise across layout variation, which is exactly why they suit this scenario — but that advantage is structural tolerance, not fewer training documents.

Trap 2: It can be trained entirely unsupervised without requiring any…

Custom neural models are supervised: they need human-labelled documents with tagged fields before training. The appeal is that neural models handle unseen layouts, which sounds like learning without labels, but layout generalisation is not unsupervised learning. In this scenario the model still depends on labelled financial statements.

Trap 3: It can extract data from scanned documents without running Optical…

Custom neural models still rely on OCR to convert scanned pages into machine-readable text before layout and semantic analysis; they differ from template models by learning layout patterns rather than requiring fixed anchor positions. The option is tempting because neural models tolerate varied layouts, but OCR remains a prerequisite for any Document Intelligence extraction.

A
It requires significantly fewer training documents than a template model to achieve high accuracy.
Why it fails: Custom neural models still require labelled samples, typically five or more per field, so they do not reduce training-document volume. The temptation is understandable because neural models generalise across layout variation, which is exactly why they suit this scenario — but that advantage is structural tolerance, not fewer training documents.
B
It can be trained entirely unsupervised without requiring any human-labeled training documents.
Why it fails: Custom neural models are supervised: they need human-labelled documents with tagged fields before training. The appeal is that neural models handle unseen layouts, which sounds like learning without labels, but layout generalisation is not unsupervised learning. In this scenario the model still depends on labelled financial statements.
C
It supports cross-page tables and varying visual layouts without requiring strict coordinate alignment.
Custom neural models use deep learning to handle variable layouts, cross-page tables and differing visual structures, so financial statements from different institutions need no fixed coordinate templates. This satisfies the varying-layout constraint that a custom template model, reliant on rigid positional alignment, cannot accommodate.
D
It can extract data from scanned documents without running Optical Character Recognition (OCR) first.
Why it fails: Custom neural models still rely on OCR to convert scanned pages into machine-readable text before layout and semantic analysis; they differ from template models by learning layout patterns rather than requiring fixed anchor positions. The option is tempting because neural models tolerate varied layouts, but OCR remains a prerequisite for any Document Intelligence extraction.

Question 8easymultiple choice

Your company processes business cards from international clients. Which prebuilt Azure AI Document Intelligence model should you use to extract names, company names, emails, and phone numbers from these cards?

Trap 1: prebuilt-invoice

prebuilt-invoice extracts invoice-specific fields such as vendor, invoice date, line items and totals; it does not model business-card fields like email or phone. It is the right choice for accounts-payable automation, whereas business cards require prebuilt-businessCard, which targets names, company, emails and phone numbers.

Trap 2: prebuilt-layout

prebuilt-layout returns tables, selection marks and text positions, not typed contact fields, so names, emails and phone numbers arrive unlabelled. Choose it for general document structure extraction; business cards need the dedicated prebuilt-businessCard model that outputs those fields directly.

Trap 3: prebuilt-receipt

prebuilt-receipt extracts merchant, totals, tax and line items from purchase receipts, so it returns no name, email or phone fields for a business card. It is the correct choice when processing retail receipts; cards require prebuilt-businessCard instead.

A
prebuilt-businessCard
The prebuilt-businessCard model is purpose-built to extract contact fields — names, company names, emails and phone numbers — from business card images. It satisfies the stem's requirement for a prebuilt model targeting business cards, avoiding the need to train a custom extraction model.
B
prebuilt-invoice
Why it fails: prebuilt-invoice extracts invoice-specific fields such as vendor, invoice date, line items and totals; it does not model business-card fields like email or phone. It is the right choice for accounts-payable automation, whereas business cards require prebuilt-businessCard, which targets names, company, emails and phone numbers.
C
prebuilt-layout
Why it fails: prebuilt-layout returns tables, selection marks and text positions, not typed contact fields, so names, emails and phone numbers arrive unlabelled. Choose it for general document structure extraction; business cards need the dedicated prebuilt-businessCard model that outputs those fields directly.
D
prebuilt-receipt
Why it fails: prebuilt-receipt extracts merchant, totals, tax and line items from purchase receipts, so it returns no name, email or phone fields for a business card. It is the correct choice when processing retail receipts; cards require prebuilt-businessCard instead.

Question 9hardmulti select

Your company's compliance mandate requires that all data processed by Azure AI Speech and Document Intelligence services remain encrypted using keys managed entirely by your organization. Which THREE configuration steps are required? Each correct answer presents part of the solution.

Trap 1: Store the private key as plain text in the application source code.

Plain-text source code exposes the key to anyone with repository access, defeating the mandate that the organisation solely manages it. It is tempting because the application must reference the key somehow, and that would be correct only when using a secure store such as Azure Key Vault rather than embedding the value directly.

Trap 2: Disable all diagnostic logging across all Azure subscriptions.

Diagnostic logging controls telemetry retention, not encryption of processed data, so disabling it neither enables nor affects customer-managed keys. It is tempting because reducing logging limits data exposure and supports privacy compliance, and that would be the correct measure when the requirement is minimising stored diagnostic data rather than key ownership.

A
Assign appropriate permissions for the AI service managed identity to access the Key Vault key.
The AI service's managed identity must hold Key Vault permissions (such as get, wrapKey, unwrapKey) so the service can reach the customer-managed key. Without this role assignment, encryption with your own key fails authorisation, breaking the compliance mandate.
B
Store the private key as plain text in the application source code.
Why it fails: Plain-text source code exposes the key to anyone with repository access, defeating the mandate that the organisation solely manages it. It is tempting because the application must reference the key somehow, and that would be correct only when using a secure store such as Azure Key Vault rather than embedding the value directly.
C
Create an Azure Key Vault and enable soft-delete and purge protection.
Soft-delete and purge protection safeguard the Key Vault and its keys against accidental or malicious deletion, preserving recoverability. Because customer-managed encryption depends on key availability, this resilience step is required to satisfy the compliance mandate.
D
Configure the customer-managed key (CMK) identifier on the Azure AI services account properties.
Setting the customer-managed key identifier on the Azure AI services account switches encryption from Microsoft-managed keys to your Key Vault key. This property is what actually enforces organisation-controlled encryption for Speech and Document Intelligence data.
E
Disable all diagnostic logging across all Azure subscriptions.
Why it fails: Diagnostic logging controls telemetry retention, not encryption of processed data, so disabling it neither enables nor affects customer-managed keys. It is tempting because reducing logging limits data exposure and supports privacy compliance, and that would be the correct measure when the requirement is minimising stored diagnostic data rather than key ownership.

Question 10hardmulti select

Which THREE features are provided by the Azure AI Foundry evaluation service?

Trap 1: Automated model fine-tuning based on failures

Evaluation reports quality and safety metrics; it does not retrain or fine-tune models from failed results. It is tempting because evaluation output can inform later tuning, but fine-tuning is a separate Foundry capability triggered manually, not an evaluation-service feature.

Trap 2: Automatic user interface generation

Evaluation service scores model outputs for groundedness, relevance, fluency and similarity; it never generates user interfaces. It is tempting because Foundry can deploy models behind a chat UI, but UI scaffolding belongs to app development tooling, not the evaluation metrics pipeline.

A
Visualization of evaluation results
Evaluation runs surface results through portal charts and comparison views, letting teams inspect metric scores across runs and models. This satisfies the stem's requirement for native result presentation within the Azure AI Foundry evaluation experience.
B
Built-in metrics for RAG (e.g., coherence, fluency)
Built-in RAG metrics such as coherence and fluency are computed directly by the Azure AI Foundry evaluation service, satisfying the stem's requirement for provided features. These groundedness, relevance and fluency scorers assess retrieval-augmented generation outputs without custom code, letting teams quantify response quality against the evaluation service's native metric set.
C
Automated model fine-tuning based on failures
Why it fails: Evaluation reports quality and safety metrics; it does not retrain or fine-tune models from failed results. It is tempting because evaluation output can inform later tuning, but fine-tuning is a separate Foundry capability triggered manually, not an evaluation-service feature.
D
Custom evaluation code integration
Custom evaluation code integration lets teams plug bespoke scoring logic into Azure AI Foundry's evaluation runs, satisfying the requirement for extensible, scenario-specific metrics beyond built-in evaluators. This capability is genuinely part of the evaluation service, so it counts among the three features the question demands.
E
Automatic user interface generation
Why it fails: Evaluation service scores model outputs for groundedness, relevance, fluency and similarity; it never generates user interfaces. It is tempting because Foundry can deploy models behind a chat UI, but UI scaffolding belongs to app development tooling, not the evaluation metrics pipeline.

Question 11easymultiple choice

You are building an application that analyzes user feedback. You need to detect instances where users share their phone numbers, email addresses, and credit card numbers so that you can automatically redact them. Which feature should you use?

Trap 1: Sentiment analysis

Sentiment analysis scores opinion polarity and subjectivity in text; it cannot identify or extract phone numbers, email addresses or credit card numbers, so nothing can be redacted. It is tempting because it also processes user feedback, and it would be the right choice when the goal is gauging whether comments are positive or negative rather than locating PII entities.

Trap 2: Language detection

Language detection identifies which language a document is written in; it returns a locale code and performs no extraction of sensitive data. It would be the correct choice when routing or translating content by language. Detecting and redacting phone numbers, emails and card numbers requires PII detection.

Trap 3: Named Entity Recognition (NER)

Standard NER extracts general entities like people and locations, not specifically for secure PII redaction.

A
Sentiment analysis
Why it fails: Sentiment analysis scores opinion polarity and subjectivity in text; it cannot identify or extract phone numbers, email addresses or credit card numbers, so nothing can be redacted. It is tempting because it also processes user feedback, and it would be the right choice when the goal is gauging whether comments are positive or negative rather than locating PII entities.
B
Language detection
Why it fails: Language detection identifies which language a document is written in; it returns a locale code and performs no extraction of sensitive data. It would be the correct choice when routing or translating content by language. Detecting and redacting phone numbers, emails and card numbers requires PII detection.
C
Named Entity Recognition (NER)
Why it fails: Standard NER extracts general entities like people and locations, not specifically for secure PII redaction.
D
PII detection
PII detection identifies and returns entities such as phone numbers, email addresses and credit card numbers, with optional redaction masking in the response. This directly satisfies the requirement to detect and automatically redact those specific data types from user feedback.

Question 12mediummultiple choice

You are deploying an Azure OpenAI GPT-4 model in a region experiencing high demand, and you need to guarantee a dedicated throughput level without contending with other tenants. Which deployment type should you select?

Trap 1: Serverless deployment

Serverless deployments draw from shared regional capacity, so throughput fluctuates with other tenants' demand and offers no guaranteed allocation. Provisioned throughput is the deployment type that reserves dedicated capacity. Serverless suits variable, low-volume workloads where per-token billing and pay-as-you-go elasticity matter more than consistent latency.

Trap 2: Standard deployment

Standard deployment draws on shared regional capacity, so during high demand throughput varies with other tenants and no dedicated level is guaranteed. Standard is tempting as the default low-configuration choice, and would fit variable, non-critical workloads, but not a guaranteed-throughput requirement.

Trap 3: Batch deployment

Batch deployment targets asynchronous, large-volume jobs processed within a longer window at discounted rates; it provides no interactive dedicated throughput guarantee. Batch is tempting for cost savings on bulk processing, but it cannot satisfy a real-time dedicated capacity requirement.

A
Serverless deployment
Why it fails: Serverless deployments draw from shared regional capacity, so throughput fluctuates with other tenants' demand and offers no guaranteed allocation. Provisioned throughput is the deployment type that reserves dedicated capacity. Serverless suits variable, low-volume workloads where per-token billing and pay-as-you-go elasticity matter more than consistent latency.
B
Standard deployment
Why it fails: Standard deployment draws on shared regional capacity, so during high demand throughput varies with other tenants and no dedicated level is guaranteed. Standard is tempting as the default low-configuration choice, and would fit variable, non-critical workloads, but not a guaranteed-throughput requirement.
C
Provisioned (PTU) deployment
Provisioned throughput units reserve dedicated model capacity for your deployment, guaranteeing a fixed throughput level that is not shared with other tenants. This removes the contention and variable latency inherent in standard pay-as-you-go deployments during periods of high regional demand.
D
Batch deployment
Why it fails: Batch deployment targets asynchronous, large-volume jobs processed within a longer window at discounted rates; it provides no interactive dedicated throughput guarantee. Batch is tempting for cost savings on bulk processing, but it cannot satisfy a real-time dedicated capacity requirement.

Question 13hardmulti select

You are deploying an enterprise RAG application in Azure AI Foundry. You need to ensure data security and compliance across all components. Which THREE security practices should you implement? (Choose THREE)

Trap 1: Grant anonymous public network access on all AI service firewalls

Anonymous public access exposes the AI service endpoints to unauthenticated traffic, directly violating the data security and compliance requirement. Private endpoints with network restrictions are the correct control; public anonymous access suits only non-sensitive demos where no confidential data or regulatory scope applies.

Trap 2: Store API keys in plain text configuration files committed to…

Plain-text keys in public repositories leak credentials to anyone, breaching the compliance requirement outright. Secrets belong in Azure Key Vault with managed identity authentication. Committing keys to a repo is tempting for quick local prototyping, but never for an enterprise RAG deployment handling sensitive data.

A
Use Managed Identities with Azure RBAC for service-to-service authentication
Managed Identities eliminate stored credentials by issuing Microsoft Entra ID tokens that Azure RBAC then authorises, so service-to-service calls between Foundry, Azure OpenAI and Azure AI Search avoid secrets in code or config — directly satisfying the compliance requirement for credential-free authentication.
B
Grant anonymous public network access on all AI service firewalls
Why it fails: Anonymous public access exposes the AI service endpoints to unauthenticated traffic, directly violating the data security and compliance requirement. Private endpoints with network restrictions are the correct control; public anonymous access suits only non-sensitive demos where no confidential data or regulatory scope applies.
C
Configure Azure Private Endpoints for Azure OpenAI and Azure AI Search
Private Endpoints assign private IP addresses from your virtual network to Azure OpenAI and Azure AI Search, removing public internet exposure of inference and index traffic. This satisfies the compliance constraint by keeping data on the Microsoft backbone and blocking exfiltration via public endpoints.
D
Store API keys in plain text configuration files committed to public GitHub repositories
Why it fails: Plain-text keys in public repositories leak credentials to anyone, breaching the compliance requirement outright. Secrets belong in Azure Key Vault with managed identity authentication. Committing keys to a repo is tempting for quick local prototyping, but never for an enterprise RAG deployment handling sensitive data.
E
Implement Customer-Managed Keys (CMK) via Azure Key Vault for data encryption at rest
Customer-Managed Keys stored in Azure Key Vault replace Microsoft-managed keys for encryption at rest, giving your organisation sole control over the key lifecycle and revocation. This meets the compliance requirement that sensitive RAG data, including indexes and model artefacts, be encrypted under tenant-governed keys.

Question 14mediummulti select

You are configuring prompt engineering practices for a generative AI application in Azure AI Foundry. Which THREE practices should you follow to ensure high output quality and reliability? (Choose three.)

Trap 1: Embed all system instructions inside the user prompt string without…

Folding system instructions into the user turn removes the separate system role that Foundry models weight most strongly for persistent behavioural rules, weakening instruction adherence across turns. It tempts as a single-message shortcut, yet the system role exists precisely to hold durable instructions apart from per-request user content.

Trap 2: Rely entirely on vague, implicit instructions to give the model…

Vague instructions give the model no measurable criteria, producing inconsistent tone, format and factual grounding across runs. It tempts because open-ended prompts can yield creative variety, but reliability requires explicit task definition, constraints and examples, which this practice omits entirely.

A
Specify the desired output format explicitly (e.g., JSON schema or markdown tables).
Declaring an explicit output format constrains generation to a defined structure, such as a JSON schema or markdown table, which directly satisfies the stem's demand for reliable, high-quality output. Without it, the model chooses its own layout, producing inconsistent, harder-to-parse responses.
B
Embed all system instructions inside the user prompt string without using system roles.
Why it fails: Folding system instructions into the user turn removes the separate system role that Foundry models weight most strongly for persistent behavioural rules, weakening instruction adherence across turns. It tempts as a single-message shortcut, yet the system role exists precisely to hold durable instructions apart from per-request user content.
C
Rely entirely on vague, implicit instructions to give the model creative freedom.
Why it fails: Vague instructions give the model no measurable criteria, producing inconsistent tone, format and factual grounding across runs. It tempts because open-ended prompts can yield creative variety, but reliability requires explicit task definition, constraints and examples, which this practice omits entirely.
D
Use delimiters such as triple backticks or XML tags to clearly separate instructions from user-provided data.
Delimiters such as triple backticks or XML tags create an unambiguous boundary between system instructions and untrusted user input, satisfying the reliability requirement. This separation prevents injected text inside user data from being interpreted as instructions, reducing prompt injection and instruction drift.
E
Incorporate few-shot examples of edge cases and expected behaviors.
Few-shot examples showing edge cases and expected behaviours condition the model on concrete input-output pairs, satisfying the stem's reliability requirement. Demonstrating boundary handling in-context steers the model toward consistent responses for similar inputs, which zero-shot instructions alone cannot reliably achieve.

Question 15mediummultiple choice

You need to extract information from a business card. Which prebuilt model should you select?

Trap 1: prebuilt-taxDocument

prebuilt-taxDocument targets US tax forms such as W-2 and 1099, returning fields like employer identification number and wages, none of which appear on a business card. It is correct when automating tax-form processing, where its trained schema matches those specific form layouts.

Trap 2: prebuilt-idDocument

prebuilt-idDocument extracts fields from passports, driving licences and similar identity documents, not contact details from business cards. It is the right selection when processing identity verification documents, where its trained field set covers document number, date of birth and expiry rather than name, company, email and phone.

Trap 3: prebuilt-layout

prebuilt-layout returns only structural elements — text, tables, selection marks and their coordinates — without extracting named contact fields, so it cannot directly yield a business card's name, email or phone. It is correct when you need raw OCR structure and will map fields yourself.

A
prebuilt-businessCard
The prebuilt-businessCard model is trained specifically to extract fields such as contact names, job titles, company names, email addresses, and phone numbers from business card images, returning structured JSON. General document or receipt models lack these card-specific field schemas.
B
prebuilt-taxDocument
Why it fails: prebuilt-taxDocument targets US tax forms such as W-2 and 1099, returning fields like employer identification number and wages, none of which appear on a business card. It is correct when automating tax-form processing, where its trained schema matches those specific form layouts.
C
prebuilt-idDocument
Why it fails: prebuilt-idDocument extracts fields from passports, driving licences and similar identity documents, not contact details from business cards. It is the right selection when processing identity verification documents, where its trained field set covers document number, date of birth and expiry rather than name, company, email and phone.
D
prebuilt-layout
Why it fails: prebuilt-layout returns only structural elements — text, tables, selection marks and their coordinates — without extracting named contact fields, so it cannot directly yield a business card's name, email or phone. It is correct when you need raw OCR structure and will map fields yourself.

Question 16mediummulti select

You are troubleshooting a scenario where client applications are unable to connect to an Azure AI Language resource secured by a Private Endpoint. Which TWO troubleshooting steps should you perform? Each correct answer presents part of the solution.

Trap 1: Verify that the client application has been assigned the Storage…

Storage Blob Data Contributor governs Blob Storage data-plane access, not Azure AI Language connectivity through a Private Endpoint. It is tempting because role assignments commonly cause authorisation failures, and this role would be correct when an application must read or write blobs in a storage account.

Trap 2: Ensure that the Azure OpenAI model weights have been retrained.

Retraining Azure OpenAI model weights has no bearing on Private Endpoint connectivity; the failure is network-path related, not model quality. It is tempting because retraining addresses accuracy degradation in deployed models, which would be the right action when predictions drift — not when clients cannot reach the resource at all.

Trap 3: Check that public network access is set to enabled and unrestricted.

Enabling unrestricted public access contradicts the Private Endpoint design, which routes traffic privately; the fix lies in private DNS resolution and subnet configuration. It tempts because public access restores connectivity when private DNS zones are misconfigured, but that bypasses the intended private-only posture.

A
Check that the client subnet can route to the private IP address assigned to the Private Endpoint.
A Private Endpoint maps the service to a private IP inside the virtual network, so the client subnet must have a valid route to that address. Missing or misconfigured routing, such as an overriding UDR or peering gap, blocks connectivity regardless of DNS.
B
Verify that the client application has been assigned the Storage Blob Data Contributor role.
Why it fails: Storage Blob Data Contributor governs Blob Storage data-plane access, not Azure AI Language connectivity through a Private Endpoint. It is tempting because role assignments commonly cause authorisation failures, and this role would be correct when an application must read or write blobs in a storage account.
C
Ensure that the Azure OpenAI model weights have been retrained.
Why it fails: Retraining Azure OpenAI model weights has no bearing on Private Endpoint connectivity; the failure is network-path related, not model quality. It is tempting because retraining addresses accuracy degradation in deployed models, which would be the right action when predictions drift — not when clients cannot reach the resource at all.
D
Verify that the Private DNS zone is correctly linked to the client virtual network.
Name resolution must return the Private Endpoint's private IP rather than the public endpoint. If the Private DNS zone is not linked to the client virtual network, clients resolve the public address and the connection fails despite correct routing.
E
Check that public network access is set to enabled and unrestricted.
Why it fails: Enabling unrestricted public access contradicts the Private Endpoint design, which routes traffic privately; the fix lies in private DNS resolution and subnet configuration. It tempts because public access restores connectivity when private DNS zones are misconfigured, but that bypasses the intended private-only posture.

Question 17mediummulti select

When designing an Azure AI Foundry project architecture, which TWO resources are typically linked to the Azure AI Hub to enable full model deployment and search capabilities? (Choose TWO)

Trap 1: Azure SQL Database relational server

Azure SQL Database provides relational storage, not the vector index or model hosting an AI Hub links for deployment and search. It tempts architects needing structured metadata or conversation logging alongside AI workloads, where SQL is the right store, but the hub instead connects Azure OpenAI and Azure AI Search resources.

Trap 2: Azure Stream Analytics job cluster

Stream Analytics performs real-time stream processing, supplying neither model deployment endpoints nor vector search indexes to an AI Hub. It tempts when telemetry or event streams must feed the AI pipeline, where Stream Analytics is the correct ingestion choice, but hub linkage requires Azure OpenAI and Azure AI Search.

Trap 3: Power BI embedded analytics workspace

Power BI embedded workspaces deliver reports and dashboards, offering no model hosting or search indexing for an AI Hub. It tempts when the project must surface analytics visually, where Power BI is the right tool, but hub-linked resources for deployment and search are Azure OpenAI and Azure AI Search.

A
Azure AI Search service
Azure AI Search provides the vector and keyword indexing that grounds models in your own data. Linking it to the Azure AI Hub satisfies the search capability requirement, enabling retrieval-augmented generation and agent knowledge tools within the Foundry project.
B
Azure SQL Database relational server
Why it fails: Azure SQL Database provides relational storage, not the vector index or model hosting an AI Hub links for deployment and search. It tempts architects needing structured metadata or conversation logging alongside AI workloads, where SQL is the right store, but the hub instead connects Azure OpenAI and Azure AI Search resources.
C
Azure OpenAI service
Azure OpenAI supplies the deployed models that power inference and agent reasoning. Linking it to the Azure AI Hub satisfies the model deployment requirement, giving the Foundry project access to GPT and embedding deployments for building and orchestrating agents.
D
Azure Stream Analytics job cluster
Why it fails: Stream Analytics performs real-time stream processing, supplying neither model deployment endpoints nor vector search indexes to an AI Hub. It tempts when telemetry or event streams must feed the AI pipeline, where Stream Analytics is the correct ingestion choice, but hub linkage requires Azure OpenAI and Azure AI Search.
E
Power BI embedded analytics workspace
Why it fails: Power BI embedded workspaces deliver reports and dashboards, offering no model hosting or search indexing for an AI Hub. It tempts when the project must surface analytics visually, where Power BI is the right tool, but hub-linked resources for deployment and search are Azure OpenAI and Azure AI Search.

Question 18easymultiple choice

You are managing prompt assets in Azure AI Foundry. Your team collaborates on developing, testing, and versioning system prompts. Which feature in Azure AI Foundry should you use to store and manage these prompt templates?

Trap 1: Azure Storage Blob lifecycle management policies

Blob lifecycle policies transition or delete stored objects on an age schedule; they provide no prompt template editing, comparison, or version history. It is tempting because blobs can hold prompt text, but Azure AI Foundry's prompt flow or prompt asset versioning feature is what supports collaborative development, testing, and versioning of system prompts.

Trap 2: Azure App Service deployment slots

App Service deployment slots host parallel web app instances for staged swaps; they store no prompt templates and offer no prompt version history or comparison. It is tempting because slots support safe release testing, but managing and versioning system prompts requires Azure AI Foundry's prompt asset or prompt flow versioning capability.

Trap 3: Azure Key Vault secret versions

Key Vault secret versioning tracks rotations of credentials and other sensitive values, not prompt template content, and it offers no editing or evaluation workflow. It is tempting because prompts may contain secrets, but storing and versioning system prompts for team collaboration requires Azure AI Foundry's prompt asset management feature.

A
Azure Storage Blob lifecycle management policies
Why it fails: Blob lifecycle policies transition or delete stored objects on an age schedule; they provide no prompt template editing, comparison, or version history. It is tempting because blobs can hold prompt text, but Azure AI Foundry's prompt flow or prompt asset versioning feature is what supports collaborative development, testing, and versioning of system prompts.
B
Prompt flow / Prompt management workspace assets
Prompt flow provides workspace assets purpose-built for authoring, testing, and versioning prompt templates within Azure AI Foundry. It satisfies the collaboration and versioning constraint by centralising prompt storage, letting teams iterate on system prompts as managed, reusable artefacts rather than ad hoc strings.
C
Azure App Service deployment slots
Why it fails: App Service deployment slots host parallel web app instances for staged swaps; they store no prompt templates and offer no prompt version history or comparison. It is tempting because slots support safe release testing, but managing and versioning system prompts requires Azure AI Foundry's prompt asset or prompt flow versioning capability.
D
Azure Key Vault secret versions
Why it fails: Key Vault secret versioning tracks rotations of credentials and other sensitive values, not prompt template content, and it offers no editing or evaluation workflow. It is tempting because prompts may contain secrets, but storing and versioning system prompts for team collaboration requires Azure AI Foundry's prompt asset management feature.

Question 19mediummulti select

When configuring role-based access control (RBAC) in Azure AI Foundry and Azure OpenAI, which TWO built-in Azure roles are commonly assigned to developers and services? (Choose TWO)

Trap 1: Storage Blob Data Owner

Storage Blob Data Owner grants full control over blob containers, which does not authorise invoking models or managing Foundry resources. It is tempting because Foundry projects store artefacts in storage accounts, and it would be correct for a service reading or writing training data directly.

Trap 2: Virtual Machine Contributor

Virtual Machine Contributor manages virtual machines, which are not the resource type being secured for model inference. It is tempting because Foundry hubs can attach compute, and it would be correct for an administrator provisioning or maintaining VM-based compute infrastructure.

Trap 3: Network Contributor

Network Contributor manages virtual networks and related connectivity, granting no permission to call Azure OpenAI deployments. It is tempting because private endpoints and networking are part of secure Foundry deployments, and it would be correct for an engineer configuring those network resources.

A
Storage Blob Data Owner
Why it fails: Storage Blob Data Owner grants full control over blob containers, which does not authorise invoking models or managing Foundry resources. It is tempting because Foundry projects store artefacts in storage accounts, and it would be correct for a service reading or writing training data directly.
B
Cognitive Services OpenAI User
Cognitive Services OpenAI User grants data-plane access for calling Azure OpenAI models, inference and completions, without permitting key or account management. It satisfies the stem's requirement for a built-in role assigned to developers and services needing model invocation, complementing the control-plane Cognitive Services OpenAI Contributor role.
C
Virtual Machine Contributor
Why it fails: Virtual Machine Contributor manages virtual machines, which are not the resource type being secured for model inference. It is tempting because Foundry hubs can attach compute, and it would be correct for an administrator provisioning or maintaining VM-based compute infrastructure.
D
Network Contributor
Why it fails: Network Contributor manages virtual networks and related connectivity, granting no permission to call Azure OpenAI deployments. It is tempting because private endpoints and networking are part of secure Foundry deployments, and it would be correct for an engineer configuring those network resources.
E
Azure AI Developer
Azure AI Developer grants data-plane access to build, train and deploy AI projects in Azure AI Foundry without permitting resource management, satisfying the least-privilege requirement for developers. It pairs with Cognitive Services OpenAI User, which supplies inference access to Azure OpenAI models, covering both the Foundry and Azure OpenAI halves of the stem.

Question 20hardmultiple choice

You are designing a RAG solution in Azure AI Foundry where sensitive enterprise documents must be retrieved. Users should only see search results corresponding to their security clearance level. How should you implement document-level access control in Azure AI Search?

Trap 1: Configure Microsoft Entra ID authentication on the Azure OpenAI…

Authenticating the Azure OpenAI endpoint governs who may call the model, not which documents Azure AI Search returns; retrieval filtering happens at query time in the index. It is tempting because Entra ID is the right identity plane for the solution, but the security filters and RBAC scopes must be applied to the search index itself.

Trap 2: Encrypt the search index using customer-managed keys (CMK) in Azure…

Customer-managed keys encrypt data at rest, protecting the index from storage-level disclosure; they do not filter results per user, so every clearance level still retrieves every document. CMK is correct for regulatory encryption and key-rotation requirements, not for enforcing document-level authorisation during search.

Trap 3: Use Azure AI Content Safety to redact sensitive keywords before…

Content Safety redacts keywords during indexing, altering document content rather than restricting which documents a given user may retrieve; a low-clearance user still receives high-clearance results. It suits sanitising harmful or PII text, not clearance-based filtering, which requires security filters mapped to user identity.

A
Store user security groups in document metadata and apply OData filter expressions during search queries
Storing group identifiers in document metadata and filtering with OData expressions lets Azure AI Search return only documents matching the caller's clearance. The filter is applied at query time, enforcing document-level access control within the RAG retrieval step.
B
Configure Microsoft Entra ID authentication on the Azure OpenAI endpoint
Why it fails: Authenticating the Azure OpenAI endpoint governs who may call the model, not which documents Azure AI Search returns; retrieval filtering happens at query time in the index. It is tempting because Entra ID is the right identity plane for the solution, but the security filters and RBAC scopes must be applied to the search index itself.
C
Encrypt the search index using customer-managed keys (CMK) in Azure Key Vault
Why it fails: Customer-managed keys encrypt data at rest, protecting the index from storage-level disclosure; they do not filter results per user, so every clearance level still retrieves every document. CMK is correct for regulatory encryption and key-rotation requirements, not for enforcing document-level authorisation during search.
D
Use Azure AI Content Safety to redact sensitive keywords before indexing
Why it fails: Content Safety redacts keywords during indexing, altering document content rather than restricting which documents a given user may retrieve; a low-clearance user still receives high-clearance results. It suits sanitising harmful or PII text, not clearance-based filtering, which requires security filters mapped to user identity.