A Microsoft Foundry project looks like a convenient place to experiment with an AI model, but its configuration becomes an operating contract once an application depends on it. Endpoints, deployments, connected storage, search indexes, evaluation records and agent tools each introduce different permissions and failure modes. A developer preparing for AI-103 needs to distinguish the resource that owns a capability, the project that organizes it and the application identity that invokes it. Otherwise a prototype may work under a broad portal sign-in and fail the moment it is deployed as a service.
The planning-and-management portion of Microsoft AI-103 includes Foundry deployment choices, CI/CD, monitoring, safety and security. Treat a project as a governed production boundary: decide what it owns, how it is deployed, which data it may access, how its configuration changes and how those changes can be audited.
Start with a resource map, not a portal sequence
Sketch a request from a user-facing application through Foundry model inference to any retrieval or action service. Identify the model deployment and its region, the project endpoint, the identity used by the client, the storage or search connection, and the place where logs are written. Record who can create a project and who only needs to invoke one deployed capability. This exercise exposes access questions that a step-by-step quickstart often hides.
A development project used for experiments may reasonably have looser data and release controls than production, but production should not inherit the experimenter’s secrets, test data, evaluation jobs and broad roles. Isolate dev and production through clearly separate resource and configuration boundaries. Use dedicated test fixtures where a customer record or sensitive document would otherwise be copied into a playground. The AI-103 official objective list asks developers to design Azure infrastructure rather than memorize a single project-creation route.
Understand who owns access to connected services
A Foundry project identity and an application workload identity may not be the same principal. If a search connection is configured through a project, determine which identity actually reads the search index and which security policies restrict it. Avoid using one service key for all development and production callers simply because it bypasses an RBAC setup step.
Consider a support chatbot that retrieves product manuals and customer-specific contracts. The search service may be accessible to the project, but user authorization must still restrict which contract rows can be returned to an individual caller. Permission at project level is not proof that every user has access to all documents. A sensible architecture combines resource RBAC, document-scoped metadata and an application-issued user authorization decision. Managed identities reduce persistent secrets, but they do not replace the destination service’s own permission model.
Configure network access around the complete path
A project is only as private as the dependencies it calls. A Foundry endpoint may be protected while a storage account, search index or diagnostic sink still accepts unwanted public traffic. Network planning must consider each ingress and egress path: the application’s runtime, model endpoint, connected search, storage, tooling and operator diagnostic access.
When a requirement calls for private connectivity, verify whether the chosen service, project configuration and region support private networking. Configure name resolution and routing alongside private endpoints rather than treating a private endpoint as an independent security checkbox. Azure Private Endpoints and DNS illustrate how a correct network interface can still be useless if the client resolves the wrong address. A network diagram should identify which DNS resolver answers each private name.
Choose a deployment and configuration strategy deliberately
A project can reference model deployments and agent definitions that evolve over time. Record deployment names and versions as application configuration, not as unexplained strings embedded in source files. Capture region, quota class, model version, safety settings, tool permissions and any data connections as part of the release record. Changes to one of those elements can affect correctness even when the application code remains unchanged.
Infrastructure-as-code can recreate much of the surrounding Azure configuration; application release scripts should promote compatible prompt or agent definitions and validate their dependencies. Do not assume every resource property or preview feature has the same deployment support. A release workflow should fail loudly if a required model, index or tool capability is unavailable in the target region. Bicep and ARM deployment decisions are useful precisely because declarative deployment still needs dependency ordering and permission checks.
Make project secrets and credentials replaceable
Store credentials in a managed secret solution when keyless access is not supported; scope and rotate them according to their risk. Do not place project keys in notebooks shared across a team, chat transcripts, issue trackers or CI logs. A leaked model key may create usage charges or disclose the application surface; a leaked search or storage key can expose data. Classify each credential by what it permits rather than by whether it happens to be called an API key.
Prefer managed identity and role assignment where possible. For local development, use an approved developer credential flow with limited environment access instead of copying a production key into a .env file. Test what happens when a principal loses one permission. A permission-denied response should identify the missing dependency in operational logs without leaking token contents. Incident response needs a way to revoke access, not just a documented instruction to rotate a key someday.
Connect traces, evaluations and costs before launch
A working endpoint proves only that one request returned a response. Before users arrive, attach monitoring that reveals model latency, token volume, errors, retrieval calls, tool actions and safety events. Decide which fields operators may log; raw prompts and retrieved documents can contain personal or confidential information. Use a correlation identifier across application, model and tool calls without turning that identifier into a secret-bearing token.
Foundry integrates with Azure monitoring and tracing capabilities. Microsoft’s agent tracing documentation explains how Application Insights participates in debugging hosted agents. An operations team should be able to answer: Did the client reach Foundry? Did model inference finish? Was retrieval empty? Did a tool deny an action? How much latency came from each step? If those answers require rerunning the customer’s prompt in production, observability was designed too late.
Treat the project as a release boundary
Production changes should have a describable unit: application version, model deployment, prompt or agent revision, search index schema, and linked tool versions. Deploy related changes through a compatible sequence. Updating an index schema without preparing the retrieval client can silently reduce answer quality; promoting a tool that expects a new argument can break an older agent definition.
Practice a controlled change: add a new document field to a retrieval index, update ingestion, test old and new document records, then promote the application that uses that field. Preserve a rollback path for each dependency. Rollback may mean reassigning an endpoint to an earlier deployment and retaining a compatible index rather than assuming source-control rollback alone restores service behavior. The goal is repeatability under change, not merely one successful deployment.
A release review should look at the permissions the deployed application actually uses, not only the administrator account that created it. Suppose a developer successfully calls a Foundry model in a sandbox using personal credentials, while production must use a managed identity. A successful sandbox invocation says nothing about whether production has the model-inference role, access to its search index, or permission to create agent tools. Record the production principal, target resource, role, and scope for every connection. Test with that principal before release; an application that works only under an engineer’s subscription-wide permissions is not ready for deployment.
For staging, intentionally deny one dependency at a time. Remove the storage read role and confirm ingestion fails visibly rather than delivering empty documents that the agent turns into invented answers. Block the search endpoint and verify that the response identifies unavailable evidence instead of claiming no matching policy exists. Revoke the write API permission and confirm the tool reports denial without requesting a more privileged model identity. These failures should have distinct trace identifiers, so the on-call team can separate identity, network and data freshness issues without reading sensitive prompts.
The deployment manifest should fix the model deployment name, agent version, retrieval index schema, evaluation set version and feature flags together. If only the model changes, previous evaluations may no longer cover output-format differences; if the index schema changes, old prompt assumptions about field names can silently break. A rollback plan should restore compatible sets of components, not merely revert the prompt string. Make one person or release pipeline responsible for promoting that tested set from staging to production.
The security approval also needs a cost boundary. A new summarization feature may preserve least privilege but send six times more context to each model call. Track expected token use per completed user task and establish alerts for sustained deviations. Quota exhaustion affects availability, so capacity approval belongs beside IAM, networking and data protection in the release checklist.
Troubleshoot by following dependency boundaries
Suppose a Python client gets a 403 when retrieving an answer. Confirm which request failed: model inference, search retrieval or a custom tool. Read the principal identity used at that hop, inspect its role scope and verify service-specific authorization. If the request times out instead, inspect endpoint health, private DNS, rate limits, retries and downstream tool duration before broadening permission assignments. These failures require different fixes and should not be collapsed into a generic “Foundry is down.”
A final deployment review should include the identity map, network path, allowed tools, model version, quota assumptions, monitoring owner, rollback procedure, and a test account with deliberately limited privileges. A Foundry project becomes production ready when these are explainable and verified. Clicking Create project is the beginning of that work, not its completion.