Connect to and Consume Azure Services practice questions

Answer: A) Route all applications through one API Management instance that uses the llm-semantic-cache-lookup and llm-semantic-cache-store policies with an Azure Managed Redis external cache that isn't partitioned per application

Putting API Management in front of Azure OpenAI with the semantic cache lookup and store policies, backed by Azure Managed Redis, gives all callers one shared response cache. Partitioning the cache per application with vary-by, or keeping a cache inside each application, removes the cross-application benefit.

• ACorrect. API Management semantic caching returns stored responses for identical and semantically similar prompts from an external Azure Managed Redis cache (RediSearch module enabled). If all applications go through the same gateway and the cache isn't split per caller, a response generated for one application can be returned to the others without calling the model again.
• BIncorrect. llm-token-limit caps token consumption per key and returns 429 (rate exceeded) or 403 (quota exceeded) to callers. It never stores or reuses responses, so identical prompts still reach the model and consume tokens.
• CIncorrect. vary-by partitions the cache. Keying it on each application's subscription ID means an application only gets cache hits on its own earlier requests, which defeats the goal of sharing responses across applications.
• DIncorrect. Separate in-process caches are siloed. Each application has to pay for its own first call for every prompt and never benefits from responses generated for other applications.

Answer: A) reasoning_effort, set to a lower value for simple lookups and a higher value for complex analysis

Azure OpenAI reasoning models expose reasoning_effort, which trades speed and cost against reasoning depth for each request. Sampling parameters such as temperature and top_p aren't supported, and max_completion_tokens only caps output length.

• ACorrect. Reasoning models accept a reasoning_effort parameter (for example low, medium or high). Lower effort produces faster, cheaper responses with less internal reasoning. Higher effort lets the model reason more thoroughly on demanding requests.
• BIncorrect. Temperature controls sampling randomness, not reasoning depth. It is also not a supported parameter for Azure OpenAI reasoning models.
• CIncorrect. max_completion_tokens caps the total tokens the model can generate, including reasoning tokens. A low cap can cut off a response, but it doesn't tell the model how much reasoning effort to apply.
• DIncorrect. top_p is a nucleus-sampling control, not a reasoning-depth setting, and reasoning models don't support it.

Answer: A) search_document

Cohere Embed models take an input_type that tells the model what role the text plays. For retrieval, embed the indexed corpus with search_document and the queries with search_query, which is why the Azure AI Search AML skill sample uses 'search_document' for chunked pages.

• ACorrect. Cohere Embed uses input_type to tell the model what role the text plays. Text stored in a vector index for retrieval should be embedded as search_document. The sample AML skill payload in the Azure AI Search docs sets input_type to 'search_document' for chunked content.
• BIncorrect. search_query is for the user's query text at search time, when you look for matching documents in the vector store. The chunks being indexed are the corpus, so they use search_document.
• CIncorrect. classification is for embeddings that will feed a text classifier. It isn't meant for a corpus that will be searched with queries.
• DIncorrect. clustering is for embeddings that will be grouped into clusters. For search and retrieval, embed the corpus with search_document and the queries with search_query.

Answer: A) Move the fixed 3,000 tokens of instructions to the start of the prompt and put the timestamp, user ID, and question after them

Azure OpenAI prompt caching is automatic for supported models. It only applies when a prompt is at least 1,024 tokens long and its first 1,024 tokens are identical across requests, so put fixed content at the start of the prompt and changing content at the end to get discounted cached tokens.

• ACorrect. A prompt is only cached when it's at least 1,024 tokens long and its first 1,024 tokens are identical across requests. Starting every prompt with a timestamp and user ID changes those first tokens on every call, so there's never a cache hit. Microsoft's guidance is to put fixed content first and changing content last.
• BIncorrect. A request has to be at least 1,024 tokens long to be cached at all. A shorter prompt would rule out caching instead of enabling it.
• CIncorrect. Prompt caching reuses the processing of identical input at the start of the prompt. It doesn't look at sampling settings, and it doesn't change the output content. Temperature has no effect on whether cached input tokens are reused.
• DIncorrect. Prompt caching is on by default for supported models, including GPT-4o and newer. The cache misses come from the prompt structure, not from a disabled setting.

Answer: A) Split, summarize, or trim the document so each request's input stays within the model's input token limit

Each model has a maximum input token limit that quota and request parameters can't change. Oversized inputs must be chunked, summarized or trimmed to fit within that limit.

• ACorrect. The maximum prompt tokens per request depends on the model and is a fixed property of that model. The fix is to send less in each request, for example by chunking the document, summarizing it first, or removing unneeded context.
• BIncorrect. TPM sets throughput per minute, and Microsoft documents that TPM allocation isn't related to a model's maximum input token limit. Raising TPM doesn't let a single request go beyond the model's context length.
• CIncorrect. max_tokens limits the length of the generated output, not the input. A higher value also uses up more of the context window and counts toward the rate-limit estimate, which makes the problem worse.
• DIncorrect. Backoff and retry-after-ms are for 429 throttling responses. An input that's too long fails validation with HTTP 400, so resending the same request fails the same way.

Answer: A) A model router deployment that uses the Balanced or Cost routing mode and selects an underlying model for each prompt

Foundry model router is deployed as a single deployment and routes each prompt to a suitable underlying model based on its complexity and the routing mode. Load balancers, Global Standard, and provisioned throughput don't choose a model for each prompt.

• ACorrect. Model router is a trained language model, deployed as a single deployment, that analyzes each prompt in real time (complexity, reasoning, task type) and routes it to a suitable underlying model. It uses smaller, cheaper models when they're good enough and larger or reasoning models when needed. The Balanced and Cost routing modes favor the most cost-effective model within a quality band.
• BIncorrect. API Management backend pools distribute requests by round-robin, weighted, or priority-based load balancing. They don't analyze prompt complexity, so simple and complex prompts would be split by weight rather than by what each prompt needs.
• CIncorrect. Global Standard routes traffic to available datacenters for capacity and quota. Every request still goes to the same model, so simple prompts wouldn't be served by a cheaper model.
• DIncorrect. Provisioned throughput reserves processing capacity for predictable throughput and lower latency variance. It doesn't choose between models per request, and sending simple prompts to the largest model doesn't optimize cost.

Answer: A) Describe the inventory lookup in the request's tools parameter and leave tool_choice set to auto

Function calling (the tools parameter with tool_choice auto) lets the model decide when to call a defined function and return JSON arguments for it. The application then runs the function and sends the result back to the model.

• ACorrect. This is function calling. With tool_choice set to auto (the default), the model decides from context whether to call a defined tool and returns a JSON object with the arguments. The application runs the lookup, appends the result as a tool message, and calls the model again to get the final answer.
• BIncorrect. JSON mode only controls the format of the model's output. It doesn't let the model decide when to invoke a specific function, and it doesn't produce a tool call tied to a defined schema that the application can run and return results for.
• CIncorrect. On Your Data grounds answers in documents retrieved from an index. It doesn't let the model call the team's live inventory API with arguments it generates, and an index would hold indexed copies of the inventory records rather than live stock levels.
• DIncorrect. Embeddings support semantic similarity search over content. They don't let the model decide to invoke an external API or generate structured arguments for one.

Answer: A) That the Foundry Models availability tables list the model version for that deployment type and region

Model availability depends on both region and deployment type, and geography-based types such as Standard get new models last. Check the Foundry Models availability tables for that type and region before choosing a region.

• ACorrect. Not all models support all deployment types, and availability differs by region. Microsoft says to check model availability by deployment type and region. New models launch first in Global types, and geography-based types such as Standard arrive last with no guaranteed availability date.
• BIncorrect. Azure OpenAI models are deployed on a Foundry or Azure OpenAI resource as a serverless deployment type. The service doesn't pull model weights from a customer's container registry.
• CIncorrect. You can create a new deployment of any model version that's supported in that region and deployment type. An earlier deployment isn't a prerequisite.
• DIncorrect. New models launch first on Global Standard, a pay-per-token type. A PTU reservation doesn't determine whether a model is offered in a region for the Standard type.

Answer: A) Azure API Management with a backend pool that uses priority-based load balancing and a circuit breaker rule

API Management's AI gateway can place multiple Azure OpenAI deployments behind one endpoint. Priority-based backend load balancing and circuit breaker rules send traffic to the primary deployment and automatically shift it to the secondary when the primary isn't responding.

• ACorrect. API Management's AI gateway lets you group AI endpoints as backends. Its load balancer supports priority-based distribution, so traffic prefers the primary deployment, and circuit breaker rules stop sending requests to a backend that isn't responding. Together these give clients a single endpoint with automatic failover.
• BIncorrect. Application Gateway is a regional service. If it runs only in the primary region, an outage there also takes down the single entry point, so it can't reliably fail traffic over to the other region.
• CIncorrect. Raising quota adds capacity in one region only. It provides no failover when that region or deployment becomes unavailable.
• DIncorrect. An alert notifies people but doesn't reroute anything. Failover would depend on someone making a manual change, which doesn't meet the requirement for automatic failover.

Answer: A) The model catalog, filtering by inference task, supported features, deployment option, and region, then reviewing each model card

The Microsoft Foundry model catalog is where you find and compare models before deploying them. You can filter by provider collection, region, deployment option, features, and task, and read license details on each model card.

• ACorrect. The model catalog lists models from Microsoft, Azure OpenAI, and partners. It can filter by collection, region, deployment option, supported features, and inference task, and each model card has a License tab.
• BIncorrect. The playground is for testing models you've already deployed. It isn't where you find undeployed models by region, deployment option, or license.
• CIncorrect. Evaluations score the outputs of models or apps you can already call. They don't let you browse every available model or filter by license and deployment option.
• DIncorrect. Agent Service hosts and runs agents that use a model you've deployed. It isn't the place to find and compare the full range of available models before deployment.