Free AI-103 practice test

Prompt engineering with a pre-trained model is the fastest, lowest-cost starting point when no custom training data exists and the task is general-purpose. It requires no training pipeline or labeled data. Fine-tuning (C) requires labeled examples and additional cost, which is unnecessary here. Training from scratch (D) is impractical for a startup with no training infrastructure or data. RAG (A) adds architectural complexity and requires a document index; it is valuable but not the simplest first choice when the task is already general and no specific knowledge base is mandated.

In Azure AI Content Safety, a lower severity threshold means the filter triggers (blocks) content at lower severity levels, providing stricter filtering. Setting Sexual to Low blocks all sexual content (even mild). Setting Violence to High means only high-severity (graphic) violent content is blocked, allowing lower-severity content to pass—matching the requirement. Option D reverses the thresholds, which would allow low-severity sexual content (incorrect for a children's platform) and block even low-severity violence. Option C disables sexual filtering entirely, which is unacceptable. Option A sets both to Low, which would block even mild violence references—more restrictive than the stated requirement for violence.

Azure AI Content Safety severity thresholds work cumulatively: setting the block threshold to 'Low' means content rated Low, Medium, or High severity for that category will all be blocked. This ensures no Hate content at any severity level passes through, which is what the developer requires. Option A is incorrect: blocking only at 'High' severity would allow Low and Medium severity Hate content to pass, which violates the requirement. Option D is incorrect: the 'Annotate' action flags content in the API response metadata but does not block it — flagged content is still returned to the application, so harmful content would not be stopped. Option C is incorrect: the default content filter profile in Azure OpenAI blocks Hate content at 'Medium' and 'High' severity by default, not 'Low'; Low-severity Hate content would pass through under the default configuration, so the default profile does not meet the stated requirement.

The 'Cognitive Services OpenAI User' role grants permissions to call Azure OpenAI inference endpoints (completions, embeddings) but does NOT allow creating, modifying, or deleting deployments or fine-tuned models—exactly matching the requirement. 'Cognitive Services OpenAI Contributor' (A) includes permissions to create and manage deployments, which exceeds the requirement. 'Azure AI Developer' at hub scope (B) is broader, granting project-level development permissions across AI Foundry resources, not just inference consumption. 'Cognitive Services Contributor' at subscription scope (C) is far too broad, granting management-plane write permissions across all Cognitive Services in the subscription.

RAG is the best fit: the knowledge base (sensor logs and maintenance reports) is large, specialized, and needs to stay current as new reports are added. RAG retrieves exact passages, reducing hallucination on factual technical content. Prompt engineering alone (C) cannot surface specific sensor log data at inference time. Fine-tuning alone (A) bakes knowledge into weights at training time; it cannot incorporate new reports without retraining and risks hallucinating specifics. The combined approach (D) is legitimate in advanced scenarios but is more complex than necessary here, and fine-tuning on only 500 pairs for formatting purposes adds cost and maintenance overhead without clear benefit over RAG alone.

To prevent public internet access to Azure OpenAI, two steps are required: (1) Disabling public network access on the resource ensures no traffic is accepted from public IP addresses. (2) Creating a private endpoint in the corporate VNet provides a private IP address within the VNet so applications can reach the service over the private network. Together, these two steps ensure data never leaves the corporate network. CMK (option C) is an encryption-at-rest feature for data confidentiality — it does not control network access paths. Blocking port 443 via NSG (option B) would break HTTPS connectivity entirely, including from within the VNet, and NSGs operate at the subnet level for VM traffic — not for PaaS service endpoints. RBAC role assignment (option A) controls who can call the API but does not restrict network routing.

Storing credentials in Azure Key Vault and referencing them via a managed identity connection is the correct approach. Azure AI Foundry Agent Service supports configuring authentication for OpenAPI tools using connections that leverage managed identity, keeping secrets out of code and specifications. Hard-coding the client secret in the OpenAPI spec is a critical security risk and an anti-pattern that violates least-privilege principles. Passing a Bearer token through the system prompt is fragile, insecure, and not a supported authentication mechanism for tool-level API calls. Using a custom function tool to retrieve and pass a token adds unnecessary complexity and still requires secure secret storage, which managed identity connections already handle natively.

The agent can only invoke endpoints that are described in the OpenAPI specification provided to the tool. Removing the DELETE operation from the spec structurally prevents the agent from ever calling it, regardless of model behavior. System prompt instructions (D) are soft guardrails and can be bypassed through prompt injection or model errors—they do not provide a hard constraint. API Management filtering (B) can serve as a defense-in-depth layer but requires additional infrastructure and does not prevent the agent from attempting the call; a hard block in the spec is simpler and more reliable. Content filters (A) operate on text content, not on HTTP method routing, and cannot block specific API operations.

RAG is the correct choice here. The handbook is a discrete, authoritative document corpus that changes quarterly—RAG allows the index to be refreshed without retraining the model, keeping answers current at low cost and effort. Fine-tuning embeds knowledge into model weights during training; when the handbook is updated quarterly, the model would need to be retrained each time, which is expensive and slow. Fine-tuning is better for teaching style, format, or behavior—not for injecting frequently changing factual knowledge. RAG can handle large corpora far exceeding the context window via chunking and retrieval—it is not limited to context-window-sized documents. While large context models can accept long documents, placing a 500-page handbook in every system prompt is prohibitively expensive in tokens, slow, and impractical for production use.

Hybrid search in Azure AI Search fuses BM25 keyword scores with vector similarity scores using Reciprocal Rank Fusion (RRF), combining the strengths of both approaches without requiring the additional semantic ranker configuration. Pure vector search ignores keyword signals and can miss exact-term matches. Full-text (BM25) search only ignores vector similarity and performs poorly on paraphrased or conceptually similar queries. Semantic ranker with vector search does provide re-ranking but requires explicit semantic configuration and adds latency/cost beyond what the question asks for.

Setting "stream": true in the chat completions request body instructs the API to return server-sent events (SSE), delivering tokens incrementally as they are generated. "async": true is not a valid Azure OpenAI API parameter; asynchronous behavior is handled client-side by the SDK. "incremental": true is not a recognized parameter in the Azure OpenAI API. "output_mode": "stream" is also not a valid Azure OpenAI API field — this is a common misconception.

Submitting tool outputs via the submit_tool_outputs endpoint is correct. When a Run reaches requires_action status, the application must call the submit tool outputs API, providing the tool call ID returned by the model and the result of executing the function. This is the designed handshake that allows the Run to proceed. Deleting and recreating the Run is incorrect because that would lose conversation context and is not the intended workflow. Adding the tool output as a new user message is incorrect; that would corrupt the conversation structure — tool outputs must be submitted through the dedicated tool output mechanism. Updating the Agent definition is incorrect; the Agent definition is for static configuration such as instructions and available tools, not for passing runtime function results.

Sequential pipeline pattern is correct because tasks are executed in a defined order — the DataAnalystAgent runs first, its output is passed to the ReportWriterAgent, and only then is the final response produced. This linear dependency chain is the hallmark of a sequential pipeline. Fan-out / Fan-in is incorrect because that pattern dispatches tasks to multiple agents in parallel and then aggregates results; there is no dependency between the parallel tasks. Competing consumers is a messaging pattern where multiple workers compete to process items from a queue, which is unrelated to the described design. Event-driven reactive pattern involves agents acting autonomously in response to events, not the deterministic step-by-step handoff described.

A pro-mode Content Understanding pipeline lets you define a reusable, structured extraction schema (colors, logos, category) once and apply it consistently across a batch, which is exactly the stated need for uniform structured extraction at scale. Option A describes ad hoc, per-image prompting without a consistent schema, which risks inconsistent output across the catalog. Option C does not scale and is not an Azure AI capability. Option D is the wrong modality — it processes audio, not visual catalog images.

Pro-mode Content Understanding is designed for defining a structured, multi-field extraction schema applied consistently in one pipeline, which matches the need to pull five related fields per image reliably. Option A undersells single-task mode's fit — it targets one narrow objective, making it a poor match for five simultaneous fields. Option D reintroduces fragile brittle parsing logic that Content Understanding is meant to replace. Option B would technically work but is inefficient and loses the benefit of one consistent schema, unlike the pro-mode pipeline in option C.

Text-to-image generation creates the still from the prompt, and image-to-video (video generation seeded with a reference image) carries the same subject and style into motion — this is the standard two-stage generative workflow. Content Understanding (option B) is an extraction/analysis capability for understanding existing content, not a generation service, so it cannot synthesize new stills or video. Option D misapplies speech-to-text, which has nothing to do with image generation from a prompt. Option A is a retrieval task, not generation, and does not meet the requirement to create new promotional media.

Translation services such as Azure Translator (or an LLM-powered flow) typically support language detection alongside translation, making them well suited to both routing by detected language and producing an English preview. Option B misapplies sentiment detection, which analyzes tone, not language identity or translation. Option D produces audio, not a text preview, and does not address routing. Option C extracts only product entities and provides no language detection or translation capability.

Multimodal reasoning from the audio can directly produce the symptom-category summary, while speech-to-text separately produces the full transcript needed for the medical record — these are complementary capabilities serving different outputs. Option A misapplies text-to-speech, which converts text to audio, the opposite direction of what's needed here, and it does neither summarization nor transcription. Option D assumes away the multilingual reality and does not perform summarization or transcription. Option C substitutes an unrelated visual capability for what is fundamentally an audio-content task.

Content Understanding analyzers that produce structured or markdown output are specifically designed to give downstream retrieval and generation steps a clean, grounded representation, reducing noise compared to raw extraction output. Option B retains OCR noise and artifacts, which is exactly the problem the scenario wants solved. Option D is unrelated to producing clean structured representations. Option C misapplies a video-specific capability to static document pages.

Layout-aware analysis informs chunking so that structural elements (tables, sections, clauses) are respected as boundaries rather than split arbitrarily by a fixed character count, directly addressing the described degradation in retrieval quality. Option A is unrelated — sentiment detection does not perform chunking or affect retrieval at all. Option D is a near-miss that may reduce the frequency of mid-structure splits somewhat but does not address the root cause, since a large fixed count can still split content awkwardly; it is not a considered structural fix. Option C would exclude a large portion of valid, useful content from the index.