Develop a security and compliance plan · Topic 1 of 3

Authentication and Authorization Methods

AZ-400 identity: service principals versus managed identities, GitHub Apps and tokens, Azure DevOps service connections, groups and access levels.

6 min

In a nutshell

Managed identity: no credentials to manage. System-assigned follows the resource. User-assigned is reusable.
Service principals have secrets, certificates or federated credentials. Prefer federation.
GitHub Apps and GITHUB_TOKEN beat PATs for automation. Set permissions: to the minimum.

What it is

Authentication proves who or what is calling. Authorization decides what that caller may do. In DevOps there are two kinds of caller: people (developers, approvers) and automation (pipelines, apps, scripts). The design goal is the same for both: least privilege, short lived credentials and no shared accounts.

How it works

Identities for automation in Azure

Identity	What it is	Credentials
Service principal	The identity of an app registration in Microsoft Entra ID	A secret, a certificate or a federated credential. Secrets and certificates expire and must be rotated
System-assigned managed identity	An identity that belongs to one Azure resource. Created and deleted with it	None to manage. Azure handles the credential
User-assigned managed identity	A standalone identity resource that you assign to one or more resources	None to manage. Survives resource deletion and can be shared

Choose a managed identity whenever the caller runs in Azure (or on an Arc enabled machine). Use a service principal when the caller runs outside Azure, such as a hosted pipeline agent, ideally with a federated credential so no secret exists. Use system-assigned for a single resource with its own life cycle and user-assigned when several resources need the same access or you want the identity to outlive the resource.

Grant roles with Azure RBAC at the narrowest scope that works, such as one resource group, and not Owner or Contributor on the subscription unless needed.

GitHub authentication

Method	Notes
GitHub App	A registered app with fine-grained permissions installed on chosen repositories. It authenticates as itself and mints short lived installation tokens (about an hour). Best for integrations and automation. Not tied to a person
GITHUB_TOKEN	A token Actions creates for each job, scoped to the repository, that expires when the job ends. Set its rights with the `permissions:` key, and set repository defaults to read only
Personal access token (PAT)	Tied to a person. Fine-grained PATs limit repositories and permissions and always expire. Classic PATs are broader. Organizations with SAML single sign on must authorize them
OAuth app	Acts on behalf of a user, with broad scopes. Prefer a GitHub App
SSH keys / deploy keys	A deploy key gives read (or write) access to one repository

permissions:
  contents: read
  id-token: write

Azure DevOps authentication

Method	Notes
Personal access token	Scoped, expiring tokens for scripts. Organizations can limit their lifetime. A PAT acts as its owner, so a departing employee's PAT should not run production
Microsoft Entra tokens	Preferred for newer integrations. Service principals and managed identities can be added to an organization and call Azure DevOps APIs
Service connections	Saved connections that let a pipeline reach Azure, GitHub, a registry, a Kubernetes cluster and more

For an Azure Resource Manager service connection, Microsoft recommends workload identity federation, with either an app registration or a managed identity, because it removes the secret. Manual connections with a secret are for edge cases. Service connections not used for about 100 days may be disabled automatically.

Secure service connections:

Do not grant access to all pipelines. Authorize each pipeline.
Scope to a resource group rather than the whole subscription where possible.
Add approvals and checks (for example branch control) to production connections.
Use the service connection roles (Reader, User, Creator, Administrator) to limit who can use or change it.

Permissions and roles

GitHub

Level	Details
Repository roles	Read, Triage, Write, Maintain, Admin, assigned to people or teams
Organization roles	Owners and members, with a base permission for all repositories
Outside collaborators	People who are not organization members, given access to specific repositories only
Teams	Group people and grant access once

Azure DevOps

Concept	Details
Security groups	Organization groups (such as Project Collection Administrators) and project groups: Project Administrators, Contributors, Readers, Build Administrators, Release Administrators
Permission states	Allow, Deny, Not set, plus inherited values. Deny wins over Allow
Scopes	Organization, project, then object level such as a repository, branch, pipeline or environment

Access levels (Azure DevOps licensing)

Level	What it gives
Stakeholder	Free. Limited Boards features, can view and contribute to work items and dashboards, but no access to private repositories
Basic	Boards, Repos, Pipelines and Artifacts. A small number of users per organization are free
Basic + Test Plans	Adds Azure Test Plans
Visual Studio subscriber	Matched to the person's subscription

In GitHub the equivalent control is the role and seat, and outside collaborators count against seats if they have private access.

Projects and teams in Azure DevOps

A project is the boundary for repositories, pipelines, boards and permissions. A team inside a project has its own backlog, boards, dashboards, area paths and iterations. Microsoft's guidance is to use fewer projects and separate teams, unless a strong security or process boundary demands another project. Configure area paths and iterations for teams so each sees its own work.

A worked scenario

A company deploys from Azure Pipelines to Azure. Pipelines used a service principal with a client secret that expired twice and had Contributor on the whole subscription. The team replaces it with a service connection using workload identity federation, scoped to one resource group with a narrow role. They authorize only the deployment pipeline, add a branch control check, and move internal Azure workloads to user-assigned managed identities shared by the app and its function.

What to remember for the exam

Managed identity: no credentials to manage. System-assigned follows the resource. User-assigned is reusable.
Service principals have secrets, certificates or federated credentials. Prefer federation.
GitHub Apps and GITHUB_TOKEN beat PATs for automation. Set permissions: to the minimum.
Azure Resource Manager service connections: workload identity federation is recommended. Do not grant all pipelines access.
Azure DevOps Deny overrides Allow. Stakeholder access has no private repository access.

Exam tip

"Pipeline needs to deploy without storing a secret" is workload identity federation. "App in Azure needs to read Key Vault" is a managed identity.

How the exam asks about this

"Several VMs need the same identity and it must survive VM deletion." User-assigned managed identity.
"Give a contractor access to one GitHub repository only." Outside collaborator.
"Limit what a workflow job can do with its token." The permissions: key.
"Let a free user view work items but not code." Stakeholder access.

Common mistakes

Contributor at subscription scope for a pipeline. Scope it to the resource group.

Using one PAT for a team. It breaks when the owner leaves and hides who did what.

Granting access to all pipelines. It lets any pipeline use the connection.

Mixing up the two managed identity kinds. Only user-assigned can be shared.

Check yourself

Which managed identity type can be assigned to several resources?
User-assigned.
Which GitHub token expires when the workflow job ends?
GITHUB_TOKEN.
Which permission state wins when Allow and Deny both apply in Azure DevOps?
Deny.

Topic 1 of 3 in Develop a security and compliance plan

Test yourself on Develop a security and compliance plan

The full Microsoft AZ-400 question bank has 766 questions, with timed practice exams and an explanation for every answer.

Subscribe Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.