13.4 Access Levels, GitHub Roles & Outside Collaborators

13.4 Access Levels, GitHub Roles & Outside Collaborators

Security groups answer "what may this person do". Access levels answer a different question - "what has this person been licensed to see" - and mixing the two up explains most access-troubleshooting scenarios on the exam.

1. Access Levels vs. Security Groups: Licensing vs. Authorization

A critical distinction tested on the AZ-400 exam is the difference between an Access Level and a Security Group.

• Access Level: Determines which features and UI elements are enabled for a user based on their Visual Studio / Azure DevOps license.
• Security Group: Determines what actions and operations a user is permitted to perform within those enabled features.

Exam Warning: Adding a user to the Project Administrators security group will NOT allow them to view or edit code if their assigned Access Level is set to Stakeholder!

Azure DevOps Access Levels

When to Assign Stakeholder Access

Assign Stakeholder access to product owners, business analysts, executive leadership, and project managers who only need to track work items, update user stories, and monitor kanban boards without interacting with Git repositories or CI/CD pipelines.

---

2. GitHub Enterprise Repository Roles & Collaborator Governance

When managing source code and workflows in GitHub Enterprise, organizations implement GitHub's five base repository permission tiers.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     GitHub Base Repository Permission Tiers                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. READ       • View code, clone repository, open issues, submit pull reqs │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. TRIAGE     • Everything in Read PLUS: Manage issues, apply labels,      │
│                 close issues, manage milestones (No code write access)      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. WRITE      • Everything in Triage PLUS: Push code to non-protected       │
│                 branches, create releases, trigger workflows                │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. MAINTAIN   • Everything in Write PLUS: Manage repository settings,       │
│                 configure branch protection rules (Cannot delete repo)      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. ADMIN      • Full control: Delete repo, manage collaborator permissions, │
│                 configure security & analysis features                      │
└─────────────────────────────────────────────────────────────────────────────┘

Deep Dive: Triage and Maintain Roles

• Triage: Specifically designed for community managers, technical writers, or issue triagers who need to organize backlogs, label bug reports, and close duplicate issues without the ability to push commits or alter code.
• Maintain: Designed for engineering team leads and project managers who must configure repository settings, define branch protection rules, manage webhooks, and oversee releases without possessing destructive administrative powers (such as deleting the repository or transferring ownership).

Managing External Contractors: Outside Collaborators

In enterprise development, organizations frequently engage external vendors, third-party penetration testers, or contractors. Adding external contractors as full members of a GitHub Organization exposes internal organization member directories, public and internal repositories, and teams.

• Outside Collaborators: Users who are granted explicit access to one or more specific repositories without being added as members of the GitHub Organization.
• Security Best Practices for Contractors:
  • Enforce Multi-Factor Authentication (MFA) across all Outside Collaborators.
  • Grant the minimum required repository role (typically Write for software contractors, Read for auditors).
  • Configure automated expiration of collaborator access.
  • Restrict fork permissions and prevent outside collaborators from inviting other collaborators.

---

3. Comprehensive Permission Mapping Matrix

---

4. Realistic Enterprise Governance Scenario & Common Traps

Scenario: Regulated Banking Contractor Onboarding

Company: Woodgrove Bank is contracting an external mobile development agency (Contoso Mobile) to build a new iOS/Android banking interface. The project repository is hosted in Azure Repos and the CI/CD pipeline runs in Azure Pipelines.

Governance Requirements:

1. Contractors must be able to view work items, branch code, and submit Pull Requests.
2. Contractors must never be able to bypass branch policies, push directly to main, delete release branches, or view internal core-banking repositories.
3. Contractors must not have access to production deployment pipelines or production service connections.

Solution Architecture:

• Licensing: Provision Basic Access Level licenses for the contractor accounts so they can access Azure Repos and Pipelines.
• Security Group: Create a custom project security group named External-Contractors.
• Repository Permissions: At the project level, grant External-Contractors Read and Contribute permissions. On the main branch, configure a strict Branch Policy requiring 2 reviewers, linked work items, and successful build validation. Explicitly set Bypass policies when completing pull requests to Deny.
• Service Connection Isolation: Ensure production service connections are set to Restricted pipeline permissions. Grant External-Contractors only the User role on development service connections, completely hiding production connections.
• Effective State: Even if a contractor is added to a secondary team group that has Allow for policy bypass, the explicit Deny on External-Contractors guarantees they cannot bypass branch safeguards.

Common Exam Traps to Avoid

• Trap: Believing an explicit Allow can override a Deny from another group. If a user belongs to Developers (Allow) and Contractors (Deny) for the same permission, the effective permission is ALWAYS Deny. The only way to grant access is to remove the user from the group containing the Deny or change the Deny to Not Set.
• Trap: Confusing Access Levels with Security Group Permissions. If a developer in Project Contributors cannot see the Repos menu, checking their Security Group permissions will not solve the issue. The administrator must check Organization Settings → Users and upgrade their Access Level from Stakeholder to Basic.
• Trap: Assigning Maintain role when repository deletion is required. The GitHub Maintain role cannot delete a repository, manage billing, or adjust organization-wide security defaults. If an exam scenario requires managing repository deletion or collaborator permissions, the correct answer is Admin.