Planning Azure AI solutions for Microsoft AI-103 Developing AI Apps and Agents on Azure: Concepts, Scenarios, and Study Priorities

Practice Exams:

View All

Planning is the part of AI engineering that determines whether a promising prototype can become a dependable Azure solution. In AI-103, planning is not a paperwork phase that happens before the “real” technical work. It includes model and service selection, retrieval and indexing choices, infrastructure, identity, networking, deployment, quotas, cost, monitoring, responsible-AI controls, and the operational path from development to production. The current skills measured, effective April 16, 2026, place planning and managing an Azure AI solution at 25–30% of the exam, making it one of the two largest skill areas.

The exam does not require one universal architecture. Instead, it expects you to choose components based on requirements and constraints. Two applications that both “use generative AI” may need completely different solutions because one handles public marketing copy and the other handles confidential legal documents. One may be latency-sensitive; another may prioritize quality. One may need retrieval; another may need deterministic database queries. One may need an agent that chooses among tools; another may be safer as a fixed workflow.

This guide focuses on the reasoning process behind those choices. If the architecture still feels fragmented, the AI-103 complete guide provides the exam-wide frame; the AI-103 objectives are then useful as a boundary check while you practice the planning method below.

Start with the workload, not the model catalog

A weak planning process begins by choosing a model and then trying to fit the application around it. A stronger process begins with the work the system must perform.

Describe the workload in verbs. Does it summarize, classify, extract, generate, search, answer, recommend, translate, transcribe, reason across several sources, call APIs, or take actions? What inputs does it receive: text, documents, images, audio, video, structured records, or a mixture? What outputs must it produce: free text, a schema, a citation-backed answer, a tool invocation, an image, a workflow decision, or a side effect in another system?

Then add quality constraints. Is factual grounding mandatory? Can the system refuse when evidence is missing? Does output need to be deterministic enough for downstream automation? Is a human expected to review it? What level of latency is acceptable? Is cost a dominant concern? Does the task need a large model, or can a smaller model meet quality and latency requirements?

This requirement-first approach makes service selection much easier. A simple extraction task may not need a general-purpose agent. A question-answering system over enterprise documents may need retrieval and grounding. A workflow that chooses among unpredictable tools may justify agentic orchestration. A fixed approval sequence may not.

Decompose the solution into responsibilities

Before naming Azure services, divide the architecture into responsibilities. A typical AI application may have the following layers:

experience layer: web app, mobile app, Teams surface, API, or another client;
application layer: request handling, validation, session state, deterministic business rules, retries, and response formatting;
AI layer: model inference, prompting, multimodal reasoning, or generation;
retrieval layer: indexing, search, filtering, reranking, and grounding context;
agent or orchestration layer: workflow sequence, tool selection, memory, and approvals;
tool layer: APIs, databases, business systems, custom functions, or Foundry tools;
data layer: source content, operational data, indexes, extracted representations, and logs;
security layer: authentication, authorization, managed identities, private networking, role policies, and secret management;
operations layer: deployment, versioning, evaluation, monitoring, tracing, quotas, cost, and incident response.

Not every application needs every layer, but writing them down exposes hidden assumptions. For example, teams often say “the agent will access the CRM” without specifying whether the agent itself has an identity, whether the application calls the CRM on its behalf, whether the user’s permissions should be honored, or whether the tool should expose only a narrow operation. Planning forces that ambiguity into the open.

Model selection is a constraint problem

The current blueprint expects candidates to choose appropriate models for different tasks, including large language models, smaller models, multimodal models, and Foundry tools. The correct choice is rarely “use the most capable model.”

Compare models against task requirements. Consider modality, reasoning complexity, response quality, structured-output reliability, context requirements, latency, throughput, deployment availability, cost, and safety. A high-capability model may be justified for complex reasoning but wasteful for simple classification. A smaller model may be preferable for high-volume extraction if it meets the quality threshold. A multimodal model is useful when visual or audio context matters, but it may be unnecessary if OCR plus text processing is more controllable for a document task.

Planning should also include fallback behavior. If a preferred deployment is unavailable or rate-limited, does the application retry, queue the request, use a lower-cost model, or return a controlled message? A design that assumes unlimited capacity is incomplete.

For study, practice model selection by writing the decision criteria before looking at product names. This trains you to recognize the governing constraint in exam scenarios.

Retrieval planning begins with the source of truth

When an application must answer from organizational knowledge, the first retrieval question is not “vector or hybrid?” It is “what content is authoritative, who can access it, and how quickly does it change?”

Inventory the sources. Are they documents, database rows, websites, images, audio, or mixed media? Do they have permissions that must be preserved? Are there multiple versions? Is freshness measured in minutes, days, or months? Are there legal retention rules? Can content leave a network boundary? Does the application need exact lookup, conceptual similarity, or both?

Only then design ingestion and indexing. Decide whether content requires OCR, layout analysis, enrichment, or Content Understanding. Decide how to chunk it, what metadata to retain, which fields can be filtered, and how updates propagate. Retrieval quality depends heavily on these choices.

Vector search is useful for semantic similarity. Keyword or lexical search can be strong when exact terms matter. Semantic ranking can improve relevance. Hybrid approaches combine signals. Metadata filtering protects scope and improves precision. None of these choices should be treated as magic. The best retrieval method depends on the query, content, and required controls.

Plan evaluation before rollout. Use representative questions with expected evidence. Track whether the right chunks are retrieved, not only whether the final answer sounds good. If the retrieval layer is weak, generation quality is built on bad context.

RAG planning should separate evidence from generation

Retrieval-augmented generation works because the application provides model context from controlled sources. That creates two quality problems: retrieving the right evidence and generating an answer that uses it correctly.

Plan metrics for both. Retrieval can be evaluated for relevance, coverage, freshness, and permission correctness. Generation can be evaluated for groundedness, factual accuracy, completeness, refusal behavior, and style. A single “answer quality” score hides where the system failed.

Plan for unsupported questions. If the application cannot find enough evidence, should it refuse, ask for clarification, or provide a clearly labeled general answer? A system that is forced to answer everything creates unnecessary fabrication risk.

Plan provenance. Users in regulated or high-trust environments may need to know which source supported the response. Even when visible citations are not required, the system may need internal traceability for auditing and investigation.

Finally, plan index health. Monitor ingestion failures, stale documents, broken enrichment, search latency, and relevance regressions. A RAG system is partly a data pipeline, so operational ownership must include the retrieval layer.

Decide whether you need a workflow or an agent

Agentic design is attractive because it can handle flexible requests, but flexibility is not always an advantage. Planning should distinguish deterministic orchestration from agentic orchestration.

Use a deterministic workflow when the sequence is known, rules are stable, and side effects require precise control. A three-step document validation process with mandatory approvals is usually easier to reason about as a workflow. The model can still participate inside individual steps without controlling the entire sequence.

Consider an agent when the system must interpret a broad request, choose among tools, decide what information to gather, or adapt its plan dynamically. Even then, constrain the agent. Define its role, tool descriptions, allowed operations, memory behavior, stopping conditions, and approval boundaries.

When the scenario depends heavily on agent behavior, the AI-103 generative AI and agents guide gives the detailed mechanics. For planning, the immediate question is simpler: what decision-making flexibility does the workload actually require?

Tool design is part of architecture

A tool is not just an API connected to an agent. It is an authority boundary.

Prefer narrow, explicit tools. “Manage customer account” is dangerously broad. Separate operations such as “get account status,” “calculate eligible credit,” and “submit credit request” create clearer schemas and permissions. Read-only and side-effecting actions should be distinguishable.

Define validation. Tool parameters should be checked before execution. The downstream API should enforce authorization rather than trusting the model. Idempotency may matter for operations that could be retried. Logging should record what was requested, what identity performed it, what result occurred, and whether a human approved the action.

Plan error behavior. If a tool fails, should the agent retry, choose another tool, ask the user, or stop? Unlimited retries can create cost and side effects. Silent fallback can hide important failures. The correct behavior depends on the business process.

Identity should be drawn on the architecture diagram

Managed identity and keyless credentials are not implementation trivia. They change risk and operations. Every connection in your diagram should have an identity and an authorization policy.

Ask which principal accesses storage, search, model endpoints, databases, and external APIs. Decide whether user identity should flow through or whether the application should use a service identity. Apply least privilege. Separate development and production identities. Avoid sharing credentials across unrelated components.

A useful design exercise is to remove all connection strings and keys from your diagram. Can the supported Azure components authenticate using managed identities or other keyless mechanisms? If a secret is unavoidable for an external system, where is it stored and rotated? Who can read it?

For agents, pay special attention to the mismatch between the user and the agent’s tool identity. A user asking a question should not automatically gain every permission available to a backend service. Tool-level authorization should enforce what the caller is allowed to do.

Network planning matters when data is sensitive

An AI solution may be logically secure but still violate network requirements. Determine whether services can be publicly reachable, whether private endpoints or private networking are required, and how clients, applications, data sources, and AI services connect.

Private networking introduces operational complexity: DNS, routing, deployment agents, build pipelines, monitoring, and developer access all need a path. Plan those dependencies rather than enabling isolation at the end and discovering that the deployment pipeline can no longer reach the service.

Network controls also do not replace identity. A service being reachable only from a private network does not mean every caller on that network should have the same authorization. Defense in depth combines network and identity boundaries.

Plan deployment as a lifecycle, not a one-time event

The blueprint includes deployment choices and integration with CI/CD. Production AI systems change in more dimensions than ordinary application code. You may version application code, prompts, model deployments, tool schemas, retrieval indexes, safety settings, evaluation datasets, and configuration.

Plan how changes move through environments. Development should allow experimentation without exposing production data unnecessarily. Test environments should support repeatable evaluation. Production changes should be observable and reversible where possible.

A model change can alter quality even when application code is unchanged. An index schema change can break retrieval. A prompt revision can change tool selection. Therefore, deployment pipelines should be accompanied by evaluation gates appropriate to the system.

For study, create a simple release checklist: what changed, what evaluation ran, what configuration was deployed, what metrics should be watched, and how to roll back. This makes CI/CD more concrete than memorizing that it is an objective.

Quotas and rate limits are architecture constraints

AI workloads often encounter capacity limits sooner than traditional web APIs. Planning must account for expected request rate, token use, concurrency, model quotas, downstream tool limits, and burst behavior.

Estimate demand. A thousand user requests may become more than a thousand model calls if each request includes retrieval, agent planning, tool calls, and final generation. Multi-agent designs can multiply calls further. Long contexts increase token consumption and latency.

Plan graceful behavior. Use backoff and retry for transient limits, but cap retries. Queue work that does not require immediate response. Reduce unnecessary context. Cache stable results only where correctness permits. Choose models that meet the task rather than always using the most expensive option. Monitor quota consumption before incidents occur.

Cost and capacity are linked. A design that uses five model calls per user turn may be acceptable at pilot volume and unsustainable at enterprise scale. AI-103 planning scenarios may reward the option that meets requirements with less complexity or cost.

Responsible AI belongs in the initial design

The current AI-103 blueprint explicitly includes safety filters, guardrails, risk detection, content moderation, responsible-AI evaluation, auditing, provenance, approval workflows, oversight modes, constraints, and tool-access controls.

Do not add these after functional testing. Identify harms and misuse cases during requirements work. What could the system generate incorrectly? What sensitive information could it expose? What harmful content might users submit? Could an image contain hidden text that attempts indirect prompt injection? Could an agent take an unintended action? Could biased or incomplete source data affect decisions?

Then map controls to layers. Content filters can reduce unsafe generation. Retrieval permissions can prevent exposure of unauthorized data. Tool authorization limits side effects. Human approval can protect high-impact actions. Trace logs and provenance support investigation. Evaluation datasets can test known risk cases before release.

A recurring exam principle is that prompts are not the only control. Use policy, identity, deterministic validation, approvals, and monitoring where stronger enforcement is required.

Observability should answer engineering questions

“Enable monitoring” is too vague. Plan the questions your telemetry needs to answer.

For a generative application: which model was called, with what latency, how many tokens were used, what safety signals fired, and what quality metric changed? For RAG: which documents or chunks were retrieved, how long retrieval took, whether the index is fresh, and whether relevance changed? For agents: which tool was selected, with what parameters, what result returned, how many steps occurred, and where the run failed? For infrastructure: what quota or rate-limit events occurred? For cost: which workload, tenant, model, or feature is consuming resources?

Tracing is especially important in multi-step AI systems because a user-visible failure may originate several calls earlier. A final bad answer can be caused by stale ingestion, bad retrieval, malformed tool output, or prompt state. Without end-to-end correlation, teams inspect components in isolation.

Scenario: internal policy assistant

Consider an assistant for employees that answers HR and compliance questions from internal documents.

The source documents are authoritative and change weekly. Access differs by department. The application must not expose restricted content. Unsupported questions should not be answered confidently. Usage is high during annual enrollment.

A strong plan starts with content inventory and permissions. The ingestion pipeline must retain metadata that supports access filtering and versioning. The retrieval layer must enforce the user’s permitted scope before evidence reaches the model. Groundedness evaluation should include questions with and without valid evidence. The application should have a refusal or escalation path.

Identity and network requirements determine whether managed identity and private networking are needed. Monitoring should include ingestion freshness, index health, retrieval relevance, answer quality, latency, and rate limits. Peak-load testing should occur before enrollment season.

Notice how the model is only one part of the plan. The difficult requirements are data authorization, freshness, retrieval, and operations.

Scenario: service agent with business actions

Now consider an agent that can read customer information, search product guidance, and create a return request.

The plan should separate read-only knowledge retrieval from side-effecting operations. Tool schemas should be narrow. The agent may gather information and propose a return, but the application can require user confirmation before submission. If high-value returns need supervisor approval, that rule should be enforced in the workflow or backend service.

The tool identity should have only required permissions. Parameters should be validated. Duplicate submissions should be prevented. The trace should record the tool call and result. Evaluation should test not only answer quality but also tool selection, argument accuracy, refusal behavior, and approval compliance.

This scenario is a good study pattern because it combines generative AI, agents, identity, governance, and observability.

Scenario: multimodal inspection workflow

A manufacturing company wants workers to upload equipment photos and spoken notes. The system should identify visible conditions, transcribe the note, retrieve maintenance documentation, and suggest the next diagnostic step.

Planning begins by separating modalities. Speech processing handles the note. A multimodal model or vision capability interprets the image. Retrieval brings in controlled maintenance content. Generation combines evidence into a recommendation.

Safety and accuracy matter because the recommendation affects physical equipment. The system may need to avoid giving instructions when evidence is insufficient. Images can contain sensitive surroundings, so retention and access rules matter. Latency may be important in the field. Offline or degraded behavior may need consideration.

Evaluation must include representative images, noisy speech, incomplete evidence, and unsafe edge cases. This is more realistic than testing a handful of perfect examples.

Study priority: learn trade-offs in pairs

Planning knowledge is easier to retain when studied as trade-offs rather than isolated definitions. Compare large and small models; vector and hybrid retrieval; deterministic workflow and agent; single agent and multi-agent; application identity and delegated user identity; public and private networking; prompt control and policy control; free-form output and structured output; real-time response and queued processing.

For each pair, write the requirement that would favor one side. Do not assume one option is universally “best.” Exam questions often provide a constraint specifically to make one trade-off decisive.

Study priority: practice architecture reviews

Take a solution diagram and review it from five perspectives.

First, functional: does it accomplish the required task? Second, data: where does information come from, where is it transformed, and how fresh is it? Third, security: what identities and permissions exist, and what network paths are allowed? Fourth, reliability: what happens when services fail or throttle? Fifth, AI quality and safety: how are outputs evaluated, monitored, grounded, and constrained?

This review method creates a reusable checklist without turning every solution into the same architecture. It is particularly useful for AI-103 because the exam frequently asks for the best change to an existing design rather than asking you to build from zero.

Study priority: reason from symptoms to layers

Planning and troubleshooting are connected. If you know which layer owns a responsibility, you can localize failures faster.

If unauthorized data appears in answers, inspect retrieval permissions, tool authorization, data filters, and identity—not just the prompt. If answers are outdated, inspect ingestion and index freshness. If the model returns correct content but an application fails, inspect schema validation or downstream integration. If an agent repeatedly chooses the wrong tool, inspect tool descriptions, routing, and overlapping responsibilities. If latency spikes, separate model time, retrieval time, tool time, and orchestration overhead.

A candidate who can map symptoms to layers is much harder to distract with plausible but irrelevant options.

A planning checklist for exam scenarios

When you encounter an unfamiliar AI-103 scenario, use a short sequence:

Define the required outcome in one sentence.
Mark hard constraints: security, latency, cost, modality, residency, approval, or integration requirements.
Identify the authoritative data sources and how fresh they must be.
Decide whether the task needs retrieval, deterministic logic, generative reasoning, tools, or an agent.
Identify every side effect and who is authorized to perform it.
Choose model or service categories based on the task rather than familiarity.
Add identity and network boundaries.
Add deployment and lifecycle considerations.
Add evaluation, safety, tracing, and monitoring.
Check whether a simpler design satisfies the same requirements.

The tenth step is important. AI architectures can become unnecessarily elaborate. A smaller design is often easier to secure, evaluate, operate, and explain.

Planning is the skill that connects the entire exam

The planning domain may be listed as one section of AI-103, but its reasoning extends into every other area. Generative AI choices depend on deployment, identity, and evaluation. Agents depend on tool boundaries and approval controls. Computer vision and speech depend on modality, privacy, and latency. Information extraction depends on ingestion, indexing, and retrieval quality. Every domain eventually reaches operations.

That is why planning should be studied through complete scenarios rather than as a list of Azure settings. The goal is to look at a requirement and see a system: data, model, retrieval, orchestration, tools, identity, safety, deployment, and telemetry working together.

When that mental model becomes automatic, AI-103 questions become less about remembering product names and more about selecting the design that best satisfies the stated constraints. That is the planning skill the exam is trying to measure.

Plan for change because AI systems are never static

A production AI solution changes even when the business requirement stays the same. Source documents are updated. Tool APIs evolve. Model deployments change. Safety settings are tuned. Search indexes grow. New departments gain access. Usage patterns shift from a pilot group to thousands of users. Good planning therefore includes change management from the beginning.

Separate the things that can change independently. Application code, prompts, model deployment settings, retrieval schemas, tool definitions, evaluation datasets, and access policies should not be treated as one undifferentiated release. If a prompt changes, you should be able to identify that change and compare quality before and after it. If an index schema changes, you should know which retrieval tests must be rerun. If a tool adds a new required parameter, the agent schema and validation logic must move together.

Versioning is useful only when it supports diagnosis. Imagine users report that answers became less grounded on Tuesday. A useful operational record can tell you whether a new model deployment, prompt, source-content batch, chunking rule, search configuration, or safety policy changed around that time. Without that record, incident response becomes guesswork.

Plan retirement as well as deployment. Old indexes, unused model deployments, stale credentials, abandoned test resources, and obsolete tool versions can increase cost and attack surface. A mature design includes ownership for cleanup and for reviewing resources that were created during experimentation.

This perspective is valuable for exam preparation because scenario questions sometimes describe a system that worked in development but behaves poorly after a change or at scale. The right answer is often not “use a more powerful model.” It may be better release control, observability, data-pipeline health, or capacity planning.

Plan the human operating model around the technology

AI systems cross team boundaries. The current Microsoft audience profile explicitly places the Azure AI engineer alongside business stakeholders, solution architects, data scientists, DevOps engineers, and cloud security engineers. That collaboration is not incidental. Different failures have different owners.

Define who owns source-data quality, search-index freshness, model deployment, tool APIs, identity policies, safety review, evaluation datasets, and production incidents. An alert without an owner is not an operational control. A human approval step without a defined approver is not a governance process. A safety policy without a process for investigating events is only configuration.

In exam scenarios, organizational detail can be a clue. If a requirement says security teams manage network boundaries while developers manage application code, favor a design that respects those responsibilities. If a business reviewer must approve high-impact outputs, build that review into the flow rather than assuming post-hoc monitoring is enough.

Planning is therefore both technical and operational. The architecture should show not only which service performs a task but also which control protects it, which signal reveals failure, and which team can act when the signal changes. That level of thinking separates a demo from a production solution and makes the planning domain much easier to reason about under exam pressure.

Rehearse planning under changing constraints

A strong final exercise is to take one Azure AI solution and redesign it three times. Begin with a private internal assistant that answers from approved documents. Then add a requirement for external users, which changes identity, data exposure, rate-limiting, and safety decisions. Next add tool execution, which makes authorization, validation, audit evidence, and failure recovery more important. Finally impose a strict latency or cost target and decide whether the retrieval pattern, model choice, deployment configuration, or amount of agentic reasoning should change.

Do not judge the exercise by whether the architecture looks sophisticated. Judge it by whether every added component answers a stated requirement. If a feature remains in the diagram after its requirement disappears, challenge it. This is useful AI-103 preparation because planning questions often reward the smallest defensible architecture that satisfies identity, data, safety, quality, deployment, and operational constraints together. The ability to revise a design when one constraint changes is stronger evidence of readiness than memorizing a fixed reference architecture.