Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-104.3 Deploy multi-agent solutions to Azure

Separate pipeline identity from release approval

Completed by the knowledge check

Learning objective

Configure CI/CD with workload identity federation, environment approval, and release validation.

Core idea

A deployment pipeline must answer three independent questions: which identity can access Azure, who permits the production stage to consume its protected resources, and what evidence establishes that the candidate is ready. Workload identity federation answers the identity question. Environment approvals answer the authorization-to-proceed question. Tests, evaluation results, and deployed checks answer the validation question.

Keep those controls separate. Secretless authentication does not imply permission to deploy every resource. A human approval does not establish that the tested agent is the deployed agent. A passing build does not prove that the runtime can reach its tools.

Azure Pipelines provides Azure Resource Manager service connections for deployment identity and resource-owned approvals and checks for stage admission. Azure Developer CLI can generate GitHub Actions pipeline configuration, but its authentication support has provider-specific limits. Choose a documented path rather than assuming all pipeline generators support the same combination.

How it works

Configure the federated deployment principal

Microsoft recommends workload identity federation for Azure Resource Manager service connections, using an app registration or managed identity. This removes the need for a stored client secret in that connection. The identity still needs Azure permissions on the deployment target; service-connection permission in Azure DevOps and resource access in Azure are separate controls.

The automatic setup supports an app registration or an existing user-assigned managed identity. The manual flow creates the identity, saves the service connection as a draft, adds the federated credential to that identity, grants the required target permissions, and completes the connection. Copy the generated Issuer and Subject identifier from Azure DevOps.

Do not hard-code a remembered Azure DevOps issuer and subject pattern. Microsoft documents a migration for public-cloud workload identity connections using single-tenant Microsoft Entra applications or managed identities: the Azure DevOps issuer https://vstoken.dev.azure.com retires on July 1, 2027, and applicable connections standardize on the Microsoft Entra issuer https://login.microsoftonline.com/. Multitenant applications and non-public clouds are excluded from that migration scope. Use the generated values for the connection being configured.

Authorize the intended pipeline individually. Microsoft’s service-connection guide advises against Grant access permission to all pipelines. Assign only the deployment permissions needed on the target resources; see 4.1.1 for principal and permission scopes. Do not reuse the deployment principal as the agent’s runtime identity merely because it can create resources.

Use tasks that consume the connection correctly

In Azure Pipelines, AzureCLI@2 runs Azure CLI commands through an Azure Resource Manager connection specified by azureSubscription. Its scriptType selects the shell, such as bash or pscore, and scriptLocation selects scriptPath or inlineScript. The service-connection name is a task input, not a client secret to pass to your deployment script.

Review task support for workload identity federation, particularly Marketplace extensions. The connection documentation explicitly requires compatible extensions. A configured federation credential cannot make an incompatible task understand the authentication flow. Validate the actual tasks in the chosen pipeline before production promotion.

For GitHub Actions generated by Azure Developer CLI, azd pipeline config defaults to OpenID Connect (OIDC), also called federated credentials. Microsoft marks that command beta. The same page states that OIDC/federated credentials are not supported for Terraform in that generated path. Do not infer that this restriction applies to every manually configured Terraform pipeline; it scopes the documented azd generator. See 4.3.9 for the Terraform integration and state requirements.

Put approval on the protected resource

Azure Pipelines approvals and checks are configured by resource administrators through the web interface, outside pipeline YAML. On a production environment, use Approvals and checks to configure Approvals, designated Approvers, the self-approval option, and Timeout. If approval does not arrive within the timeout, the stage is skipped.

Every check on every resource consumed by a stage must be satisfied before that stage begins. The documented order is static checks, pre-check approvals, dynamic checks, post-check approvals, and exclusive lock. A YAML condition and a resource-owned approval are therefore different mechanisms: editing the pipeline’s condition does not edit the environment’s approval policy.

Use Branch control for allowed source branches and Required template when pipelines must extend an approved YAML template. These controls reduce the chance that a pipeline author bypasses the expected validation sequence. They still need appropriate administration of the protected resources; a resource administrator can bypass supported checks, and Azure Pipelines records who performed the bypass.

If approval must consider completed machine evidence, arrange validation before the approval or use the documented post-check approval category after dynamic checks. An early approval cannot review a report that does not exist yet. See 4.3.3 for how these gates connect to controlled traffic promotion.

Validate the release before and after deployment

Before the protected stage, run the test layers from 4.3.6 and consume the completed evaluation decision from 4.3.7. Link their results to the code revision, deployment artifact, agent version, and compatible dependencies. Those identifiers form your release record; an approval is meaningful only if it refers to that record.

See 4.3.3 for Invoke REST API, Invoke Azure Function, Query Azure Monitor Alerts, and Exclusive lock checks that connect evidence, operational health, and serialized promotion.

After deployment, perform a deployed invocation and verify a representative tool path under the runtime identity. For Foundry hosted agents, azd ai agent invoke exercises the deployed target, while --local exercises local execution. Use a fresh session where isolation matters and retain the observed response and tool outcome. A successful infrastructure task is not this runtime validation.

Keep recovery linked to the compatible release evidence described in 4.3.4.

Key distinctions and trade-offs

Federation versus permissions: Federation establishes the pipeline’s identity without the connection’s stored client secret. Azure role assignments establish what that principal can do.

YAML conditions versus resource checks: The pipeline author controls conditions. The protected resource’s administrators control its approvals and checks.

Approval versus validation: Approval permits consumption of a protected resource. Validation establishes a measured property of the candidate or deployed runtime.

Automation reduces credential handling and repetitive work, but generated pipelines still need task compatibility, resource checks, and release-specific validation. Separate the provisioning identity, runtime identity, and approver responsibilities according to the work each performs.

Architecture / decision scenario

A finance team deploys a hosted agent through Azure Pipelines. It creates a workload identity Azure Resource Manager connection, copies the generated federation values, grants narrowly scoped deployment permissions, and authorizes only the release pipeline. AzureCLI@2 consumes the named connection.

The candidate passes deterministic tests and the evidence-linked evaluation gate. The production environment requires an approved branch and template, a dynamic quality-evidence check, and post-check approval. The approver reviews the candidate’s completed report rather than an unrelated passing run. An exclusive lock prevents overlapping promotion stages.

Deployment succeeds, but deployed invocation cannot reach a required tool using the runtime identity. The pipeline records a release-validation failure and stops further promotion. Federation and approval succeeded; runtime readiness did not. The team repairs the runtime permission or restores the recorded compatible set. It does not broaden the deployment principal’s permissions and assume that will repair agent execution.

Common exam traps

  • Treating workload identity federation as an Azure authorization grant.
  • Granting every pipeline access to the production service connection.
  • Copying a fixed issuer pattern despite the documented migration.
  • Defining a YAML condition and calling it a resource-owned approval.
  • Assuming azd pipeline config supports Terraform with OIDC.
  • Treating deployment success or absence of alerts as proof of agent quality.

What to remember

Federate a scoped deployment identity, protect the production resource with independently managed checks, and validate the exact candidate before and after deployment. Keep issuer scope, task compatibility, approval order, and runtime identity explicit. Each control proves a different part of release readiness.

Knowledge check

References