Develop a security and compliance plan
DevOps Authentication and Authorization
CoreChoose the right workload principal and token model, then grant product access, roles, permissions, projects, and teams at the narrowest workable scope.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
DevOps automation spans human and workload identities. A credential can authenticate successfully while the principal lacks authorization, or a broad role can turn a short-lived token into excessive access.
Must Know
- System-assigned managed identity shares one Azure resource lifecycle; user-assigned managed identity has an independent lifecycle and can be reused.
- A service principal can authenticate Azure automation but the application owns credential or federation configuration; prefer managed identity when the Azure hosting surface supports it.
- GitHub Apps use installations, selected repositories, granular permissions, and short-lived tokens; `GITHUB_TOKEN` is scoped to one workflow repository and should have explicit minimum permissions.
- Personal access tokens represent a user and require narrow scopes and lifecycle management; do not make them the default service identity.
- Azure DevOps service connections represent external-resource authentication; workload identity federation avoids a stored client secret for Azure Resource Manager connections.
- GitHub repository roles and Azure DevOps permissions govern actions; Azure DevOps access levels govern licensed product features.
- Azure DevOps projects isolate many resources; teams within projects define backlogs, area paths, iteration paths, dashboards, and notification scope.
Compare and Distinguish
- Authentication proves a principal; authorization grants actions; access level enables product features.
- GitHub App installation token is app-scoped and short-lived; PAT is user-bound; `GITHUB_TOKEN` is workflow-repository scoped.
- Project Administrator differs from team administrator and Project Collection Administrator.
Scenario examples
- Scenario: One VM needs vault access only while it exists. Think: system-assigned managed identity plus a narrow vault role.
- Scenario: A business user only updates work items. Think: Stakeholder access and project membership, not repository write.
Exam traps
- A short-lived token can still be overprivileged.
- Stakeholder access is not a security group and does not itself grant every Boards action.
- Granting pipeline access to all service connections defeats isolation.
Key takeaways
- Choose identity lifetime before credential form.
- Minimize both permission and assignment scope.
- Separate product licensing, group membership, and object authorization.
How it works
- A platform authenticates the principal, resolves group and inherited permissions, then evaluates allows and denials at the target object.
- GitHub App installations mint short-lived tokens limited by both the app declaration and the repositories approved by the owner.
Objects and administrative surfaces
- Microsoft Entra app registrations, service principals, managed identities, federated credentials, and Azure RBAC.
- GitHub Apps, token permissions, organization and repository roles, teams, collaborators, and audit log.
- Azure DevOps users, access levels, groups, object permissions, projects, teams, service connections, and PATs.
When to use it
- Use a user-assigned managed identity when several Azure resources need one reusable identity with lifecycle independent of any one resource.
Security and governance implications
- Review organization owners, project administrators, policy bypass, force push, service connection use, and stale personal tokens separately.
Troubleshooting signals
- For denied access, identify the principal, token type, target scope, group membership, inherited rule, explicit denial, and access level.
More detail
- Use GitHub Apps for declared permissions and selected-repository installations, reserving personal access tokens for bounded user scenarios.
- Prefer federated Azure Resource Manager service connections and assign the deployment role at the smallest effective Azure scope.
- Distinguish Azure DevOps access levels from project membership, security groups, and object-level permissions.
Ready for the quiz?
- When is a user-assigned identity preferable?
- Why is a GitHub App usually better than a shared PAT for an integration?
- What does Stakeholder access control?
Related objectives
- D4.1.S1 — Choose between Microsoft Entra service principals and managed identities for Azure resources (system-assigned and user-assigned)
- D4.1.S2 — Implement and manage GitHub authentication, including GitHub Apps, GITHUB_TOKEN, and personal access tokens
- D4.1.S3 — Implement and manage Azure DevOps service connections and personal access tokens
- D4.1.S4 — Design and implement permissions and roles in GitHub
- D4.1.S5 — Design and implement permissions and security groups in Azure DevOps
- D4.1.S6 — Recommend appropriate access levels, including stakeholder access in Azure DevOps and outside collaborator access in GitHub
- D4.1.S7 — Configure projects and teams in Azure DevOps