AZ-400 Restrict agent pool access Practice Question
Your YAML pipeline uses a self-hosted agent pool. You need to ensure that only the pipeline can trigger builds on that pool, preventing other projects from using it. What should you do?
⚠ Common exam trap
Watch out — candidates often confuse disabling the pool for other projects (Option A) with permission-based restrictions, not realizing that disabling removes all access, including the intended pipeline's ability to use it.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure pipeline permissions in the agent pool security settings
Azure DevOps agent pool security settings allow you to restrict which pipelines or projects can use a specific agent pool. By configuring pipeline permissions, you can grant the 'Use' permission only to the intended pipeline, preventing other projects from triggering builds on that pool. This ensures exclusive access without disabling the pool for all other uses.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the agent pool to 'Disabled' for other projects
Why it's wrong here
Disabling the agent pool for other projects is not a security control in Azure DevOps; it would prevent all agent usage for those projects rather than selectively restricting pipelines. Access should be managed by adjusting the pool's security settings, not by disabling the entire pool.
- ✓
Configure pipeline permissions in the agent pool security settings
Why this is correct
Configuring pipeline permissions in the agent pool security settings is the correct approach because Azure DevOps agent pools support role-based access control (Reader, User, Administrator) and you can grant or deny the 'Use' permission to specific pipelines or groups. This allows you to restrict which pipelines can consume the agents in the pool.
- ✗
Use a deployment group instead of an agent pool
Why it's wrong here
A deployment group is designed for deploying software to target machines, not for controlling access to agent pools or pipelines. It does not provide permission settings that restrict which pipelines can use agents, so it is not a valid alternative for restricting agent pool access.
- ✗
Create a separate agent pool for each project
Why it's wrong here
Creating a separate agent pool for each project isolates agents but does not itself restrict access; you would still need to configure permissions on each pool. Additionally, this approach is inefficient and does not provide the fine-grained control needed to allow specific pipelines while blocking others, unlike security settings on a single pool.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-400 exam frequently reuses these exact scenarios with slightly different constraints.
✓Configure pipeline permissions in the agent pool security settingsCorrect answer▾
Why this is correct
Configuring pipeline permissions in the agent pool security settings is the correct approach because Azure DevOps agent pools support role-based access control (Reader, User, Administrator) and you can grant or deny the 'Use' permission to specific pipelines or groups. This allows you to restrict which pipelines can consume the agents in the pool.
✗Set the agent pool to 'Disabled' for other projectsWrong answer — click to see why▾
Why this is wrong here
Disabling the pool prevents all usage, including the intended pipeline.
✗Use a deployment group instead of an agent poolWrong answer — click to see why▾
Why this is wrong here
Deployment groups are for targeting specific servers, not for access control.
✗Create a separate agent pool for each projectWrong answer — click to see why▾
Why this is wrong here
That would work but is not necessary; you can secure a single pool with permissions.
Analysis generated from the official AZ-400blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Self-hosted agent
A self-hosted agent is a software component that you install and manage on your own infrastructure to run automated tasks for a CI/CD or DevOps platform.
Key term
Agent
An agent is a software component that runs on a local machine to perform automated tasks, collect data, or execute commands as part of a larger system like CI/CD or monitoring.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.