Troubleshooting practice questions

You are troubleshooting an Azure AI Search indexer that fails to index a PDF file stored in Azure Blob Storage. The error message indicates that the document is encrypted. What is the most likely cause and solution?

Trap 1: The indexer is not configured with the PDF parser; set the parsing…

PDF parsing is already handled by the blob indexer's built-in document extraction; parsing mode governs text versus layout extraction, not decryption. It tempts because parser misconfiguration does cause indexing failures, but the error explicitly names encryption, so the fix is supplying decryption credentials.

Trap 2: The file format is unsupported; convert to PDF/A

PDF is a supported format, and PDF/A conversion does not remove password protection, so the encrypted content still fails. It tempts because unsupported formats do break indexers, but the error names encryption; the actual fix is decrypting the file or configuring the indexer with an encryption key.

Trap 3: The file is too large; split it into smaller parts

File size triggers a different error about document limits, not encryption; splitting the PDF leaves the encryption intact. It tempts because oversized blobs genuinely fail indexing, but the stated cause is encryption, which requires removing the password or granting the indexer a decryption key.

A
The indexer is not configured with the PDF parser; set the parsing mode
Why it fails: PDF parsing is already handled by the blob indexer's built-in document extraction; parsing mode governs text versus layout extraction, not decryption. It tempts because parser misconfiguration does cause indexing failures, but the error explicitly names encryption, so the fix is supplying decryption credentials.
B
The file format is unsupported; convert to PDF/A
Why it fails: PDF is a supported format, and PDF/A conversion does not remove password protection, so the encrypted content still fails. It tempts because unsupported formats do break indexers, but the error names encryption; the actual fix is decrypting the file or configuring the indexer with an encryption key.
C
The file is too large; split it into smaller parts
Why it fails: File size triggers a different error about document limits, not encryption; splitting the PDF leaves the encryption intact. It tempts because oversized blobs genuinely fail indexing, but the stated cause is encryption, which requires removing the password or granting the indexer a decryption key.
D
The PDF is encrypted; remove encryption before indexing
Azure AI Search's document cracking cannot decrypt password-protected or rights-managed PDFs, so the indexer reports the document as encrypted and skips it. Removing encryption before indexing, or supplying an unencrypted copy, lets the blob indexer extract text successfully.

Question 2hardmultiple choice

You are troubleshooting an agent built with Microsoft Copilot Studio. The agent uses a custom topic to check inventory levels. The topic calls a Power Automate flow that returns JSON with 'inStock' boolean. The agent sometimes says 'Item is in stock' even when the flow returns false. What is the most likely cause?

Trap 1: The Power Automate flow has a timeout and returns default true.

Power Automate timeouts fail or return an error, not a default true value; nothing in the flow defines such a fallback. It is tempting because timeouts are a familiar integration failure, and would be correct if the flow's error-handling branch explicitly assigned true to inStock on timeout.

Trap 2: The agent's response is based on a different variable that defaults…

A variable defaulting to true would produce consistently wrong answers, not the intermittent behaviour described. It is tempting because variable misbinding is a genuine topic-authoring error, and would be correct if the response node referenced an unrelated variable initialised to true instead of the flow's inStock output.

Trap 3: The agent's topic is not parsing the JSON output correctly.

Copilot Studio topics do parse flow JSON, and a boolean mismatch would fail consistently rather than intermittently. It is tempting because malformed JSON handling is a common integration fault, and would be correct if the flow returned a string like 'false' that the topic never converted to a boolean.

A
The Power Automate flow has a timeout and returns default true.
Why it fails: Power Automate timeouts fail or return an error, not a default true value; nothing in the flow defines such a fallback. It is tempting because timeouts are a familiar integration failure, and would be correct if the flow's error-handling branch explicitly assigned true to inStock on timeout.
B
The topic's condition is using a variable that is not being updated with the flow output.
The topic evaluates a variable that never receives the flow's 'inStock' output, so the condition tests stale or default data rather than the returned boolean. Binding the flow response to that variable before the condition resolves the false-positive 'in stock' message.
C
The agent's response is based on a different variable that defaults to true.
Why it fails: A variable defaulting to true would produce consistently wrong answers, not the intermittent behaviour described. It is tempting because variable misbinding is a genuine topic-authoring error, and would be correct if the response node referenced an unrelated variable initialised to true instead of the flow's inStock output.
D
The agent's topic is not parsing the JSON output correctly.
Why it fails: Copilot Studio topics do parse flow JSON, and a boolean mismatch would fail consistently rather than intermittently. It is tempting because malformed JSON handling is a common integration fault, and would be correct if the flow returned a string like 'false' that the topic never converted to a boolean.

Question 3mediummultiple choice

You are troubleshooting an agentic solution where the agent is not returning responses within acceptable time limits. You suspect the agent is making too many sequential calls to external tools. Which strategy should you recommend to reduce latency?

Trap 1: Increase the max token limit

Raising the max token limit only allows longer prompts and completions; it does not reduce the count of sequential external tool calls causing the delay. It is tempting because token limits govern model throughput, and increasing them helps when responses are truncated, not when orchestration latency dominates.

Trap 2: Add more tools to distribute the load

Adding tools increases the number of functions the agent may select and invoke, worsening sequential call latency rather than reducing it. It is tempting because distributing load across services helps throughput in parallel architectures, but the stem requires cutting the number of sequential tool calls, not spreading them.

Trap 3: Reduce the thread history length

Trimming thread history reduces prompt tokens and cost, but the sequential tool calls themselves still execute one after another, so wall-clock latency is unchanged. Tempting because shorter prompts feel faster, it would be correct only if latency stemmed from context size rather than serialised tool invocation.

A
Increase the max token limit
Why it fails: Raising the max token limit only allows longer prompts and completions; it does not reduce the count of sequential external tool calls causing the delay. It is tempting because token limits govern model throughput, and increasing them helps when responses are truncated, not when orchestration latency dominates.
B
Enable parallel tool execution
Parallel tool execution dispatches independent external tool calls concurrently rather than sequentially, so total latency reflects the slowest call instead of the sum of all calls. This directly addresses the stem's constraint of excessive sequential tool invocations exceeding acceptable response times.
C
Add more tools to distribute the load
Why it fails: Adding tools increases the number of functions the agent may select and invoke, worsening sequential call latency rather than reducing it. It is tempting because distributing load across services helps throughput in parallel architectures, but the stem requires cutting the number of sequential tool calls, not spreading them.
D
Reduce the thread history length
Why it fails: Trimming thread history reduces prompt tokens and cost, but the sequential tool calls themselves still execute one after another, so wall-clock latency is unchanged. Tempting because shorter prompts feel faster, it would be correct only if latency stemmed from context size rather than serialised tool invocation.

Question 4easymultiple choice

Your chatbot uses Azure Bot Service and QnA Maker. Users can ask questions in natural language, and the bot returns answers from a knowledge base. Users report that the bot sometimes returns irrelevant answers. What should you do first?

Trap 1: Create multiple QnA Maker knowledge bases for different topics

Splitting into multiple knowledge bases does not fix irrelevant matches; it multiplies maintenance and still returns poor answers from each. It is tempting because separating topics can improve precision, but that applies once you have clean, well-separated content, not as the first diagnostic step.

Trap 2: Integrate LUIS to detect user intent

LUIS detects intent, but the bot already routes questions to QnA Maker; irrelevant answers stem from knowledge base content and matching, not intent classification. It is tempting because LUIS improves natural-language understanding, and it would be correct if the bot needed to distinguish questions from commands.

Trap 3: Use Azure AI Search to index the knowledge base

Indexing the knowledge base in Azure AI Search does not change QnA Maker's own ranking of matched question-answer pairs, so irrelevant answers persist. It is tempting because Azure AI Search powers richer semantic retrieval, and would be right when building a custom search solution over documents rather than a QnA Maker knowledge base.

A
Create multiple QnA Maker knowledge bases for different topics
Why it fails: Splitting into multiple knowledge bases does not fix irrelevant matches; it multiplies maintenance and still returns poor answers from each. It is tempting because separating topics can improve precision, but that applies once you have clean, well-separated content, not as the first diagnostic step.
B
Integrate LUIS to detect user intent
Why it fails: LUIS detects intent, but the bot already routes questions to QnA Maker; irrelevant answers stem from knowledge base content and matching, not intent classification. It is tempting because LUIS improves natural-language understanding, and it would be correct if the bot needed to distinguish questions from commands.
C
Use Azure AI Search to index the knowledge base
Why it fails: Indexing the knowledge base in Azure AI Search does not change QnA Maker's own ranking of matched question-answer pairs, so irrelevant answers persist. It is tempting because Azure AI Search powers richer semantic retrieval, and would be right when building a custom search solution over documents rather than a QnA Maker knowledge base.
D
Review and edit the QnA pairs to add alternative phrasings
Editing QnA pairs to add alternative phrasings directly improves matching, because QnA Maker ranks answers by comparing the user's utterance against each question's stored wording. Irrelevant responses stem from weak lexical overlap, so enriching question variants raises confidence scores for the intended pair, satisfying the stem's requirement to fix irrelevant answers first.

Question 5mediummultiple choice

Your Azure AI Document Intelligence model is failing to extract tables from scanned PDFs. The PDFs are low-quality images. What should you do first?

Trap 1: Use Azure AI Computer Vision to enhance the image.

Computer Vision performs OCR and image analysis, not the deskewing, denoising and contrast correction that Document Intelligence's own prebuilt read/OCR pipeline applies before table extraction. It is tempting because Computer Vision genuinely handles image enhancement tasks, and would suit a scenario requiring captioning, tagging or standalone text extraction from photographs.

Trap 2: Retrain the model with more table examples.

Retraining cannot recover tabular structure that the OCR stage never captured from degraded scans; the failure is at input quality, not model knowledge. It is tempting because custom neural models do improve extraction of unusual table layouts, and retraining would be right if clean scans were being misread due to unfamiliar formats.

Trap 3: Use a higher resolution scanner for input PDFs.

Rescanning improves future inputs but does not fix the existing low-quality PDFs already failing extraction. It is tempting because scanner resolution genuinely determines OCR accuracy for new documents, yet the stem asks what to do first about the current failing files, which requires preprocessing or a different model.

A
Verify that the Read OCR step is extracting text correctly.
Verifying the Read OCR output comes first because Document Intelligence's layout and table extraction depend entirely on that OCR layer. Low-quality scans degrade character and word recognition, so tables cannot be reconstructed reliably. Confirming whether the Read model extracts text correctly isolates the OCR constraint before tuning table extraction.
B
Use Azure AI Computer Vision to enhance the image.
Why it fails: Computer Vision performs OCR and image analysis, not the deskewing, denoising and contrast correction that Document Intelligence's own prebuilt read/OCR pipeline applies before table extraction. It is tempting because Computer Vision genuinely handles image enhancement tasks, and would suit a scenario requiring captioning, tagging or standalone text extraction from photographs.
C
Retrain the model with more table examples.
Why it fails: Retraining cannot recover tabular structure that the OCR stage never captured from degraded scans; the failure is at input quality, not model knowledge. It is tempting because custom neural models do improve extraction of unusual table layouts, and retraining would be right if clean scans were being misread due to unfamiliar formats.
D
Use a higher resolution scanner for input PDFs.
Why it fails: Rescanning improves future inputs but does not fix the existing low-quality PDFs already failing extraction. It is tempting because scanner resolution genuinely determines OCR accuracy for new documents, yet the stem asks what to do first about the current failing files, which requires preprocessing or a different model.

Question 6hardmultiple choice

Refer to the exhibit. You are troubleshooting an Azure OpenAI API call that is returning incomplete responses. The response stops mid-sentence. Which parameter should you adjust?

Exhibit

{
  "model": "gpt-4",
  "messages": [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "What is the capital of France?"}
  ],
  "max_tokens": 500,
  "temperature": 0.7,
  "top_p": 0.95,
  "frequency_penalty": 0,
  "presence_penalty": 0,
  "stop": null
}

Trap 1: Remove the stop parameter.

Removing stop only matters if a stop sequence truncated the output; incomplete mid-sentence responses typically stem from max_tokens being reached, so deleting stop changes nothing when no stop sequence is configured. Stop sequences are legitimately used to halt generation at a chosen delimiter, which is a different scenario.

Trap 2: Increase temperature to 1.0.

Temperature controls randomness of token selection, not response length, so raising it to 1.0 cannot extend a truncated completion and may add incoherence. It tempts because temperature is the most familiar sampling knob, yet it is the right adjustment when outputs feel repetitive or need creative variation, not when max_tokens cuts them off.

Trap 3: Increase top_p to 1.0.

Top_p does not limit length.

A
Increase max_tokens to 1000.
max_tokens caps the number of tokens generated in the completion, so a low value truncates output mid-sentence. Raising it to 1000 lets the model finish, directly resolving the incomplete response. Temperature, top_p and presence penalties alter style, not truncation length.
B
Remove the stop parameter.
Why it fails: Removing stop only matters if a stop sequence truncated the output; incomplete mid-sentence responses typically stem from max_tokens being reached, so deleting stop changes nothing when no stop sequence is configured. Stop sequences are legitimately used to halt generation at a chosen delimiter, which is a different scenario.
C
Increase temperature to 1.0.
Why it fails: Temperature controls randomness of token selection, not response length, so raising it to 1.0 cannot extend a truncated completion and may add incoherence. It tempts because temperature is the most familiar sampling knob, yet it is the right adjustment when outputs feel repetitive or need creative variation, not when max_tokens cuts them off.
D
Increase top_p to 1.0.
Why it fails: Top_p does not limit length.

Question 7hardmultiple choice

You are the Azure AI engineer for a large e-commerce company. The company uses Azure Computer Vision to automatically tag product images uploaded by sellers. The system has been running smoothly for months. However, after a recent update to the Computer Vision API, you notice that certain images of clothing items are being tagged with incorrect labels, such as 'shoe' for a shirt. The images are clear and well-lit. You have confirmed that the image format (JPEG) is supported and the size is within limits. The issue occurs consistently for clothing items with similar colors. Other product categories work fine. You suspect the issue is related to the API version. What should you do first?

Trap 1: Increase the image size limit.

Image size limits govern whether an image is accepted for analysis at all; exceeding them returns an error, not a wrong label. The images are already within limits, so raising the cap changes nothing. Size limits would be relevant when uploads are rejected for being too large.

Trap 2: Switch to a custom model trained on clothing items.

A custom model is trained on your own labelled images to recognise domain-specific classes the prebuilt model lacks. Here the prebuilt tagging worked for months and broke after an API update, so the regression lies in the service version, not model coverage. Custom training would be correct when prebuilt categories genuinely do not exist.

Trap 3: Reduce the confidence threshold to 50% to see if more tags appear.

Lowering the confidence threshold makes the service return more candidate tags, including weaker ones; it does not correct a label that is confidently wrong. The mislabelling stems from the API version change, so threshold tuning adds noise. Threshold adjustment would be correct when valid tags are being suppressed for falling just below the cutoff.

A
Increase the image size limit.
Why it fails: Image size limits govern whether an image is accepted for analysis at all; exceeding them returns an error, not a wrong label. The images are already within limits, so raising the cap changes nothing. Size limits would be relevant when uploads are rejected for being too large.
B
Check the API version used in the application code and compare with the latest version.
Version-specific model changes can alter labelling behaviour, so verifying the API version in code against the latest release isolates whether the regression stems from the update. This is the first diagnostic step before retraining or altering image preprocessing.
C
Switch to a custom model trained on clothing items.
Why it fails: A custom model is trained on your own labelled images to recognise domain-specific classes the prebuilt model lacks. Here the prebuilt tagging worked for months and broke after an API update, so the regression lies in the service version, not model coverage. Custom training would be correct when prebuilt categories genuinely do not exist.
D
Reduce the confidence threshold to 50% to see if more tags appear.
Why it fails: Lowering the confidence threshold makes the service return more candidate tags, including weaker ones; it does not correct a label that is confidently wrong. The mislabelling stems from the API version change, so threshold tuning adds noise. Threshold adjustment would be correct when valid tags are being suppressed for falling just below the cutoff.