Refer to the Exhibit Practice Questions

Remove the customSubDomainName property.

Why it fails: Removing customSubDomainName does not alter network ACL evaluation, so the on-premises application remains blocked. It is tempting because the custom subdomain relates to endpoint naming, and it would be correct when a token or endpoint URL fails due to an incorrect subdomain, not a firewall rule.

Set the defaultAction to Allow.

Why it fails: Setting defaultAction to Allow opens the firewall to all networks, defeating the network ACL restriction the template applies; the on-premises address range must instead be added to the allowed list. It is tempting because it does grant access, and it would be correct only when the resource should be reachable from every network.

Change the SKU to F0 to allow public access.

Why it fails: The F0 free tier still enforces the same network ACL rules, so changing SKU does not grant the on-premises application access. It is tempting because F0 is associated with public endpoints, and it would be correct when testing with a free-tier key rather than resolving connectivity.

The kbId is not published.

Why it fails: The error is more likely due to the endpoint.

The skill is not deployed.

Why it fails: The configuration file suggests the skill is configured but not connecting.

The endpointKey is incorrect.

Why it fails: While possible, the more fundamental issue is the modelUrl.

The output variable 'sentimentResult' is not defined

Why it fails: An undefined output variable surfaces as an expression or activity evaluation error naming the variable, not BadRequest, which the Azure AI services activity returns for invalid request payloads such as malformed input or exceeded limits. It is tempting because variable definition errors are common in pipelines, and defining the variable would be correct when the error cites it.

The activity type should be 'AzureFunction'

Why it fails: Sentiment analysis is a Cognitive Services skill invoked through the Azure AI Language linked service, not an Azure Function activity, which runs custom code rather than the built-in text analytics endpoint. AzureFunction suits bespoke scoring logic the pipeline must execute itself, where no prebuilt cognitive skill exists.

The linked service name is misspelled

Why it fails: A misspelled linked service name produces a linked service not found or authorisation error, not BadRequest, because the pipeline cannot resolve the connection before the service call. It is tempting because linked service misconfiguration is a common Data Factory failure, and correcting the name would be the fix when the error names the missing linked service.

Create an Azure Container Registry and push the Custom Vision base image.

Why it fails: The Custom Vision base image is irrelevant here; the exported model must be packaged as an IoT Edge module image, which requires exporting the published iteration as a Dockerfile first. It tempts because container registries are involved, but that step is correct only after the model export exists.

Use the Custom Vision prediction API to call the published endpoint from the edge device.

Why it fails: The prediction API requires network connectivity to the cloud endpoint, which defeats the on-premises inference requirement. It is tempting because the API is the standard way to consume a published Custom Vision model, and would be correct for cloud-hosted or internet-connected clients rather than an IoT Edge module.

Retrain the model with more images to improve mAP.

Why it fails: Retraining with more images targets overall mean average precision, not the export and containerisation steps the deployment requires, so the on-premises inference goal stays unmet. It tempts because accuracy improvements feel preparatory, but it is the right choice only when detection quality itself is the blocker.

To define the response the bot sends

Why it fails: Triggers specify the phrases or events that start a topic, not the bot's reply; the message node handles responses. Defining replies here is tempting because topics visually pair triggers with responses, but a trigger's condition merely launches the conversation flow before any message is sent.

To define the authentication method

Why it fails: Triggers match user utterances or events to launch a topic; authentication is configured separately in the bot's security settings. Choosing this is tempting because triggers do run before a topic executes, yet they carry no credential or identity-provider configuration, so they cannot select an auth method.

To define the entities to extract

Why it fails: Triggers specify the phrases or events that start a topic, not entity extraction. It is tempting because triggers and entities both appear in topic authoring, and defining entities would be correct when capturing structured values such as dates or order numbers from user utterances.

Decrease the batch size to 5

Why it fails: Batch size governs how many documents are processed per invocation, not whether a failing document aborts the run; smaller batches still stop at the same errors. Tuning batch size suits throttling or memory pressure scenarios, not error tolerance.

Increase batch size to 20

Why it fails: A larger batch means more documents per invocation, so more failures accumulate before the indexer aborts; it does not skip bad documents. Larger batches suit high-throughput indexing of clean, well-formed content where errors are rare.

Remove the schedule to run the indexer on demand

Why it fails: Removing the schedule changes when the indexer runs, not how it handles failing documents; it will still halt on the same errors. On-demand execution suits ad-hoc reindexing after content changes, not fault tolerance during a run.

The script uses the wrong HTTP method; it should use GET.

Why it fails: Azure OpenAI chat completions require POST; a GET returns 405 Method Not Allowed, not an authentication error. It tempts because GET is used for read-style REST calls, so it appears reasonable when the script merely retrieves a completion response.

The API version is incorrect.

Why it fails: An invalid api-version returns 404 or 400 errors about the version, not an authentication failure. It tempts because the api-version query parameter is mandatory and visibly present in the URL, making it an easy suspect when the call is rejected.

The endpoint URI is missing the resource name.

Why it fails: Authentication failures stem from the key or token, not the endpoint path; a malformed URI yields a 404 or DNS error instead. It tempts because the resource name does appear in the endpoint, so omitting it looks like a plausible cause of any request rejection.

Organization

Why it fails: Named Entity Recognition classifies Seattle as a Location, not an Organization, because the model distinguishes geographic entities from corporate or institutional names. It is tempting since organisations are frequently extracted entities, and that label would be correct for a company name such as Microsoft appearing in the same document.

Person

Why it fails: "Seattle" is a Location entity, not a Person; NER classifies place names under Location/Geography. Person is tempting because it captures human names, which is the correct type when the extracted text is an individual's name such as "Satya Nadella".

City

Why it fails: The API's entity taxonomy uses Location for cities; City is not a returned category, so the label cannot be selected. It is tempting because Seattle is indeed a city, and a finer-grained geographic label would be correct if the model exposed city-level subtypes rather than the broader Location type.

The model version is not specified and will default to the latest.

Why it fails: Standard deployments require an explicit model version at creation; there is no automatic default to the latest version, and the version stays fixed until changed. It is tempting because some Azure services auto-update to the newest model, but Azure OpenAI pins the version you specify.

Content filtering is disabled for this deployment.

Why it fails: Standard scale type governs throughput and latency, not content filtering; filters stay enabled by default. It is tempting because scale types do affect deployment behaviour, and content filtering can be configured separately in Azure OpenAI, but that setting is independent of the Standard scale type.

The deployment uses provisioned throughput with reserved capacity.

Why it fails: Standard scale type bills per token with pay-as-you-go quota, not reserved capacity; provisioned throughput is the separate Provisioned scale type. It is tempting because reserved capacity guarantees consistent latency for high-volume production workloads, which is precisely when Provisioned, not Standard, is chosen.

Fine-tune the model on safe code examples.

Why it fails: Fine-tuning adjusts model weights for task behaviour, not safety enforcement; harmful output persists because content filtering operates outside the model. It is tempting because fine-tuning on safe examples shapes style and domain responses, and would be correct when adapting tone or format for a specific application.

Lower the temperature parameter to 0.

Why it fails: Temperature controls sampling randomness, not policy compliance; at zero the model still generates harmful code deterministically. It is tempting because low temperature improves factual consistency and reproducibility, and would be correct when the problem is erratic or creative output rather than unsafe content.

Add more examples to the prompt.

Why it fails: Adding prompt examples is still prompt-level guidance, which the model can override; it does not enforce blocking of harmful content. It is tempting because few-shot examples reliably steer output format and task accuracy, and would be the right approach when improving consistency on benign classification or extraction tasks.

Date

Why it fails: If the exhibit shows the Date entity already meeting its accuracy or confidence threshold, adding labelled examples there wastes effort. The entity with the lowest scores needs more data. Date is tempting because dates appear frequently in documents, but frequency alone does not indicate poor model performance.

OrderNumber

Why it fails: If the exhibit shows OrderNumber already achieving acceptable precision, recall or confidence, extra labelled examples there will not lift overall model quality. The weakest entity needs the data. OrderNumber is tempting because it is a structured, high-value field, but strong existing scores rule it out.

All entities need improvement.

Why it fails: Adding labelled examples to every entity dilutes effort when the exhibit shows some entities already meeting their thresholds. Only the lowest-scoring entity needs more data. This option is tempting as a safe catch-all, but it ignores the exhibit's per-entity metrics that identify the actual weak point.

To extract named entities from the text without linking.

Why it fails: Named entity recognition returns entity categories such as Person or Organisation without disambiguating which real-world entity each mention denotes. Entity linking is tempting to confuse with it because both detect entities, but linking additionally returns a Wikipedia URL and ID resolving the mention to one specific entity.

To extract key phrases from the text.

Why it fails: Key phrase extraction returns the main talking points in a document, not disambiguated entity references. It is tempting because it uses the same Azure AI Language resource and text input, but the response is a list of significant phrases, whereas entity linking returns entity mentions matched to Wikipedia entries.

To analyze the sentiment of the text.

Why it fails: Sentiment analysis returns a positive, neutral or negative score for the document; entity linking instead resolves recognised entity mentions to Wikipedia knowledge-base entries. Sentiment is tempting because it shares the same Text Analytics endpoint and request shape, but the response contains confidence scores per sentence, not linked entity URLs.

The system message explicitly prohibits making up information, which is correct behavior.

Why it fails: Instructing the model not to fabricate is standard grounding practice and prevents hallucination; it does not cause refusals. The actual fault is a system message that is too restrictive, such as demanding citations or forbidding answers when context is incomplete.

The system message does not include instructions to use the provided data.

Why it fails: A system message without grounding instructions leaves the model relying on its own priors, so it declines in-scope questions. It is tempting because system messages are the correct place for behavioural constraints, but the failing requirement here is directing the model to answer from the supplied data.

The temperature parameter is set too high, causing the model to hallucinate.

Why it fails: Temperature controls randomness of token selection, so a high value yields varied or creative wording, not refusals. The reported behaviour is the model declining to answer, which stems from overly restrictive system-message instructions rather than sampling parameters.

The OCR step is not recognizing table cells.

Why it fails: OCR extracts characters and their coordinates; the layout model's table-detection logic infers rows and columns from those coordinates, so OCR cannot recognise cells as such. Cell recognition is a layout-model capability, relevant only when choosing a model that returns structured table cells rather than raw text lines.

The table extraction step is misconfigured.

Why it fails: The layout model performs table extraction internally with no separate configurable step, so nothing exists to misconfigure. A distinct extraction step appears in custom models, where you train and configure field extraction — the correct route when the built-in layout output does not meet your schema needs.

The output field mapping for tables is missing.

Why it fails: The layout model returns tables automatically; no output field mapping exists to omit, so a missing mapping cannot empty the array. Field mapping belongs to custom extraction models, where you map labelled fields to schema properties — the right approach when building a bespoke model, not when reading a document's inherent table structure.

https://mytextanalytics.cognitiveservices.azure.com/sentiment/v3.1

Why it fails: The path /sentiment/v3.1 does not exist on the Text Analytics REST API; the operation is exposed as /text/analytics/v3.1/sentiment. It is tempting because the host is correct and the version and operation names appear, but the segment order is wrong, so the call returns 404.

https://mytextanalytics.api.cognitive.microsoft.com/text/analytics/v3.1/sentiment

Why it fails: The regional endpoint uses the api.cognitive.microsoft.com host, which belongs to the older Cognitive Services account pattern; the Text Analytics resource created in the portal exposes a cognitiveservices.azure.com host. It is tempting because legacy tutorials still show this URL, and it works for classic multi-service keys.

https://mytextanalytics.cognitiveservices.azure.com/analyze

Why it fails: The /analyze path belongs to the newer unified Language service, which requires a Language resource rather than a Text Analytics resource. It is tempting because Microsoft is consolidating text capabilities there, but the stem specifies a Text Analytics resource and key1, whose sentiment operation sits under /text/analytics/v3.1/sentiment.