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

Design and implement authentication and authorization methods, including Microsoft Entra service principals, managed identities, GitHub Apps, and Azure DevOps service connections and permissions.

Design authentication and authorisation for pipelines using managed identities and Microsoft Entra service principals to avoid stored credentials, and configure GitHub Apps and Azure DevOps service connections with least-privilege permissions. Recognise when personal access tokens are appropriate and their limitations compared to credential-free identity options.

managed identitiesMicrosoft Entra service principalsGitHub AppsAzure DevOps service connectionspersonal access tokens

Practice question for this objective

Free sampleDevelop a Security and Compliance Planhard

A team is configuring workload identity federation so an "Azure Pipelines" service connection authenticates to Microsoft Entra and deploys to an Azure subscription with no client secret or certificate held anywhere. They are creating a federated credential on the Microsoft Entra application. Which two values must the federated credential be configured with so that only this service connection's pipeline runs can exchange their token for Azure access? Select TWO.

AA copy of the service principal client secret, pasted into the federated credential so the pipeline presents both the secret and the federated token at sign-in.
BAn issuer pointing at the Azure DevOps organisation's OpenID Connect token issuer, so Microsoft Entra trusts tokens minted for that organisation. Correct
CA Contributor role assignment on the resource group, entered directly in the federated credential record so that authorisation travels with the trust definition.
DA subject identifier that matches the specific service connection, so only tokens issued for that connection's organisation and project satisfy the trust. Correct

Configure a federated credential with the correct issuer and subject so only the intended Azure Pipelines service connection can exchange its OpenID Connect token for Azure access. Workload identity federation relies on the federated credential's issuer and subject. The issuer establishes which OpenID Connect provider Microsoft Entra trusts, and the subject pins the trust to one service connection identity. Together they let only that connection's run-time tokens be exchanged for Azure access, with no secret stored anywhere.

Why A is wrong: Workload identity federation exists to eliminate the client secret entirely, so requiring a pasted secret contradicts the secretless goal and is not part of a federated credential at all.

Why B is correct: The issuer names the trusted OpenID Connect provider; setting it to the Azure DevOps organisation issuer lets Microsoft Entra accept the run-time tokens that organisation mints, which is required for the federated exchange.

Why C is wrong: Authorisation is granted by a separate Azure role assignment on the resource, not stored inside the federated credential, so this conflates the trust definition with role-based access control.

Why D is correct: The subject claim scopes the trust to one service connection's identity, so only pipeline runs using that connection present a matching subject and can complete the token exchange, keeping the trust narrow.

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.

Rotate the service principal client secret automatically every seven days through a scheduled pipeline so that any leaked secret is short-lived and quickly invalidated before it can be reused by an attacker.
Why it is wrong: Frequent rotation shortens a secret's useful life but the pipeline still stores and presents a standing client secret between rotations, so a long-lived credential remains and the mandate is not satisfied.
Register a Microsoft Entra application for the app, store its client secret in an App Service application setting, and grant that application a Key Vault access policy for get and list of secrets.
Why it is wrong: Granting the registered application vault access works, but storing its client secret in app settings keeps a long-lived credential on the app, which is precisely what the team wants to avoid.
Generate a service principal client secret, save it as an encrypted GitHub Actions secret, and reference it from the azure login step so the value is never exposed in workflow logs or source.
Why it is wrong: Encrypting the secret in GitHub protects it at rest and in logs, but a client secret is still a stored long-lived credential, which directly violates the requirement to store no secret or certificate.

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