AZ-400 Develop a security and compliance plan Practice Question
Your company, Contoso Ltd., is a financial services firm that must comply with PCI DSS. You manage a Azure DevOps organization with over 200 projects. Each project uses a service principal to deploy to Azure using service connections stored in library variable groups. Recently, an auditor flagged that a developer used a service principal with Contributor rights on a production subscription to accidentally delete a storage account. The developer had been granted access to the variable group containing that service principal's credentials. You are tasked with implementing a security and compliance plan to prevent this from recurring. The solution must minimize administrative overhead and follow the principle of least privilege. Current environment: All service principals are created in Azure AD and assigned to variable groups. Developers are granted 'User' access level in Azure DevOps and are members of various teams. You have the ability to create Azure AD groups and custom roles. Which course of action should you take?
⚠ Common exam trap
Watch out — candidates often confuse approval gates (Option B) as a sufficient security control, but they fail to address the root cause—excessive permissions on the service principal itself—and overlook the need to restrict access to the service connection credentials at the Azure DevOps permission level.
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 custom Azure RBAC roles with minimal required permissions for each service principal, restrict service connections to specific pipelines using Azure DevOps security settings (e.g., 'Use' permission), and assign developers only the 'Use' permission to the service connections they need, not the variable groups containing credentials.
It enforces the principle of least privilege by creating custom Azure RBAC roles with minimal permissions, restricting service connections to specific pipelines via Azure DevOps security settings (e.g., 'Use' permission), and assigning developers only the 'Use' permission to the service connections rather than the variable groups containing credentials. This prevents developers from directly accessing or modifying the service principal credentials, eliminating the risk of accidental or malicious use of high-privilege roles like Contributor.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove all variable groups and require developers to use their own Azure AD accounts for deployments, granting them Contributor rights only on non-production environments.
Why it's wrong here
This approach violates least privilege and separation of duties: personal Azure AD accounts are not designed for service-to-service automation, and Contributor rights on non-production environments still expand the blast radius. It also ties deployment credentials to individual users, causing access loss when employees leave and bypassing secure service connection governance.
- ✗
Require all pipeline runs that use production service connections to be approved by a security team via Azure Pipelines approval gates.
Why it's wrong here
Approval gates are a process control that adds manual overhead without reducing the underlying permissions of the production service principal. They are reactive and can be bypassed if the pipeline definition or service connection is misconfigured, so they do not address the core issue of excessive RBAC privileges.
- ✗
Implement Azure DevOps pipeline decorators to inject a security task that checks the service connection's role before each deployment, and fail the pipeline if the role is Contributor or higher.
Why it's wrong here
Pipeline decorators that check the service connection's RBAC role are a runtime guardrail, but they are reactive and add complexity without reducing the principal's actual permissions. The check relies on the pipeline execution context and can be bypassed by using a different connection or altering the pipeline definition; the connection itself should be scoped with least-privilege roles.
- ✓
Create custom Azure RBAC roles with minimal required permissions for each service principal, restrict service connections to specific pipelines using Azure DevOps security settings (e.g., 'Use' permission), and assign developers only the 'Use' permission to the service connections they need, not the variable groups containing credentials.
Why this is correct
This approach aligns with least privilege by creating custom Azure RBAC roles that include only the exact actions required for each deployment, rather than using broad built-in roles like Contributor. Restricting service connections to specific pipelines via Azure DevOps security settings (e.g., the 'Use' permission) ensures that a compromised pipeline can only use its designated connection, and developers are not granted access to variable groups containing credentials, reducing the risk of secret leakage.
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
Variable group
A variable group is a reusable collection of key-value pairs in Azure DevOps that can store configuration settings and secrets, shared across multiple pipelines.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.