Free AI Intermediate practice test

When an Azure OpenAI model version is retired, customers must act: they need to update their deployment to a supported model version before the retirement date. After retirement, the old version no longer serves new calls. The claim that every deployment is upgraded automatically is wrong: automatic upgrades happen only when 'auto-update to default' is explicitly enabled on the deployment, and this is not the default behavior for all deployments. The claim that the deployment is deleted and returns HTTP 404 is also wrong: calls to the retired version start to fail, but the resource is not removed in the way described. The claim that the version stays available indefinitely while the subscription is active is wrong because Microsoft controls the lifecycle of hosted model versions.

When Azure OpenAI diagnostic logs are sent to a Log Analytics workspace, they appear in the 'AzureDiagnostics' table. The per-request log entries include fields such as 'prompt_tokens_d', 'completion_tokens_d', and 'total_tokens_d' that KQL can query to filter requests by token usage. The 'AppRequests' option is wrong because that is an Application Insights table for application-level telemetry. It doesn't contain Azure OpenAI token usage fields such as a 'token_count' custom dimension unless you add custom instrumentation. The 'AzureMetrics' option with the 'TokenTransaction' metric is wrong because that table holds aggregated metric time series (for example, total tokens per minute). It doesn't give the per-request detail needed to find individual requests over 3,000 tokens. The 'ContainerLog' option is wrong because that table holds stdout/stderr from containerized workloads. It has nothing to do with Azure OpenAI Service API diagnostic logging, and the managed service doesn't expose container runtime logs to you.

Setting in_scope: true and enabling semantic ranking are correct. Setting in_scope: true in the Azure OpenAI on your data payload tells the model to answer only from retrieved documents and to say 'I don't know' when the answer isn't found, which directly reduces out-of-scope answers. Semantic ranking improves the relevance of retrieved chunks, so the most pertinent information reaches the model. That lowers the chance the model makes up answers because of missing context. Raising the TPM quota is wrong because quota controls throughput, not answer grounding. Switching to GPT-4o-mini is wrong because a smaller model does not inherently hallucinate less, and smaller models can hallucinate more. Raising top to 50 is wrong because passing 50 retrieved chunks often adds noise and can actually increase hallucinations by diluting the relevant content.

Option E is correct. For zero-downtime canary/blue-green model upgrades with fine-grained traffic control and instant rollback, the recommended approach is to deploy the new model version to a managed online endpoint (in Azure AI Foundry or Azure Machine Learning) and use the endpoint's deployment weight settings to split traffic (e.g., 10% to the new 'green' deployment, 90% to the existing 'blue' deployment). Rollback is instant by resetting weights to 100%/0%. Option A is incorrect; using Azure Front Door across two separate OpenAI resources is architecturally complex, harder to manage, and not the canonical approach—it also introduces cross-region latency inconsistencies. Option B is incorrect in its premise: Azure OpenAI Service itself does not provide native traffic splitting between two deployments within the same resource; that capability lives at the managed online endpoint layer. The option conflates OpenAI resource deployments with managed online endpoint traffic split. Option C is incorrect; there is no built-in A/B testing feature within a single Azure OpenAI deployment object—traffic split is not configurable at the deployment level. Option D is incorrect; Azure OpenAI does not automatically perform canary rollouts when you update a deployment's model version—it performs an in-place update.

The Azure AI Foundry model catalog offers two main deployment options for third-party and open-source models. Serverless API is a pay-as-you-go managed endpoint where Microsoft manages the infrastructure and billing is per token. Managed Compute is a dedicated endpoint backed by Azure ML compute. Both provide scalable API access without the developer managing the underlying VMs or containers. A local Docker container exposed through a REST port is not a scalable production approach and is not a catalog deployment target. Deploying to AKS with a Helm chart is a custom bring-your-own-infrastructure approach, not the catalog's deployment mechanism. Azure Batch pools, even with autoscaling, are built for large-scale asynchronous batch jobs, not low-latency real-time inference API endpoints.

Option B is correct: increasing the number of shards distributes the ANN index across more nodes, reducing per-node query load and improving latency. Option F is correct: adding more replicas to the index endpoint enables horizontal scaling, distributing concurrent query traffic and reducing latency under load. Option A is incorrect: changing the distance measure does not materially affect ANN query latency; it changes which neighbors are returned. Option C is a common misconception — reducing leafNodeEmbeddingCount increases the number of leaf nodes visited, which can actually increase latency; the parameter to reduce for a latency-recall tradeoff is 'num_neighbors' or the tree depth configuration. Option E is incorrect: re-embedding with lower dimensionality would require re-indexing all vectors and may degrade recommendation quality; it also doesn't address the root cause of latency from additional vectors. Option D is incorrect: streaming updates affect index freshness, not query latency for an existing index.

Option E is correct: distillation trains the student on soft targets (the teacher's output probability distribution), which carries more information than hard labels. Option F is correct: a core use case is compressing a large Gemini model into a smaller, faster student model. Option C is correct: a teacher model can generate synthetic labels for an unlabeled dataset, which are then used to train the student — a key advantage of distillation. Option A is wrong: distillation does not require identical architectures; the student is typically smaller. Option B is wrong: the student is expected to be smaller and may sacrifice some accuracy for efficiency, not exceed the teacher. Option D is wrong: distillation is distinct from SFT on human labels; it uses teacher-generated soft labels, not just original human annotations.

Vertex AI Agent Builder supports data stores backed by Cloud Storage for unstructured documents (option A), enabling the agent to retrieve and answer questions from product manuals. For calling external APIs, Agent Builder supports OpenAPI tool definitions (option C) that allow the agent to invoke REST endpoints—such as an internal escalation service—when triggered by intent or conditions. Option B (Matching Engine) requires custom engineering outside Agent Builder and is not a built-in Agent Builder capability. Option D is incorrect: Vertex AI Pipelines are ML workflow orchestrators, not conversational agent components. Option E (BigQuery data store) is used for structured, SQL-queryable data—not for unstructured product manuals in Cloud Storage.

The three most likely causes of score inflation are: (B) a vague or permissive judge prompt — if the rubric does not clearly define what constitutes a deduction (e.g., missing information, factual errors), Gemini will default to lenient scoring; (C) an unrepresentative or too-easy eval dataset — if the test cases do not include hard or ambiguous questions, most model responses will genuinely match references, inflating scores; and (E) verbosity bias — LLM judges, including Gemini, are known to favor longer, fluent responses over concise but accurate ones, inflating scores for verbose outputs. Positional bias (A) primarily affects pairwise evaluation where the order of Candidate A vs. B matters; in pointwise evaluation there is only one candidate, so positional bias is not a primary concern. Pointwise evaluation is a valid and calibrated approach (D is false); pairwise is complementary, not superior for all cases. Pipeline caching (F) would return identical outputs but would not systematically inflate scores — and caching affects component execution, not the evaluation scoring logic itself.

Valid causes for a context cache miss include: (F) TTL expiration — context caches have a configurable TTL and are evicted after it expires, requiring full context reprocessing on the next request; (C) region mismatch — Vertex AI context caches are regional resources; if a request is routed to a different region than where the cache was created, the cache is unavailable and the context is reprocessed; (E) prompt modification — the cache is keyed to the exact content of the cached prefix; any change to the system prompt text produces a different cache key, resulting in a miss. Option D is incorrect: the non-cached (dynamic) portion of the request is expected to change and does not affect the cache for the static prefix — that is the entire purpose of context caching. Option B is partially true (model version must match), but the scenario does not indicate a model version change — it is not 'always' a cause relative to the three clearest answers. Option A is incorrect: Vertex AI context caching does not have a bypass triggered solely by total token count as long as the cached tokens meet the minimum token threshold; the non-cached portion is appended separately.

Provisioned throughput in Amazon Bedrock allows customers to purchase a fixed number of model units, guaranteeing a consistent throughput level that prevents throttling — ideal for high-volume, predictable workloads. It does not make inference free after a one-time purchase; customers pay for the committed capacity regardless of actual usage, which is a commitment cost, not free inference. Provisioned throughput applies to a specific model in specific Regions; it does not grant access to every model across all Regions or bypass Regional quotas. Provisioned throughput is a committed capacity purchase with a term (e.g., 1 month or 6 months) and does not auto-scale with traffic — that characteristic describes on-demand pricing.

Grounding checks in Bedrock Guardrails compare the model's generated response against a provided reference source (e.g., retrieved Knowledge Base passages) and compute a grounding score. Responses that contain claims not supported by the reference content are flagged as potentially hallucinated — this is precisely what grounding checks are designed for. Detecting offensive or harmful language in user input is the role of content filters, not grounding checks. Restricting conversations to approved topics is handled by the denied topics feature. Detecting PII in model responses or user inputs is handled by sensitive information filters (PII redaction), not grounding checks.

Amazon Rekognition provides a fully managed Content Moderation API that detects explicit, suggestive, or violent content in images and videos with no ML expertise required. This is exactly what it was built for. Bedrock with a Stability AI model is wrong because that is a generative model for creating images, not for classifying or moderating them. SageMaker with a pre-built image classifier is wrong because setting up and maintaining a custom classifier takes significant ML expertise. Textract is wrong because it extracts text and structured data from documents and does not moderate image content.

The Groundedness metric in Amazon Bedrock's automatic model evaluation measures whether the model's generated response is factually supported by the provided source passages, which directly addresses the hallucination concern in RAG use cases. It checks whether claims in the response can be traced back to the retrieved context. ROUGE-L measures lexical overlap between a generated response and a reference answer; it does not assess whether the content is grounded in source documents and is better suited to summarization tasks. BERTScore measures semantic similarity against a reference text, not against source passages, so it does not assess grounding in retrieved context. The Correctness metric with an LLM judge compares the response against a golden reference answer for factual accuracy, but it requires pre-defined reference answers and does not directly evaluate grounding against retrieved passages the way the Groundedness metric does.

Correct: D. The multilingual-e5-large model (and E5 models in general) are trained with task-specific instruction prefixes. Queries must be prefixed with 'query: ' and documents/passages with 'passage: ' before encoding. Omitting these prefixes degrades retrieval quality significantly because the model was fine-tuned to expect them. Cosine similarity is then computed between the resulting embeddings. C is wrong because E5 models require the query: and passage: prefixes — using raw strings without prefixes is a common mistake that leads to suboptimal results. B is wrong because multilingual-e5-large is a bi-encoder (it encodes queries and documents independently), not a cross-encoder; it has no predict() method for pairs. A is wrong because E5 embeddings are L2-normalized by default, making cosine similarity equivalent to dot product — but more importantly, the claim that cosine similarity should not be used is incorrect.

(B) Correct — Organizations support private repositories, so only members with the appropriate role can access the models. (D) Correct — Organizations provide a shared namespace where multiple collaborators can push, pull, and manage model files, making team collaboration straightforward. (E) Incorrect — Hugging Face does not change or upgrade the license of a model based on where it is hosted; licenses are determined by the model creator. (A) Incorrect — Rate limits on the Inference API are tied to account tier/subscription, not simply whether a model is in an organization. (C) Incorrect — Hugging Face does not offer SLA-backed uptime guarantees for standard Hub hosting; that is a feature of their enterprise/dedicated offerings.

Option D is correct. Zero-shot classification models (like facebook/bart-large-mnli) use natural language inference to score candidate labels provided at inference time, so they can classify into arbitrary categories never seen during training — no fine-tuning required. Option C is wrong because a sentiment classification model (SST-2) outputs only positive/negative labels; it cannot generalize to unseen support ticket categories and would require retraining or fine-tuning. Option A is wrong because a model fine-tuned on the original support ticket categories has a fixed output head — remapping logits to new labels does not give meaningful predictions for categories outside the training distribution without additional fine-tuning. Option B (feature extraction + k-NN) could support new categories at query time, but the k-NN classifier still requires labeled examples from the original categories to compute neighbors — it does not handle truly unseen categories without any training data, making it inferior to zero-shot classification in this scenario.

B and D are correct. Clear annotation guidelines that define a complete and correct answer reduce subjectivity, and having at least two independent annotators label each example (and measuring their agreement) catches labeling errors. A is wrong: keeping only questions the system already gets right hides its failure modes; a golden set should include edge cases and hard questions. C is wrong: generating questions with the same LLM being evaluated introduces circular bias and misses its blind spots. E is wrong: a single annotator introduces idiosyncratic bias and gives no quality check. F is wrong: restricting examples to verbatim, single-chunk answers makes the benchmark unrealistically easy and misses multi-hop and ambiguous questions.

Explicit, example-anchored rubrics reduce ambiguity and help annotators apply criteria consistently. Measuring inter-annotator agreement (e.g., Cohen's kappa) quantifies label reliability and identifies where guidelines need clarification. Including adversarial and edge-case examples ensures the dataset probes failure modes rather than only easy cases. Using a single annotator eliminates the ability to measure agreement and introduces unchecked individual bias. Scraping unannotated web data without review introduces noise and unlabeled examples that do not constitute a golden dataset. Using the evaluated model to pre-label creates a circular dependency and contaminates the evaluation with the model's own errors.

QLoRA quantizes the base model weights to 4-bit precision (dramatically reducing VRAM requirements) and then applies LoRA adapters in a higher precision, making it feasible to fine-tune very large models on limited hardware. RLHF requires training a separate reward model and running PPO, which is more memory-intensive, not less. Full SFT with gradient checkpointing reduces activation memory but does not reduce the memory footprint of the model weights themselves sufficiently for 70B models on 24 GB GPUs. DPO is a preference-learning method that still requires full or LoRA-based fine-tuning; it does not inherently address quantization for VRAM savings.