Choose the project and resource boundary deliberately

Start with the business workload rather than a long list of AI services. A proof of concept that generates short internal summaries may need one Foundry project and model deployment; a production assistant with company documents, tools and approval workflows also needs search, identity, logging and data ownership. Group resources according to deployment lifecycle, trust boundaries and operations. Identify what is shared across teams and what belongs to a single application so permissions and budgets do not leak from a pilot into production.

Microsoft Foundry terminology and APIs evolve, so verify the current project and resource model against the Microsoft Foundry overview. Confirm which services are available in the selected Azure region and subscription. A deployment may be syntactically correct and still fail because a model is not offered in that geography or quota is insufficient. Record resource names, region, subscription, owner, intended data classification and teardown date before provisioning.

For an actual setup, start with Microsoft’s Foundry resource-and-project quickstart. In a permitted training subscription, create or select a resource group, create the Foundry resource, create a project, and deploy one model offered in that region. Copy the project endpoint directly from the project overview. For a current Foundry project, the documented format is https://<resource-name>.services.ai.azure.com/api/projects/<project-name>, not a generic Azure resource endpoint. Save the resource group, region, project name, exact project endpoint and model deployment name as configuration values, not credentials.

Microsoft has renamed several project-scoped RBAC roles: Foundry User, Owner and related roles may appear under their earlier Azure AI names during rollout. Assign only the appropriate scope to the developer or workload principal, verify the effective role before requesting a token, and document who can create deployments separately from who can invoke them.

Choose a model before allocating production capacity

Start by defining what the app must return: language, format, modality, maximum useful context, latency target and acceptable price. Compare the capabilities of small and large models, code models and multimodal models with those requirements. For a classifier that returns one of a few labels, a large reasoning model may be wasteful. For an assistant analyzing images and documents, a text-only deployment cannot meet the input requirement. Model selection is an application decision that should be tied to a representative evaluation set.

Deployment modes, quotas, content filters and data handling vary by model and region. A team should validate these before treating a product preview as the production baseline. Record model family, deployment ID, version policy, access roles, cost controls and supported API. Avoid embedding a deployment name into dozens of files; give the application a single configuration layer that can be changed and rolled back predictably.

Configure least-privilege application identity

Separate the identity a developer uses to explore a project from the identity a deployed application uses to call the model or access a search index. Prefer supported Microsoft Entra authentication and managed identity rather than distributing a shared API key among web clients and developers. Grant the smallest data- or control-plane roles that complete the workflow. A model response permission does not automatically justify assigning subscription Contributor or letting an agent modify network settings.

Test the denial path deliberately. Remove or narrow the application’s role in a nonproduction environment and confirm that the request fails with a traceable authorization error. Also distinguish role failures from incorrect endpoint, expired token, firewall or private DNS problems. With managed identity for AI applications, document exactly which workload principal requests a token for which Foundry or search resource; a working token is not a substitute for the right authorization scope.

Use a deliberate negative-authentication test in the nonproduction project: try the same request under an identity that lacks the necessary project/model access, expect a denied request, and verify that neither a fallback API key nor a broader personal identity silently succeeds. Restore access only through the approved RBAC process. Preserve the error category and request correlation ID without logging tokens or key material.

Make Python clients resilient and configurable

A Python application should create its Foundry or model client from controlled configuration, resolve credentials through an approved identity provider, and separate the application interface from raw SDK responses. Specify timeouts and handle failures such as throttling, malformed requests, unavailable deployments and invalid tool results. Retry only where the operation is safe to repeat; an automatic retry of a write-capable tool can duplicate a purchase or case update. Use idempotency controls when an action can mutate external state.

Do not scatter model-specific object structures through business logic. Write a small adapter for generation, agent invocation, retrieval and evaluation so the application can test each dependency and upgrade SDK versions with a limited change surface. Keep a fixture that represents a successful answer and an explicit error case. When an API or SDK changes, run those contract tests before releasing to production rather than relying on a developer’s last interactive notebook session.

A model interface should distinguish three classes of failure: inputs rejected by the application, requests rejected by Azure, and an accepted model response that does not satisfy business rules. Validate requested output shape and length before submission, log rate-limit guidance when Azure throttles a request, and require a schema check before an application acts on a generated result. These differences determine whether to show a user validation message, retry with backoff or send a record for review. If one generic exception handler hides all three, the team cannot measure why the application fails.

Keep a small contract-test collection that includes authentication failure, nonexistent deployment, a slow response and a structured result missing a required field. Run it after an SDK or model deployment update, because some behavioral changes are visible only to the consuming application. Source-code unit tests can verify adapter logic, while a limited integration test verifies the actual deployed model and identity path. Treat the integration environment’s cost and cleanup as part of test design.

Microsoft’s current Foundry SDK Python quickstart uses Azure AI Projects 2.x; examples for the older 1.x project API are not interchangeable. Use Python 3.10 or later in a virtual environment. Install the Foundry Projects 2.x SDK, its OpenAI client dependency and Azure Identity with python -m pip install "azure-ai-projects>=2.3.0" "openai>=3.0.0" azure-identity. The version constraints are quoted because an unquoted > can be interpreted as shell redirection. Authenticate locally with az login or use an appropriately scoped managed identity in Azure. Copy the project endpoint and your actual deployment name into PROJECT_ENDPOINT and MODEL_DEPLOYMENT. The following minimal call deliberately contains no secrets:

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)
client = project.get_openai_client()
result = client.responses.create(
    model=os.environ["MODEL_DEPLOYMENT"],
    input="Reply with READY, without any other words.",
)
if not result.output_text or not result.output_text.strip():
    raise RuntimeError("Foundry smoke test returned no text")
print(result.output_text)

A nonempty response confirms that the endpoint, credential and deployed model were usable for this request; it does not establish a production-grade safety policy. Record the exact package version, model deployment and observed output. On a deliberately wrong deployment name, expect a failure rather than making up a reply. Run this test only with an authorized Azure subscription; this article’s code has been syntax-checked offline, not executed against an Azure project.

Attach retrieval and agent tools through explicit permissions

Applications needing organizational knowledge must decide where that knowledge lives, how it is indexed and how access filtering works. An agent may retrieve a policy document but should not automatically inherit the caller’s permission to read every underlying file. Preserve document IDs, version timestamps, ownership and allowed scopes. The application should make a transparent distinction between trusted system instruction and lower-trust retrieved content that may contain hostile prompts.

Tools need schemas, argument validation, authentication and a defined failure contract. Separate read-only tools from high-impact actions, and require approval for irreversible or financially consequential steps. If an API returns unexpected fields, the agent should not convert that ambiguity into a guessed value. In tool calling in Microsoft AI agents, a schema-valid argument must still pass the business-authorization check before a write or financial action is executed.

Build deployments through repeatable CI/CD

Store infrastructure definitions, configuration templates, prompt assets and evaluation cases under version control. Avoid hard-coding secrets or personal data in the repository. A release pipeline should validate resource configuration, run code and policy checks, deploy a candidate configuration, evaluate answer quality and authorization behavior, and then promote or roll back according to measured results. A team should be able to reconstruct why a particular prompt, model and search configuration was used on a given day.

Use separate development and production identities and deployment scopes. A successful canary request does not prove production readiness if the safety filters, search index or tool permissions differ. Check deployment versions, quotas and observed token usage at release time. Feature flags or deployment switching can help, but the rollback path must include prompts, model settings, tool schemas and indexes when those components change together.

Instrument useful monitoring rather than every event

Capture request IDs, deployment versions, token usage, latency by stage, tool failures, retrieval relevance and safety outcomes without storing unrestricted private prompts in logs. Traces should let an operator distinguish a slow model from a slow search query and a refused request from an unauthorized tool action. Decide which fields may contain sensitive data, who can view them and how long they are retained. Keep logs informative enough for debugging but limited enough to meet privacy and security requirements.

Create alerts for service availability, error rate, rate-limit spikes, cost anomalies and evaluation regressions tied to an owner and an action. Test a throttled request and an unavailable search backend to ensure the right alert fires. Effective AI application observability correlates model requests, retrieval spans and tool failures without retaining raw sensitive prompts by default.

Prove recovery and operational handoff

Document how to redeploy the model client, restore a known-good configuration and recover an index or tool dependency when a release fails. Identify the on-call owner, approved emergency actions, support contact and test procedure. A deployment that depends on one engineer remembering an endpoint URL is not an operable service, even if it passed a demo. Rehearse rollback in the same kind of environment used for deployment testing.

For the Microsoft AI-103 exam, the durable model is requirement, resource/project, model, identity, Python client, retrieval/tools, deployment pipeline, observation and tested recovery. Keep a dated runbook and small evaluation suite so changing model behavior or SDK APIs does not require rediscovering the application’s trust boundaries.

Finish by removing any temporary model deployments, sample keys, test role assignments and resources that are no longer needed. When all lab assets belong exclusively to a disposable resource group, an authorized owner can delete that group; do not delete shared resources to simplify cleanup. Retain the short runbook, source revision, deployment identifiers and test outcomes so the setup can be reproduced safely without reconstructing access from someone’s personal account.