AI-103 Implement generative AI and agentic solutions: 429 practice questions

12 of the 429 Implement generative AI and agentic solutions questions in the Certsqill AI-103 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AI-103? Take the free 5-min readiness check →

1. Retrieve approved passages per question and require: Which implementation best meets these requirements?

1. Retrieve approved passages per question and require supported answers or abstention. ✓

   This uses retrieval-augmented generation to supply current document context without retraining. The application can require supported answers and acknowledge insufficient evidence.
2. Fine-tune the deployed model on current support documents, then request concise answers with citations in the prompt.

   Fine-tuning requires repeating model updates as documents change and does not itself establish that citations support the answer. Retrieval better addresses changing external knowledge.
3. Prompt the model to cite approved documents and report confidence, without supplying those documents as context.

   Prompt instructions alone do not provide current external information. The model may produce fluent but unsupported citations or answers.
4. Return JSON containing an answer, citations, and confidence, then validate fields before displaying the response.

   Structured output or JSON mode can shape response fields, but it does not retrieve current documents or prove factual support for citations.

Use RAG to retrieve current passages and instruct the model to answer only from supported evidence.

2. Configure the request to use structured outputs: Which implementation change addresses the missing prerequisit

1. Configure the request for JSON mode and parse the returned JSON before applying application validation.

   JSON mode targets valid JSON but does not provide the same schema-conformance guarantee required here. Parsing and validation do not replace structured-output configuration.
2. Define a function tool with the schema and return its call result to the model.

   Function calling describes tool parameters and enables application execution, but a tool schema does not itself impose the required response schema or guarantee conformance.
3. Add a retrieval step that supplies current business documents as additional model context.

   Retrieval can ground responses in external information, but it does not constrain the response to a JSON schema. Retrieval also requires separate inspection of relevance and support.
4. Configure the request to use structured outputs with the application’s supported JSON schema. ✓

   Structured outputs constrain supported model responses to the specified supported JSON schema. The application must still validate business rules and handle refusals or incomplete responses.

Use structured outputs with a supported JSON schema; JSON mode, retrieval and function tools solve different problems.

3. Define a function tool with inventory parameters: What targeted correction best satisfies the requirement?

1. Expand the system prompt with inventory examples and instruct the model to answer only when confident.

   Prompt guidance may influence refusal behavior, but examples cannot execute the secured function or supply authoritative current inventory data. Tool execution remains the missing step.
2. Define a function tool with inventory parameters; validate authorization, execute it, and return the result. ✓

   Function calling requires the model to request the tool and the application or configured framework to execute it. The application must validate arguments and permissions, return the result using the call identifier, and handle failures before reporting success.
3. Enable structured outputs with an inventory schema, then accept schema-conformant responses as completed lookups.

   Structured outputs can constrain response shape for supported models and APIs, but valid JSON does not perform the backend lookup, establish authorization, or prove factual accuracy.
4. Retrieve current inventory documents and ask the model to cite matching records.

   Retrieval can provide document context, but it does not execute the secured backend function or guarantee current inventory results. Diagnose retrieval and execution separately.

The application must execute requested function calls, enforce authorization, return results, and handle failures before claiming success.

4. Version prompts: Which implementation step best meets the requirement?

1. Configure function-calling schemas and deploy them, relying on tool definitions for consistent behavior across releases.

   Function schemas describe callable tools but do not replace versioned prompts, model configuration, integration tests, or deployment validation.
2. Recreate the portal experiment manually in each environment, selecting the model that currently appears most capable.

   Manual recreation and subjective model selection do not provide a reproducible release process or repeatable acceptance evidence.
3. Switch to JSON mode and store its responses as release evidence, without versioning prompts or integration tests.

   JSON mode concerns response formatting; it does not version the application or establish representative release tests.
4. Version prompts, model settings, and integration tests; validate capabilities, then promote the tested package. ✓

   This versions the key application artifacts, checks deployment prerequisites, and uses repeatable tests before promotion.

Version the application artifacts and tests, validate prerequisites, and promote the tested package.

5. Compare retrieval results with citations: What should the developer implement?

1. Enable JSON mode, then validate parsed objects against the assistant’s expected business fields.

   JSON mode can improve syntactic validity, but it does not establish document grounding, citation support, or factual accuracy. Business validation remains necessary but addresses a different requirement.
2. Repeat the successful portal demonstration, then use HTTP success as evidence that policy answers are reliable.

   A favorable demonstration and successful HTTP response do not measure groundedness or task quality. Representative held-out inputs and explicit acceptance criteria are required before release.
3. Add a policy-lookup function tool, then review whether the model requests that function.

   Function calling can expose a lookup operation, but a tool request does not diagnose whether retrieved documents support generated claims. Execution, authorization, argument validation, and failure handling are also required.
4. Compare retrieval results with citations, then test held-out questions for groundedness and unsupported-answer handling. ✓

   This separates retrieval success from answer-generation support and evaluates groundedness with representative cases. The application should acknowledge insufficient evidence instead of fabricating support.

Inspect retrieval evidence separately from generated-answer support, then evaluate groundedness on representative held-out inputs.

6. Configure retrieval against the current policy corpus so: What should you implement first to address the missi

1. Require citations in the system prompt and reject answers lacking citation evidence.

   Prompt instructions and rejection checks may improve behavior, but they do not retrieve external policy information or provide evidence to the model.
2. Configure retrieval against the current policy corpus so relevant documents are supplied as model context. ✓

   RAG requires relevant external information to be retrieved and provided as model context. Making the current corpus available to retrieval addresses the missing prerequisite.
3. Enable structured outputs with a policy schema, then validate returned fields against business rules.

   Structured outputs constrain response format, but schema conformance does not supply policy content or establish factual grounding.
4. Fine-tune the deployed model on historical policy examples, leaving the external corpus outside request-time context.

   Fine-tuning does not provide current external documents at request time. RAG grounds responses by retrieving relevant information without retraining the model.

The missing prerequisite is a retrieval path that supplies relevant, current policy documents as model context.

7. Enable structured outputs with the required schema: Which targeted correction best addresses the dominant defe

1. Enable structured outputs with the required schema, then handle refusals and incomplete responses. ✓

   Structured outputs target conformance to a supported JSON schema, while application validation still handles business rules and incomplete results.
2. Enable JSON mode and add a prompt example listing every required property and permitted status.

   JSON mode targets valid JSON but does not provide the same schema-conformance guarantee, so omitted properties can persist.
3. Define a function tool with extraction parameters and return its call result directly.

   Function calling describes a requested tool call; it is not the targeted mechanism for constraining ordinary extraction output to a JSON schema.
4. Add a retrieval index containing claim records and instruct the model to copy matching fields.

   Retrieval can provide external context, but it does not constrain the response to the required JSON schema.

Use structured outputs for the missing-property defect; separately validate factual and business correctness.

8. Version schemas: Which rollout step should you implement?

1. Enable JSON mode, confirm application parsing, and promote after messages meet the JSON requirement.

   JSON mode targets valid JSON, but parsing does not establish schema conformance, authorization, task completion, or representative release quality. Tool execution and acceptance testing remain necessary.
2. Version schemas, prompts, model settings, and integration tests; run representative acceptance cases before promotion. ✓

   This creates a repeatable release process and verifies tool behavior with representative cases before promotion. Application code must still execute calls, validate arguments, enforce permissions, and handle failures.
3. Define the function and parameter schema in the prompt; report completion without executing the requested function.

   A function schema describes a callable tool, but the application or configured framework must execute the request, return its result, and handle failures before reporting success.
4. Save the prototype configuration, demonstrate one successful production-tool call, and promote that configuration.

   A portal experiment and one favorable demonstration do not provide versioned prompts, configuration, integration tests, or representative acceptance evidence. This fails reproducibility and evaluation requirements.

Use versioned application artifacts and integration tests, then evaluate representative cases before promoting the tool-enabled release.

9. Check production identity: What should you do first?

1. Re-index the retrieved documents, tune ranking, and add freshness checks to improve response grounding.

   These are valid retrieval improvements, but retrieval already succeeded and cannot resolve the observed model-call authorization failure.
2. Enable structured outputs, validate the response schema, and apply business rules after generation.

   Structured outputs can constrain response shape, but they do not provide project authorization or correct a 403 inference request.
3. Define a function schema, validate its arguments, and authorize the application to execute the operation.

   Function calling is an appropriate tool pattern when needed, but a tool schema neither grants model access nor fixes the failed inference call.
4. Check production identity, project access, deployment target, and model support; then test the setup. ✓

   The 403 occurs after successful retrieval and indicates an inference access or configuration problem. Confirm the production identity, project access, deployment target, and required model or region support before releasing a repeatable configuration.

Successful retrieval isolates the failure to the subsequent model request; verify production access and deployment configuration first.

10. Test held-out grounding and relevance: Which implementation best satisfies this requirement?

1. Test held-out grounding and relevance; inspect freshness, access and answer support, and monitor after release. ✓

   A favorable score does not establish that documents remain current, relevant, accessible, or adequately support each answer. Held-out cases and post-release monitoring address these separate risks.
2. Use structured outputs with a JSON schema, validate business rules, and reject responses that fail conformance.

   Structured outputs can constrain supported responses to a schema and support business-rule validation, but schema conformance does not establish factual accuracy, document freshness, or grounding.
3. Add a function tool with parameter validation, enforce permissions, and return results using the call identifier.

   This is appropriate for safely handling tool calls, but function schemas do not address whether retrieved policy evidence is current, relevant, or sufficient for an answer.
4. Repeat the portal demonstration with a larger prompt, check one successful response, and release the application.

   A portal demonstration and successful HTTP response are not representative evaluation or task-success evidence. Release decisions require explicit criteria, held-out cases, and ongoing monitoring.

RAG improvement does not eliminate freshness, relevance, access, or answer-support risks; evaluate them separately on held-out cases and monitor them after release.

11. Refresh outdated policy documents: Which targeted correction should you implement first?

1. Refresh outdated policy documents, inspect retrieval relevance and access, and require insufficient-evidence responses. ✓

   This directly addresses the weak retrieval and groundedness scores while considering document freshness, relevance, and access. The response behavior should avoid unsupported answers when retrieved evidence is inadequate.
2. Enable structured outputs for supported models, validate the policy-answer schema, and reject nonconforming responses.

   Structured outputs can constrain JSON shape, but schema conformance does not improve document freshness, retrieval relevance, groundedness, or factual accuracy.
3. Deploy another available model, compare fluency on representative policy questions, and select the stronger result.

   Model comparison may investigate generation quality, but the table points first to retrieval and stale source data rather than fluency. It does not correct the RAG evidence pipeline.
4. Define a function-calling policy-lookup tool, validate requested parameters, and return its retrieved evidence.

   Function calling can request an application tool, but defining the tool does not itself refresh documents or ensure the returned evidence supports the answer.

Correct the evidence pipeline first: refresh stale sources, inspect retrieval, and handle insufficient evidence explicitly.

12. Verify model/API support and enable structured outputs: Which rollout step best satisfies these requirements?

1. Use a function-call schema, version the prompt, and test representative inputs; do not treat tool definitions as backend authorization.

   Function calling describes requested tools and parameters, not the response-schema mechanism needed here; it also introduces an unrelated authorization concern.
2. Use JSON mode, version the prompt, and test representative inputs; do not treat valid JSON as schema enforcement.

   JSON mode targets valid JSON but does not provide the same schema guarantee as structured outputs, so it misses a central release requirement.
3. Deploy through the portal, select a regionally available model, and release after one successful extraction request.

   A portal deployment and one successful request do not create a reproducible release process or establish schema conformance, business validation, and representative quality.
4. Verify model/API support and enable structured outputs; version artifacts and tests, check rules, handle refusals/incomplete results, and test held-out cases. ✓

   This uses structured outputs for schema conformance, verifies support, versions delivery artifacts, validates business meaning, handles incomplete outcomes, and evaluates representative held-out inputs.

Use supported structured outputs, version delivery artifacts, validate business rules, handle incomplete responses, and evaluate held-out cases.

Other AI-103 domains

• Plan and manage an Azure AI solution — 364 questions →
• Implement computer vision solutions — 169 questions →
• Implement text analysis solutions — 169 questions →
• Implement information extraction solutions — 169 questions →
• All 1300 AI-103 questions →