AZ-400 Configure processes and communications Practice Question
You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?
⚠ Common exam trap
Many exam-takers assume environment-level approvals or branch policies alone are sufficient, but they overlook that users with 'Edit release pipeline' permissions can bypass these controls by modifying the pipeline definition.
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 protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.
It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.
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 new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.
Why it's wrong here
Creating a service connection with limited permissions only restricts what Azure resources the pipeline can access; it does not enforce approval gates, because a user with pipeline edit permissions can simply switch to another connection or modify the pipeline to bypass approval requirements. Azure Policy can audit configuration changes, but it cannot govern the approval workflow inside Azure Pipelines, so this approach fails to satisfy the control requirement.
- ✗
Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.
Why it's wrong here
Environment-level approvals are only effective if the pipeline definition is locked down; since the pipeline remains editable by developers, they can remove or ignore the environment approvals entirely, and Azure Policy does not integrate with Azure Pipelines to force deployments through a specific environment. Enabling diagnostic settings on App Configuration streams operational logs to Azure Monitor but provides no mechanism for approval gating or prevention of unauthorized configuration changes, so this combination does not meet the compliance goal.
- ✗
Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.
Why it's wrong here
Branch policies on the release pipeline's YAML file only govern changes to the code that defines the pipeline, but they do not enforce an approval gate on pipeline runs themselves. A user with edit permissions can still modify the pipeline definition directly in the Azure DevOps portal or push a change to a separate branch that bypasses the protected branch review, since branch policies do not lock down the pipeline resource. Additionally, a webhook alone merely fires an HTTP notification; it does not provide a durable, queryable audit log, and sending such events to Azure Monitor requires a proper data collector or HTTP Data Collector API, not just a webhook subscription. Thus this approach fails to ensure that all configuration changes are approved and logged in a compliant manner.
- ✓
Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.
Why this is correct
Protected variable groups allow you to store critical configuration like approval gate settings and restrict access through pipeline permissions, ensuring only authorized users can modify those gates, and referencing the variable group in the pipeline makes the approval logic itself subject to governance. Restricting edit permissions on the release pipeline to a security group that excludes developers prevents developers from altering the pipeline definition to remove or bypass the required approvals, which is essential for compliance. Using an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor provides an auditable, infrastructure-as-code approach for configuration changes, capturing exactly what was changed and who deployed it, and seamlessly integrating with Azure Monitor for centralized log retention and alerting. This layered defense enforces mandatory approval gates and provides complete change auditability, satisfying financial services compliance requirements.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
ARM template
An ARM template is a JSON file that defines the infrastructure and configuration for Azure resources, enabling repeatable and consistent deployments.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
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.