Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-100 Prerequisites

Make agent delivery reproducible and reviewable

Completed by the knowledge check

Learning objective

Apply foundational Git, testing, environment, container, and infrastructure-as-code practices.

Core idea

A reproducible release identifies more than the application source. It also identifies dependencies, configuration, container artifacts, and infrastructure definitions. If a teammate cannot explain what changed between two deployments, diagnosing an agent regression becomes guesswork: a behavior change might originate in code, instructions, credentials, or the environment that executes it.

For an architect preparing for AI-500, apply ordinary software delivery discipline to the agent’s entire executable contract. Git supplies reviewable history, tests supply evidence about behavior, environments supply configuration, containers supply packaged runtime artifacts, and infrastructure as code supplies declared Azure resources. None replaces the others. A passing unit test does not prove that a deployed identity can reach a private data service.

How it works

Keep the change reviewable in Git

Microsoft’s Azure Repos workflow uses a branch for a change, commits on that branch, a push to the remote repository, and a pull request for review before merging. The branch groups related work; the commit records a source state; the pull request exposes the change for review. A running deployment is a separate outcome.

Store application code, prompt definitions owned by the application, tests, dependency declarations, and infrastructure definitions together in reviewable source control. Apply a repository-owned prompt-agent definition with project.agents.create_version(agent_name=..., definition=PromptAgentDefinition(...)); see 0.13. Reconcile portal edits into that source definition before creating the next reviewed version.

Keep one change explainable. A prompt edit accompanied by a data-schema change and a credential change makes failures harder to attribute. Separate changes when they have independent deployment or rollback requirements, and make their dependencies explicit. The review should tell another engineer which artifact changes behavior and which resource change enables it.

Test the layer that owns the behavior

Use deterministic tests for deterministic rules: input validation, routing, authorization decisions owned by your application, and tool result handling. Fix their inputs and expected outputs so a failed test identifies a code regression. See 0.10 for structured validation and exception handling. Do not substitute an uncontrolled live model call for a test of a pure validation function.

Integration tests exercise the actual interface between components. A storage integration test should check the intended data operation under a test identity. A deployed smoke test should call the intended endpoint and verify a meaningful response. These are proposed test layers, not automatic capabilities enabled by naming a framework.

Agent quality needs a further distinction. A model can return different valid wording, so an exact text assertion is often the wrong contract for a task outcome. Specify the required properties, permitted tool behavior, and unacceptable results. Keep quality evaluation separate from the deterministic checks that must pass every run; the release decision can require evidence from both.

Azure Pipelines provides concrete Python execution mechanisms. UsePythonVersion@0 selects the runtime, and the documented Python pipeline installs dependencies from requirements.txt. The documented pytest invocation uses --junitxml for test-result output and pytest-cov for coverage output. A machine-readable result lets the pipeline expose failures rather than relying on someone to read a terminal transcript. Coverage measures exercised code, not correctness of every agent answer.

Separate development dependencies and environment settings

The Foundry development-environment guide specifies Python 3.10 as its minimum supported version and recommends a project virtual environment instead of global package installation. A virtual environment isolates Python packages for that project. It does not provision an Azure project or select an Azure identity by itself.

Record the runtime and dependency versions that the release uses. Installing an unconstrained package set on every machine can change behavior without a source edit. Use the same dependency declarations in development and CI; see 1.2.9 for dependency controls.

Environment settings describe where and how the same artifact runs: project endpoint, model selection, resource identifiers, and deployment location. Keep secrets out of committed source and container images. A configuration name alone does not make its value confidential; choose the host’s secret mechanism or an identity-based integration.

Azure Developer CLI (azd) creates an environment with a name and stores environment settings under its .azure directory. The environment name influences resource naming. A development and production environment can therefore share source while pointing to different deployed resources. Inspect the selected subscription and location before provisioning instead of trusting a remembered terminal context.

Package containers as identifiable artifacts

A container image packages the application runtime and dependencies. The running container also needs deployment configuration, identities, networking, and any external data services. Packaging the code does not package all of those resources into the image.

Azure Container Apps specifies the image under its template configuration. Changes to that configuration create a container app revision. Its documentation recommends unique image tags per deployment, such as a Git hash, instead of reusing a static tag. Keep a release record that connects the source commit to the exact image reference and deployed revision.

Container Apps expresses environment variables with env; when referencing a secret, use secretRef instead of putting the secret in value. That is a concrete host configuration mechanism, distinct from embedding credentials during image build. The documentation specifies Linux x86-64 (linux/amd64) images, so validate the target architecture rather than assuming an image built on any laptop is deployable unchanged.

Declare infrastructure independently of application execution

Bicep uses declarative syntax to describe Azure resources. It deploys through Azure Resource Manager and supports repeatable resource definitions. Parameters carry environment-specific values, while reusable definitions reduce the need to recreate infrastructure through manual portal actions.

The Bicep what-if operation previews resource and property changes before deployment. Review creates, updates, and deletes as infrastructure changes; a successful preview does not establish that the application can execute its business operation. Keep the infrastructure review and the deployed smoke test as separate evidence.

azd up coordinates provisioning and deployment from a template. The documented flow includes azd provision for Azure resources and azd deploy for application code. Those names expose two responsibilities even when one command runs both. A code change can require deployment without a different resource topology; a network change can require provisioning even when the application artifact stays the same.

Key distinctions and trade-offs

Source versus artifact: A commit identifies reviewed source. An image reference identifies packaged execution content. Record both instead of assuming a branch name identifies a deployed build.

Test versus evaluation: A deterministic test checks a defined rule. An agent evaluation checks task quality under the chosen criteria. Both supply evidence, but they answer different questions.

Provision versus deploy: Provisioning creates or changes Azure infrastructure. Deployment installs the application artifact. A successful operation in one layer does not prove correctness in the other.

Architecture / decision scenario

A team changes a document classifier and its output schema. The pull request contains code, the schema, deterministic validation tests, and the dependency declarations. CI selects the Python version, installs dependencies, and publishes pytest results. A separate evaluation set checks the classification quality.

The release builds a Container Apps-compatible image with a unique commit-based tag. Environment variables select the test project, and secretRef supplies any host-managed secret. The team reviews the Bicep what-if output before provisioning the test resources, then deploys the image and runs a storage-access smoke test with the deployed identity. Production reuses the reviewed artifact with production configuration; it does not rebuild from an unrecorded laptop environment.

Common exam traps

  • Treating a branch name as the identity of a deployed artifact.
  • Assuming high test coverage proves agent answer quality.
  • Confusing a Python virtual environment with an Azure deployment environment.
  • Reusing a container tag while expecting an unambiguous release history.
  • Embedding secrets in an image instead of configuring the runtime.
  • Treating infrastructure preview or provisioning success as an application test.

What to remember

Version the contract, test each responsible layer, identify the artifact, and declare the infrastructure. Keep environment values separate from source and secrets separate from image contents. A reproducible delivery path explains both what ran and what resources allowed it to run.

Knowledge check

References