AZ-400 - Develop a Security and Compliance Plan (13% of the exam) - Section 4.2

Design and implement a strategy for managing sensitive information in automation, including Azure Key Vault, secretless authentication, and workload identity federation.

Implement secret management in pipelines using Azure Key Vault references and Azure Pipelines secure files to keep credentials out of YAML definitions. Apply workload identity federation via OpenID Connect to allow pipelines to authenticate to Azure without storing long-lived secrets, and understand when each approach is the right fit.

Azure Key Vaultworkload identity federationOpenID ConnectAzure Pipelines secure filessecret management

Practice question for this objective

Free sampleDevelop a Security and Compliance Planhard

A pipeline in "Azure Pipelines" deploys to an Azure subscription through an Azure Resource Manager service connection. A security review requires that the pipeline hold no long-lived credential that could be exported or leaked, while still authenticating to Microsoft Entra to obtain Azure access tokens. Which way of configuring the service connection meets the requirement?

ACreate the service connection using a Microsoft Entra service principal with a client secret, then store that secret in "Azure Key Vault" and have the pipeline read it at run time so it is never committed to the repository.
BCreate the service connection using workload identity federation so Azure DevOps presents an OpenID Connect token to Microsoft Entra and exchanges it for an access token, with no secret or certificate held on the connection. Correct
CCreate the service connection using a Microsoft Entra service principal authenticated with a certificate, and rotate the certificate automatically every ninety days so a leaked credential has a short useful lifetime.
DCreate the service connection from a personal access token scoped only to release management, and grant that token rights on the subscription so the pipeline authenticates without storing an Entra service principal secret.

Use workload identity federation on an Azure Resource Manager service connection to authenticate to Microsoft Entra without storing any long-lived secret. Workload identity federation configures a federated credential in Microsoft Entra that trusts tokens issued by Azure DevOps. At run time the service connection presents a short-lived OpenID Connect token and exchanges it for an Azure access token, so authentication succeeds without any client secret or certificate being stored on the connection.

Why A is wrong: Keeping the secret in a vault improves storage hygiene and is tempting, but a client secret is still a long-lived credential that can be exported, so it does not satisfy the no-stored-credential requirement.

Why B is correct: Workload identity federation lets the service connection exchange a short-lived OpenID Connect token for an Azure access token through a federated credential, so no secret or certificate is ever stored, meeting the requirement exactly.

Why C is wrong: Certificate credentials with rotation reduce exposure and look secure, but the certificate is still a long-lived secret stored against the connection, which is exactly the artefact the review wants eliminated.

Why D is wrong: A personal access token authenticates to Azure DevOps itself rather than to an Azure subscription, and it is still a long-lived secret, so it can neither perform the deployment nor satisfy the requirement.

See more AZ-400 practice questions, answers explained.

Exam traps in Develop a Security and Compliance Plan

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

Store the vault access in the application's appsettings.json file as a connection string so the runtime can present it to the vault when it requests each secret.
Why it is wrong: Placing any credential in appsettings.json is precisely the stored secret the team wants to avoid, so although it would technically authenticate it violates the no-secret-in-settings constraint.
Create one variable group per pipeline, paste the current secret values into each as secret variables, and update every group manually whenever a value is rotated in the vault.
Why it is wrong: Pasting copies of the values into many groups duplicates the secrets and forces manual edits on every rotation, which fails the requirement that rotated values flow through without editing each pipeline.
Store a Microsoft Entra service principal client secret in an organisation-level secret restricted to selected repositories, and reference it in the workflow so only approved repositories can read the credential to sign in.
Why it is wrong: Restricting an organisation secret to selected repositories limits who can read it, which is tempting, but the client secret is still stored as a secret, directly violating the policy against storing Azure credentials.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.