AZ-400 Develop a security and compliance plan Practice Question
Which TWO actions should a DevOps engineer take to ensure that Azure DevOps pipelines comply with the principle of least privilege for service connections?
⚠ Common exam trap
Test-takers frequently confuse 'Workload identity federation' (which improves secret management) with 'least privilege' (which is about permission scoping), leading them to select option C instead of recognizing that federation does not automatically restrict permissions.
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
✓
Create a service principal with permissions scoped to the minimum required Azure resources.
Creating a service principal with permissions scoped to the minimum required Azure resources directly implements the principle of least privilege. By assigning only the necessary roles (e.g., Contributor on a specific resource group) to the service principal used in the service connection, you ensure that the pipeline can only perform actions on those resources, reducing the attack surface. This aligns with Azure RBAC best practices for securing automated deployments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a service principal with permissions scoped to the minimum required Azure resources.
Why this is correct
Creating a service principal with permissions scoped to the minimum required Azure resources enforces least privilege by granting the pipeline identity only the specific RBAC roles needed on targeted resource groups or services, preventing over-permissioning and reducing the attack surface if credentials are compromised.
- ✗
Use the Project Collection Build Service account for all pipeline runs.
Why it's wrong here
Using the Project Collection Build Service account for all pipeline runs violates least privilege because that built-in account has broad access across all projects in the collection, increasing the blast radius of any exposure. Instead, use dedicated service principals with scoped permissions per pipeline or project.
- ✗
Use Workload identity federation to avoid managing secrets.
Why it's wrong here
Workload identity federation improves credential management by eliminating the need to manage and rotate client secrets, but it does not by itself limit the permission scope of the service principal. You must still assign narrow RBAC roles to the federated service principal, so it is a complementary practice rather than a substitute for least privilege.
- ✓
Configure the service connection to be available only to specific pipelines.
Why this is correct
Configuring the service connection to be available only to specific pipelines restricts usage to authorized execution contexts, reducing the risk of unauthorized or unintended deployments. This authorization control complements least privilege by limiting which pipelines can consume the scoped service principal.
- ✗
Use the same service connection for both build and release pipelines.
Why it's wrong here
Using the same service connection for both build and release pipelines often grants broader permissions than necessary, because build and release stages frequently require different levels of access to Azure resources. This violates least privilege; instead, create separate service connections scoped to the specific resources and actions each pipeline needs.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure DevOps
Azure DevOps is a Microsoft service that provides development tools for planning, building, testing, and deploying software applications using automated pipelines and collaboration features.
Key term
Service principal
A service principal is an identity created for an application or automated tool to access cloud resources securely without using a human user account.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.