A team maintains multi-agent definitions, tool registrations, prompt assets, and Azure infrastructure for Microsoft Foundry. They need repeatable promotions across Development, Test, Acceptance, and Production with auditability. Which approach best satisfies CI/CD and multi-environment requirements?
Select an answer to reveal the explanation.
Short Explanation
Treat agents like real software: keep prompts, tools, evals, and infrastructure-as-code in version control, test them in pipelines, and promote through DTAP with approvals. Click-ops-only production is how drift and mystery outages are born.
Full Explanation
Deploying multi-agent solutions requires choosing release methodology (including DTAP), multi-environment strategies, and CI/CD with IaC and automated testing/evaluations. The approach that stores agent prompts, tool configs, evaluation suites, and infrastructure-as-code in version control; runs automated tests and evaluations in pipelines; and promotes artifacts through DTAP environments with controlled approvals is correct because version-controlled assets, pipeline-automated validation, and staged DTAP promotion with approvals provide repeatability and audit trails.
The approach that edits agents only in the Production Foundry portal using click-ops is incorrect because production-only portal click-ops prevents reproducible releases and creates configuration drift.
The approach that copies production secrets into developer laptops and manually recreates resources in each subscription by memory is incorrect because secrets on laptops and manual recreation violate security and CI/CD principles.
The approach that uses a single shared environment for all stages is incorrect because collapsing all stages into one environment removes isolation for testing and acceptance and increases production risk.
Exam tip: DTAP + IaC + automated evaluations in pipelines is the multi-agent release story; portal-only production edits are a common wrong answer.