Authorization & Access: GitHub Roles & Azure DevOps Security

Why authorization design matters for DevOps

GitHub repository roles

GitHub uses a five-tier permission model for repositories. Each role inherits all permissions from the level below it.

Role	Key Permissions	Typical User
Read	Clone, view code, open issues, comment	External contributors, stakeholders
Triage	Read + manage issues and PRs (label, assign, close) — cannot push code	QA, project managers, support engineers
Write	Triage + push to non-protected branches, create branches, merge PRs (if approved)	Developers
Maintain	Write + manage repo settings (except destructive actions), manage topics and wikis	Tech leads, senior developers
Admin	Full control — delete repo, manage security settings, configure branch protection	Repository owners

Organisation-level roles

• Member — default role. Can see all non-private repos, create repos (if allowed), and be added to teams.
• Owner — full administrative control over the organisation, billing, and all repos. Limit to 2-3 people.
• Moderator — can manage comments and interactions across the org. No code access.
• Billing manager — can manage billing settings only. No code or admin access.

Outside collaborators

An outside collaborator is someone who is not a member of the organisation but has access to one or more repositories. Key facts:

• Must be explicitly invited per repository
• Cannot see other repositories or organisation settings
• Can be granted any repository role (Read through Admin)
• Organisations can restrict outside collaborator invitations to owners only
• Useful for contractors, consultants, or partner teams

Question

What is the key difference between the Triage and Write roles in GitHub?

Click or press Enter to reveal answer

Answer

Triage can manage issues and PRs (label, assign, close, reopen) but CANNOT push code or merge PRs. Write can do everything Triage can, plus push code to non-protected branches and merge approved PRs. Triage is ideal for QA and project managers who manage the backlog but do not write code.

Click to flip back

Azure DevOps security model

Azure DevOps uses a group-based security model with permissions inherited through a hierarchy: Organisation → Project → Team → Area/Iteration.

Default project-level groups

Group	Key Permissions	Typical Members
Project Administrators	Full project control — manage teams, repos, pipelines, service connections	Tech leads, project owners
Build Administrators	Manage build pipelines and build definitions	CI/CD engineers
Contributors	Create and edit work items, push code, create branches, run pipelines	Developers
Readers	Read-only access to code, work items, and pipeline results	Stakeholders, auditors
Project Valid Users	Baseline access to browse the project	Auto-populated — everyone in the project
Release Administrators	Manage release pipelines and approve deployments	Release managers

Organisation-level groups

• Project Collection Administrators — highest level. Full control over all projects, agents, extensions, and settings.
• Project Collection Build Service — the identity Azure Pipelines uses. Control its permissions to restrict what pipelines can do.

The Build Service identity

Every Azure DevOps organisation has a Project Collection Build Service account. This is the identity that runs pipelines. Its permissions determine what pipelines can access:

• By default, it has Contribute access to repositories in the project
• You can restrict it per-repository (e.g., deny access to sensitive repos)
• For cross-project access, explicitly grant the Build Service account permissions in the target project

Question

What is the 'Project Collection Build Service' in Azure DevOps?

Click or press Enter to reveal answer

Answer

It is the built-in identity that Azure Pipelines uses to execute pipeline tasks. It has its own set of permissions that you can configure per-repository and per-project. Restricting its permissions is a key security control — for example, you can deny it write access to production configuration repositories.

Click to flip back

Azure DevOps access levels

Access levels control which features a user can use, separate from permissions (which control what they can do within those features).

Azure DevOps Access Levels

Feature	Stakeholder (Free)	Basic	Basic + Test Plans
View work items and boards	Yes	Yes	Yes
Create and edit work items	Yes (limited in private projects)	Yes	Yes
View pipelines and releases	Yes	Yes	Yes
Run pipelines	No	Yes	Yes
Manage repos (push, PR)	No	Yes	Yes
Use Boards fully (sprints, capacity)	Limited	Yes	Yes
Test Plans (create and run test suites)	No	No	Yes
Cost	Free (unlimited users)	Paid per user (first 5 free)	Paid per user (add-on)
Ideal for	Executives, clients, business users	Developers, QA, DevOps engineers	Dedicated test managers

Stakeholder access is strategically important: it allows unlimited free users to view progress, create work items, and participate in discussions — without consuming paid licences. This is how you give visibility to business stakeholders, executives, and external clients.

Scenario: Amira designs access for Meridian Insurance

🏛️ Dr. Amira Hassan is designing the Azure DevOps access model for Meridian Insurance (8,000 employees). Dmitri (VP Engineering) wants all 200 developers to have full access, but also wants 50 business analysts and 15 executives to see progress.

Amira’s design:

• 200 developers → Basic access level, added to Contributors group per project
• 50 business analysts → Stakeholder access (free), added to a custom “Business Stakeholders” group with read access to Boards and work items
• 15 executives → Stakeholder access (free), added to a dashboard-only team with visibility into progress charts
• 5 release managers → Basic access, added to Release Administrators group
• 3 platform leads → Basic access, added to Project Administrators group
• Elena (compliance) → Basic access + custom permissions to view audit logs and pipeline approvals

Cost impact: Only 208 paid Basic licences instead of 283. The 65 Stakeholder users are free.

GitHub vs Azure DevOps permissions

Permission Models: GitHub vs Azure DevOps

Concept	GitHub	Azure DevOps
Permission unit	Repository roles (Read/Triage/Write/Maintain/Admin)	Security groups with granular allow/deny/not set
Inheritance	Org defaults flow to repos	Org → Project → Team → Area/Iteration
External users	Outside collaborators (per-repo invite)	Stakeholder access level (free, limited features)
Team structure	Teams (org-level, grant repo access)	Teams (project-level, own backlogs and sprints)
Pipeline permissions	Workflow permissions block + environment protection rules	Pipeline permissions, approvals, branch restrictions on service connections
Free tier external users	Outside collaborators (count against paid seats on paid plans)	Stakeholder access (unlimited, truly free)
Highest admin role	Organisation Owner	Project Collection Administrator

Question

In Azure DevOps, what is the difference between an access level and a permission?

Click or press Enter to reveal answer

Answer

An access level controls which FEATURES a user can see (Boards, Repos, Pipelines, Test Plans). A permission controls what actions the user can PERFORM within those features (read code, push code, manage pipelines, approve releases). A user needs both the right access level AND the right permissions to do their work.

Click to flip back

Configuring projects and teams in Azure DevOps

Project structure patterns

Pattern	Description	When to Use
Single project	All teams in one project, separated by Area Paths	Small-to-medium orgs with shared backlogs
One project per product	Each product/service has its own project	Medium-to-large orgs needing isolation between products
One project per team	Each team owns a project	Avoid — leads to fragmentation and cross-project query headaches

Team configuration

Within a project, teams provide:

• Own backlog — each team manages its own Product Backlog and Sprint Backlogs
• Own sprints — teams can have different iteration cadences
• Own dashboards — team-specific metrics and widgets
• Area path ownership — work items in a specific area path belong to the team
• Notification settings — team-level alerts

Default team: Every project has a default team that owns the root Area Path. Additional teams should be created with child Area Paths.

Question

How do you give two teams in the same Azure DevOps project their own separate backlogs?

Click or press Enter to reveal answer

Answer

Create child Area Paths under the project root (e.g., 'MyProject/Team Alpha' and 'MyProject/Team Beta'). Create a team for each, and in the team settings, configure the team to own its Area Path. Work items under each Area Path appear only in that team's backlog.

Click to flip back

💡 Exam tip: Least-privilege patterns

The exam frequently tests least-privilege reasoning. Common patterns:

• Developers should be Contributors, not Project Administrators
• Stakeholders viewing progress should get Stakeholder access (free), not Basic
• Release approvers need only approve permission on environments/stages — not Build Administrator or Project Admin
• Outside contractors in GitHub should be outside collaborators with Write (not Admin) on their repo only
• Service accounts (pipeline identities) should have the minimum RBAC scope — resource group, not subscription
• Branch protection enforces who can merge, even if they have Write access to the repo

Knowledge check

Knowledge Check

Nadia wants business analysts at Meridian Insurance to view Azure Boards, create work items, and leave comments — but NOT run pipelines or manage code. What is the most cost-effective solution?

ABasic access level with Readers group membershipBStakeholder access level (no additional group needed for these activities)CBasic access level with a custom security group denying pipeline and repo accessDVisual Studio Enterprise access level with Readers group

Check Answer

Knowledge Check

Jordan's team has a GitHub organisation with 20 repositories. A security contractor needs Write access to three specific repos for a six-month engagement. What is the best approach?

AAdd the contractor as an organisation Member and create a team with access to those three reposBAdd the contractor as an outside collaborator with Write role on each of the three reposCCreate a fine-grained PAT scoped to the three repos and share it with the contractorDGive the contractor Admin role on the three repos so they can manage their own access

Check Answer

Knowledge Check

In Azure DevOps, which group should a user belong to if they need to manage build pipeline definitions but NOT approve production releases or manage project settings?

AProject AdministratorsBContributorsCBuild AdministratorsDRelease Administrators

Check Answer

🎬 Video coming soon

Authorization & Access: GitHub Roles & Azure DevOps Security

Next up: Secrets and Secure Pipelines: Key Vault and Workload Federation