Azure DevOps built-in role
Lab Services Reader
Views existing Azure Lab Services resources without changing those service resources. The role has no DataActions, but its control-plane definition also includes a supporting resource-deployment wildcard. Azure Lab Services retires on June 28, 2027, so reader access should support inventory and migration rather than a new long-term deployment.
Role-definition permissions are imported from Microsoft Learn. Practical scope, use cases, prerequisites, best practices, security considerations, assignment guidance, and relationships have been reviewed against the official sources below.
Role definition ID: 2a5c394f-5eb7-4d4f-9c8e-e8eae39faebc
Control-plane actions (4)
Microsoft.LabServices/*/readMicrosoft.Authorization/*/readMicrosoft.Resources/deployments/*Microsoft.Resources/subscriptions/resourceGroups/read
Data-plane actions (0)
None — this role grants no data-plane (data access) actions.
Excluded actions (0)
None
Assignable scopes (1)
/
Practical scope
Assign on one lab for lab-specific visibility or on a resource group to view every contained lab. Labs and lab plans are sibling resources, so an assignment on a lab plan is not inherited by its associated labs; resource-group assignments are inherited by both.
Common use cases (2)
- Inventory existing labs, plans, schedules, users, images, and migration dependencies without changing them.
- Give a migration reviewer visibility into one lab or a dedicated Lab Services resource group before cleanup.
Prerequisites (2)
- Existing Lab Services resources must still be present and included in a documented retirement inventory.
- The reviewer must know whether visibility is needed for one lab or every lab in a dedicated resource group.
Best practices (3)
- Use Reader instead of Assistant, Contributor, Creator, or Lab Services Contributor when migration work requires only inventory.
- Assign on one lab unless the reviewer is responsible for every Lab Services resource in a dedicated resource group.
- Remove the assignment after resources are migrated or deleted and the retirement inventory is closed.
Security considerations (4)
- The role exposes lab, plan, schedule, user, image, deployment, authorization, and resource metadata throughout its scope.
- The published definition includes Microsoft.Resources/deployments/* in addition to Lab Services reads, so it is not a generic read-only Azure role outside the service boundary.
- A resource-group assignment reveals every inherited lab, while a lab-plan assignment does not provide visibility into sibling labs.
- The role cannot operate VMs or change Lab Services resources, but stale visibility remains unnecessary after migration.
Assignment guidance
Do not create a permanent reader model for a retiring service. Retain or assign Lab Services Reader only for a time-bounded migration inventory at one lab or a dedicated resource group, then remove it when the resources are migrated or deleted.
Related roles (2)
- Lab Assistant: Adds start, stop, reimage, and redeploy operations for lab virtual machines.
- Lab Contributor: Adds management and deletion of one existing lab.
Common questions
When should I assign the Lab Services Reader Azure role?
Assign Lab Services Reader when you need to: Inventory existing labs, plans, schedules, users, images, and migration dependencies without changing them.; and Give a migration reviewer visibility into one lab or a dedicated Lab Services resource group before cleanup.. Practical scope: Assign on one lab for lab-specific visibility or on a resource group to view every contained lab. Labs and lab plans are sibling resources, so an assignment on a lab plan is not inherited by its associated labs; resource-group assignments are inherited by both.
What permissions does the Lab Services Reader Azure role grant?
The role definition grants 4 combined control-plane and data-plane actions. Representative operations include: Microsoft.LabServices/*/read; Microsoft.Authorization/*/read; Microsoft.Resources/deployments/*; and Microsoft.Resources/subscriptions/resourceGroups/read. Review the permission sections above for the complete definition and exclusions.
What are the security risks of the Lab Services Reader Azure role?
Key considerations when assigning Lab Services Reader: The role exposes lab, plan, schedule, user, image, deployment, authorization, and resource metadata throughout its scope.; The published definition includes Microsoft.Resources/deployments/* in addition to Lab Services reads, so it is not a generic read-only Azure role outside the service boundary.; A resource-group assignment reveals every inherited lab, while a lab-plan assignment does not provide visibility into sibling labs.; and The role cannot operate VMs or change Lab Services resources, but stale visibility remains unnecessary after migration.. Follow the assignment guidance above and use the narrowest practical scope.
Editorial sources (8)
- Azure built-in roles for DevOps - Azure RBAC | Microsoft Learn →
Supports: Description, Security considerations. Retrieved 2026-07-17.
- Understand Azure role definitions →
Supports: Description, Security considerations. Retrieved 2026-07-17.
- Understand scope for Azure RBAC →
Supports: Practical scope, Assignment guidance. Retrieved 2026-07-17.
- Best practices for Azure RBAC →
Supports: Best practices. Retrieved 2026-07-17.
- Remove Azure role assignments →
Supports: Best practices, Assignment guidance. Retrieved 2026-07-17.
- Azure role-based access control - Azure Lab Services | Microsoft Learn →
Supports: Description, Practical scope, Common use cases, Prerequisites, Security considerations, Assignment guidance, Related roles. Retrieved 2026-07-17.
- Azure Lab Services retirement guide - Azure Lab Services | Microsoft Learn →
Supports: Description, Common use cases, Prerequisites, Best practices, Security considerations, Assignment guidance. Retrieved 2026-07-17.
- Migrate lab account role assignments to lab plans in Azure Lab Services →
Supports: Practical scope, Best practices. Retrieved 2026-07-17.