AZ-400 Designing and Implementing Microsoft DevOps Solutions Exam

Choose between Service Principals and Managed Identity

When connecting to Azure resources, you often need to authenticate an application or script. Two common options in Azure are Service Principals and Managed Identity. Both approaches use Azure Active Directory (Azure AD) to grant access without sharing passwords.

A Service Principal is like a user identity for an application. It uses client ID and client secret or certificates. You can assign a Service Principal to an application and give it specific permissions in Azure.

A Managed Identity is a special identity created and managed by Azure itself. It can be system-assigned or user-assigned. Azure automatically rotates credentials, reducing the risk of leaked secrets.

When choosing between them, consider:

• Security: Managed Identity removes secret management.
• Scope: Service Principals can span multiple subscriptions.
• Ease of use: Managed Identity is simpler to set up for single resources.

Implement and manage GitHub authentication, including GitHub Apps, GITHUB_TOKEN, and personal access tokens

To automate workflows in GitHub, you need to authenticate actions securely. There are three main methods: GitHub Apps, GITHUB_TOKEN, and personal access tokens.

A GitHub App uses OAuth to grant scoped permissions to repositories or organizations. You install the app where you need it, and it can perform only the actions you allow. This makes it highly secure for integrations.

The GITHUB_TOKEN is an automatically generated token available in GitHub Actions. It provides short-lived credentials for each workflow run. You do not need to store it, and it is revoked at the end of the run.

A personal access token (PAT) is created per user and can have broad scopes. You must store it securely (for example, in GitHub Secrets). PATs are suitable for manual API calls or scripts outside of GitHub Actions.

Implement and manage Azure DevOps service connections and personal access tokens

In Azure DevOps, service connections and personal access tokens (PATs) help connect to external services. You need them to integrate pipelines, test suites, and deployments.

A service connection holds credentials to an external system, like Azure, Docker Registry, or GitHub. You set it up in Azure DevOps project settings and select the connection type. You can use service principals, managed identities, or PATs under the hood.

A personal access token is tied to a user account in Azure DevOps. It can span multiple scopes, like code read/write or project management. PATs must be treated as secrets and rotated regularly to maintain security.

Best practices include:

• Use service connections for pipelines to avoid user-level credentials.
• Grant the least privilege needed for tasks.
• Store PATs in Azure Key Vault or pipeline secrets.

Design and implement permissions and roles in GitHub

Managing permissions in GitHub ensures that teams have the right level of access. You can control who can read, write, or administer repositories using roles and permissions.

GitHub offers several built-in roles: Read, Triage, Write, Maintain, and Admin. Each role has specific capabilities, from viewing code to managing settings. Assign roles at the repository or organization level to match responsibilities.

You can also use teams to group users and assign repository permissions in bulk. This simplifies access management when you have many contributors. Teams can inherit permissions and be nested under other teams.

To secure your repositories:

• Enforce branch protection rules.
• Require pull request reviews.
• Use approved teams and least privilege.

Design and implement permissions and security groups in Azure DevOps

Azure DevOps uses security groups and access levels to manage permissions across projects. Security groups let you assign permissions to multiple users at once.

Built-in groups include Project Administrators, Contributors, and Readers. Each group has a set of permissions for boards, repos, pipelines, and test plans. You can also create custom security groups for special roles, like release managers.

Permissions are granted or denied at different scopes:

• Project level
• Repository level
• Pipeline level

Use these scopes to implement least privilege. Always review group memberships and avoid granting broad permissions to reduce the risk of unauthorized changes.

Recommend appropriate access levels, including stakeholder access in Azure DevOps and outside collaborator access in GitHub

Choosing the right access level ensures team members can do their work without extra risk. Azure DevOps and GitHub both have ways to grant limited or full access.

In Azure DevOps, Stakeholder access is free and offers basic features like work item tracking and dashboards. It is ideal for users who do not need to commit code. For more features, you choose Basic or Basic + Test Plans levels.

In GitHub, you can add outside collaborators to a repository without giving them full organization access. Outside collaborators can be given any of the repository roles from Read to Admin. This ensures external partners get only what they need.

When recommending access:

• Match access to actual job tasks.
• Use free or minimal tiers where possible.
• Review and revoke access when roles change.

Configure projects and teams in Azure DevOps

Effective organization in Azure DevOps starts with well-defined projects and teams. Projects group related work, code, and pipelines. Teams help structure workboards, backlogs, and sprints.

Each project can contain multiple teams, each with its own area paths and iterations. This lets teams plan and track work independently. You can also assign team-level backlogs and dashboards for focused visibility.

To set this up:

• Create a project per product or major initiative.
• Define teams based on functional roles or features.
• Assign area paths and sprint schedules to each team.

This structure improves collaboration, reduces confusion, and ensures that work is assigned to the right group.

Conclusion

In this section, you learned how to secure Azure and DevOps environments by choosing the right authentication methods, such as Service Principals or Managed Identity. You discovered how to implement GitHub authentication with Apps, GITHUB_TOKEN, and personal access tokens, and how to manage Azure DevOps service connections and PATs. Permission models in both GitHub and Azure DevOps were covered, focusing on roles, security groups, and access levels like stakeholder or outside collaborator. Finally, you saw how to structure projects and teams in Azure DevOps to align work and control access effectively. These skills help you maintain secure, organized, and efficient DevOps processes in Azure.