AZ-400 · Domain 4: Develop a security and compliance plan · 13% of the exam
Task 4.1: Design and implement authentication and authorization methods
Service principals or managed identities, GitHub Apps, GITHUB_TOKEN and personal access tokens, service connections, permissions, roles and security groups in GitHub and Azure DevOps, access levels, and projects and teams.
Study it
Identities for automation: service principals, managed identities, GitHub Apps and tokens
Permissions, roles, security groups, access levels, projects and teams in GitHub and Azure DevOps
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
Twenty VMs in a scale set run a deployment agent that reads secrets from Key Vault. The VMs are deleted and re-created from a new image every week. Role assignments must be made once and survive the rebuilds, and no credential may be stored on the VMs. Which identity should the agents use?
AA system-assigned managed identity enabled on each VM
BA service principal with a client secret stored in a file on each VM
CA personal access token from the platform team lead
DA user-assigned managed identity assigned to the scale set
Show the answer and why
AA system-assigned managed identity enabled on each VM
Incorrect
System-assigned identities are deleted with their VM, so the role assignments would be lost every week.
BA service principal with a client secret stored in a file on each VM
Incorrect
A secret on the VMs is the stored credential the design must avoid.
CA personal access token from the platform team lead
Incorrect
A personal token ties automation to one person and is still a stored secret.
DA user-assigned managed identity assigned to the scale set
Correct
It's a standalone resource that several VMs can share, so its role assignments outlive the rebuilt VMs.
A system-assigned managed identity shares its resource's lifecycle and is deleted with it. A user-assigned managed identity is a standalone Azure resource that can be assigned to multiple resources, and Microsoft recommends it for Microsoft services. Azure manages the credentials of both.
Thirty Azure Resource Manager service connections use app registrations with client secrets. Secrets expire every year and deployments fail until someone renews them, and security wants no long-lived secrets for pipelines at all. Teams may not create app registrations themselves. What should you recommend?
AClient secrets with a two-year lifetime and a calendar reminder to renew them
BCertificates uploaded to each app registration instead of secrets
CService connections that authenticate with workload identity federation, using existing user-assigned managed identities
DA personal access token stored in a variable group
Show the answer and why
AClient secrets with a two-year lifetime and a calendar reminder to renew them
Incorrect
Longer-lived secrets are still secrets, and renewals still fail when forgotten.
BCertificates uploaded to each app registration instead of secrets
Incorrect
Certificates also expire and must be stored and rotated.
CService connections that authenticate with workload identity federation, using existing user-assigned managed identities
Correct
Federation exchanges short-lived tokens with no stored secret, and the managed identity option works without creating app registrations.
DA personal access token stored in a variable group
Incorrect
A PAT authenticates to Azure DevOps, not to Azure Resource Manager.
Microsoft recommends Azure Resource Manager service connections that use workload identity federation, with an app registration or a managed identity; the managed identity option suits teams that can't create app registrations. Federation avoids storing and rotating secrets. New connections use the Microsoft Entra issuer; the Azure DevOps issuer retires on 1 July 2027.
An internal bot labels pull requests and posts comments across 150 repositories in a GitHub organization. It uses a classic personal access token from an engineer who is leaving. The bot needs only issue and pull request permissions, its tokens should expire quickly, and it must not depend on any person's account. What should you use?
AA GitHub App installed on the organization with only the needed permissions
BA fine-grained personal access token from a shared machine user account, rotated every year
CThe workflow's GITHUB_TOKEN, passed to the bot's service
DAn SSH key registered to the leaving engineer's account
Show the answer and why
AA GitHub App installed on the organization with only the needed permissions
Correct
GitHub Apps have fine-grained permissions and generate short-lived tokens as the app, not as a user.
BA fine-grained personal access token from a shared machine user account, rotated every year
Incorrect
A machine user is still a user account whose long-lived token must be stored and rotated.
CThe workflow's GITHUB_TOKEN, passed to the bot's service
Incorrect
GITHUB_TOKEN is scoped to one workflow run in one repository, not 150 repositories.
DAn SSH key registered to the leaving engineer's account
Incorrect
SSH keys authenticate Git operations, not API calls for labels and comments, and are tied to the user.
GitHub Apps are the recommended way to integrate automation with the GitHub API: they have fine-grained permissions and generate scoped, short-lived access tokens. GITHUB_TOKEN is generated for a workflow run and scoped to its repository, and personal access tokens act as a user.
While creating a production service connection, an engineer is about to select Grant access permission to all pipelines. Only two pipelines should use it. What should she do instead?
AGrant access to all pipelines and remove it later
BCreate a separate project for the two pipelines
CShare the connection's secret with the two pipeline owners
DLeave the option off and authorize the two pipelines on the connection
Show the answer and why
AGrant access to all pipelines and remove it later
Incorrect
Any pipeline could use the connection meanwhile.
BCreate a separate project for the two pipelines
Incorrect
A new project isn't needed to restrict one connection.
CShare the connection's secret with the two pipeline owners
Incorrect
Sharing secrets isn't access control.
DLeave the option off and authorize the two pipelines on the connection
Correct
Authorizing individual pipelines limits who can use the connection.
Granting access to all pipelines lets any pipeline use a service connection and isn't recommended; authorize each pipeline individually.
A script runs on a build server in a partner's datacenter, outside Azure and not connected to Azure Arc, and must call Azure APIs. Which identity fits, and how should it authenticate?
AA system-assigned managed identity of the server
BA Microsoft Entra service principal using federation or a certificate
CAn administrator's user account with MFA disabled
DAn Azure DevOps PAT
Show the answer and why
AA system-assigned managed identity of the server
Incorrect
The server isn't an Azure resource, so it has no managed identity.
BA Microsoft Entra service principal using federation or a certificate
Correct
Outside Azure, use a service principal and prefer federation or a certificate over a client secret.
CAn administrator's user account with MFA disabled
Incorrect
A user account for automation, without MFA, is a poor choice.
DAn Azure DevOps PAT
Incorrect
A PAT authenticates to Azure DevOps, not Azure APIs.
Prefer a managed identity for workloads hosted in Azure. For a service principal, prefer workload identity federation or a certificate over a client secret when the hosting environment supports it.
Which default Azure DevOps group can create teams, define area and iteration paths and manage user permissions in a project?
AReaders
BProject Administrators
CProject Collection Build Administrators
DContributors
Show the answer and why
AReaders
Incorrect
Readers can view, not administer.
BProject Administrators
Correct
Project Administrators manage permissions, teams, areas and iterations.
CProject Collection Build Administrators
Incorrect
That group manages build resources at the organization level.
DContributors
Incorrect
Contributors work with content, not project settings.
Assign Project Administrators to users who manage user permissions, create or edit teams, modify team settings, define area or iteration paths, or customize work item tracking.