13.3 Azure DevOps Projects, Teams & Permission Evaluation

13.3 Azure DevOps Projects, Teams & Permission Evaluation

Effective enterprise DevOps governance requires maintaining the balance between engineering velocity and strict security control. In organizations with hundreds of engineers, external contractors, and automated pipelines, poorly structured permissions lead to unauthorized code modifications, accidental branch deletions, unvetted pipeline executions, and compliance failures.

For the AZ-400 exam, candidates must master the hierarchical security models of both Azure DevOps and GitHub Enterprise. This includes understanding built-in security groups, permission inheritance mechanics, explicit Deny evaluation logic, licensing Access Levels, and GitHub repository roles.

---

1. Azure DevOps Hierarchical Security Planes

Azure DevOps organizes security boundaries into three hierarchical planes:

┌─────────────────────────────────────────────────────────────────────────────┐
│ 1. Organization Level (Project Collection)                                  │
│    • Project Collection Administrators (PCA)                                │
│    • Global Policies, Auditing, Extension Installs, Billing, Org Licensing │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │ Governs
                                       ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 2. Project Level                                                            │
│    • Project Administrators, Project Contributors, Project Readers          │
│    • Project Settings, Teams, Area/Iteration Paths, Service Connections     │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │ Governs
                                       ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 3. Object Level (Individual Artifacts)                                      │
│    • Specific Git Repositories (Bypass policies, Force push, Manage branch) │
│    • Specific Pipelines (Edit build pipeline, Queue builds, Delete)         │
│    • Specific Service Connections (Use, Administer)                         │
│    • Specific Agent Pools and Variable Groups                               │
└─────────────────────────────────────────────────────────────────────────────┘

Built-In Security Groups & Default Roles

Azure DevOps provisions standard built-in security groups with pre-configured permission sets:

• Project Collection Administrators (PCA): The highest administrative authority in an organization. PCAs can perform all actions across all projects, modify organization settings, configure billing, manage auditing, and install extensions from the Visual Studio Marketplace.
• Project Administrators: Full administrative control within a single project. Can create and delete teams, configure area and iteration paths, manage project-level permissions, and adjust service connections.
• Project Contributors: The standard security group for software developers. Members can add, modify, and delete source code in Azure Repos, create and complete pull requests, queue builds, create and edit work items, and manage release definitions.
• Project Readers: Read-only access to the project. Members can view code, pipelines, and work items, but cannot commit changes, queue builds, or alter settings.
• Build Administrators / Release Administrators: Specialized groups with administrative authority over CI/CD pipelines, retention policies, and deployment environments without granting full Project Administrator privileges.

---

2. Permission Evaluation Mechanics: The Golden Rules

Understanding how Azure DevOps evaluates effective permissions is one of the most frequently tested concepts on the AZ-400 exam.

                         [Permission Check Requested]
                                      │
                                      ▼
                  Is there an explicit DENY on the user
                      or ANY group the user belongs to?
                                 /         \
                               YES          NO
                              /               \
                             ▼                 ▼
                      [ACCESS DENIED]     Is there an explicit ALLOW on the user
                     (DENY ALWAYS WINS)   or ANY group the user belongs to?
                                                   /         \
                                                 YES          NO
                                                /               \
                                               ▼                 ▼
                                        [ACCESS GRANTED]    [INHERIT / NOT SET]
                                                            Evaluates parent scope.
                                                            If parent is NOT SET:
                                                            EFFECTIVE DENY

The Three Permission States

1. Allow: The user or group is explicitly granted permission to execute the action.
2. Deny: The user or group is explicitly blocked from executing the action.
3. Not Set (Inherited): No explicit decision has been made at this level. The permission inherits its value from the parent container (e.g., from Organization down to Project, or Project down to Repository).

Core Evaluation Principles

• Principle 1: Explicit Deny Always Wins: If a user is a member of two groups—one granting Allow and another granting Deny for the exact same permission—the effective permission is always Deny. An explicit Deny cannot be overridden by an Allow.
• Principle 2: Direct Assignment Does Not Override Group Deny: If a user account is directly granted Allow on an object, but belongs to a security group that has Deny on that same object, the user is Deny. Deny is absolute.
• Principle 3: "Not Set" Defaults to Deny: If an inherited permission resolves to "Not Set" all the way to the root level, the effective permission evaluated by the system is Deny.
• Principle 4: Explicit Allow Beats Inherited Deny: If a permission is denied at the Project level through inheritance, an explicit Allow configured directly on a child object (such as a specific Git repository) will successfully grant access for that child object.

---

3. Configuring Azure DevOps Projects and Teams

Project and team structure is the container every other permission decision sits inside, so the blueprint asks you to configure it deliberately.

Choosing a project boundary. A project is the strongest isolation unit in Azure DevOps: it owns its own work item process, repositories, pipelines, feeds and security groups. Prefer one project with many teams when groups share a backlog, need cross-team queries, or want a single set of build agents and feeds. Split into multiple projects only when you need a genuinely separate process template, hard data isolation for a regulated or externally-staffed workstream, or a different administrative owner. Splitting is easy; merging later is not.

Process model. Each project is created from a process — Basic, Agile, Scrum or CMMI — and the process determines the work item types, states and fields. Inherited processes let you add fields, states, rules and custom work item types without XML; changing a project's process afterwards is possible between inherited processes but re-maps states, so decide before the backlog fills.

Creating and scoping a team. Every project starts with one default team. Each additional team gets its own backlog, board, sprint cadence and dashboards, and is backed by a security group of the same name.

az devops project create --name Payments --process Agile --source-control git   --visibility private --organization "$ORG"
az devops team create --name "Payments-Core" --project Payments --organization "$ORG"

Wiring the team to work. A team is only useful once its Team Configuration is set:

The most common misconfiguration is adding a team without selecting its iterations: the board renders, but sprint planning is empty and the burndown never draws. The second is overlapping area paths between two teams, which double-counts the same work item on both boards and corrupts velocity for both.