AI-103: Developing AI Apps and Agents on AzureDemo

By Microsoft · Browse Mode
About the Exam

This exam is for Azure AI engineers and developers who build, manage, and deploy agents and AI solutions using Microsoft Foundry. It expects experience developing apps with Python and familiarity with general AI, generative AI, and Azure services. Passing demonstrates you can plan and manage Azure AI solutions and implement generative AI, computer vision, text analysis, and information extraction solutions.

Exam Topics

  • Plan and manage an Azure AI solution25–30%
  • Implement generative AI and agentic solutions30–35%
  • Implement computer vision solutions10–15%
  • Implement text analysis solutions10–15%
  • Implement information extraction solutions10–15%

How to Use This Practice Exam

  1. Browse — Read each question, select your answer, and reveal the explanation.
  2. Exam Mode — Simulate real exam conditions with a timed session and score report.
  3. Learn Mode — Spaced repetition schedules questions you struggle with for long-term retention.

Download the Full Exam PDF

Get every question and answer in a clean, printable PDF built for offline study. Purchase once, keep permanent access, and re-download the latest version anytime.

Get PDF
Learn More

Last updated August 10, 2026 at 11:31 AM

Topic filter
Retired questions
Question sort

QuestionQ1

Implement generative AI and agentic solutions

You have a Microsoft Foundry project that contains an agent. The agent accepts user-uploaded screenshots and relies on a multimodal chat model. Some of the screenshots contain potentially malicious embedded text. You need to prevent a prompt injection attack and ensure that third-party content is treated as lower trust. How should you configure Prompt Shields for document attacks?

Select
Prompt shields action:
Additional mitigation:
Explanation

Prompt Shields for document attacks inspects content that originates outside the user's direct input, such as text embedded in an uploaded image or document, for indirect (cross-prompt) injection attempts. Setting the shield's action to Block causes the service to block the request when it detects embedded instructions that attempt to hijack the model, which is what stops the prompt injection attack. Spotlighting is the complementary Prompt Shields capability that marks ingested third-party content, such as text extracted from a screenshot, as distinct from and lower-trust than the user's and system's own instructions, so the model does not treat embedded text as an authoritative command, which directly satisfies the requirement to treat third-party content as lower trust. A custom blocklist only matches known bad strings, and running OCR first does not itself establish provenance or trust separation.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ2

Implement generative AI and agentic solutions

You need to recommend a plan for creating a customer support agent using the Microsoft Foundry Agent Service. The agent must meet these requirements:

  • Retain user preferences across multiple conversations.
  • Let users provide contextual grounding by uploading documents directly during a chat.

Which Foundry capability should you recommend for each requirement?

Select
To retain user preferences across conversations, use:
To enable users to provide contextual grounding during chats, use the:
Explanation

Agent memory that uses persistent storage keeps curated, long-lived information such as user preferences outside of any single conversation thread, so it can be recalled in later sessions and satisfies the requirement to retain preferences across conversations; plain conversation history and orchestration-managed session context are scoped to the current thread or session and do not persist afterward. The File search tool lets users attach documents directly during a chat and grounds responses in that uploaded content on the fly, whereas the Azure AI Search tool queries a pre-built, pre-indexed search index rather than files uploaded in the moment, and the code interpreter tool executes code rather than performing document retrieval.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ3

Implement text analysis solutions

You have an application named App1 that uses Azure Speech in Foundry Tools to transcribe live calls.

Transcript segments frequently contain both English and Spanish. App1 sends each segment to Azure Translator in Foundry Tools for translation into another language, but mixed-language segments sometimes produce incomplete or incorrect translations.

You need to reduce translation errors, ensuring that the entire transcript is translated successfully.

What should you do before sending the segments to Translator?

  • A Use document translation to translate the entire transcript as a single document.
  • B Split the mixed-language segments into single-language segments and translate each segment separately.
  • C Enable automatic language detection for the translation request.
  • D Specify English as the source language in the translation request for all the segments.
Explanation

Azure Translator performs best when a request's source content is a single language, because language identification and translation both operate on the assumption of one dominant source language per request; a segment that mixes English and Spanish causes the service to mis-detect or mis-translate the portion in the non-dominant language. Splitting each mixed-language transcript segment into single-language sub-segments before translating each one separately ensures every portion is translated correctly and the entire transcript is translated successfully. Treating the whole transcript as one document does not resolve mixed-language content within a single passage, enabling automatic language detection still only selects one source language per request, and forcing English as the source language for every segment would mistranslate the Spanish portions.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ4

Implement generative AI and agentic solutions

You have a Microsoft Foundry project named Project1 that contains an agent, and the agent uses an OpenAPI 3.0 specification to call an external weather service.

The weather service requires a key that must be passed in an HTTP header, and the key value is stored as a connection in Project1.

You need to ensure that the key value from the connection is automatically included whenever the OpenAPI tool is invoked.

What should you configure in the OpenAPI specification?

  • A a header parameter defined for each operation
  • B an Azure Key Vault connection
  • C an API key security scheme
  • D a Bearer token security scheme
Explanation

When an OpenAPI 3.0 specification declares a securitySchemes entry of type apiKey (a key passed in a header, query, or cookie), the Foundry OpenAPI tool binds that scheme to the connection associated with the tool and automatically injects the connection's stored key value into every matching request, without the caller supplying it manually. Defining a plain per-operation header parameter would require the value to be supplied at invocation time rather than sourced automatically from the connection, an Azure Key Vault connection is not how the OpenAPI tool authenticates outbound calls, and a Bearer token security scheme is intended for OAuth/JWT bearer tokens rather than a static API key header.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ5

Implement generative AI and agentic solutions

You have a Microsoft Foundry project that contains an agent. You use a GitHub Actions workflow for CI/CD. You need to configure the workflow to automatically evaluate the agent whenever a pull request (PR) is created, and to prevent branches from merging if the evaluation results do not meet the defined thresholds.

Select
Authentication method:
If the evaluation results are NOT met, configure the workflow to:
Explanation

GitHub Actions workflows should authenticate to Azure using the Azure Login action configured for OpenID Connect (OIDC) federated credentials, which lets the workflow obtain a short-lived Microsoft Entra ID token without storing a personal access token or a managed-identity secret in the repository. This is the recommended secretless authentication pattern for GitHub-hosted runners that need to call Azure resources such as a Foundry project. To gate a pull request on the evaluation outcome, the workflow step that runs the evaluation must be configured to fail (return a non-zero exit code) when the results do not meet the defined thresholds; when the repository's branch protection rules require that check to pass, a failing step blocks the PR from merging. Sending an alert or locking the target branch does not tie the PR status check to the evaluation result, so neither action prevents the merge.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!
Know a question that should be here? Contribute to this exam
Back home