Requiring Team-Specific Approval for Monorepo Subfolder Changes
Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?
Quick Answer
Path filters on a branch policy scope a required-reviewer rule to specific folders in the pull request diff, so a policy attached to /src/api only fires when files in that folder change, and a separate one on /src/web fires independently for that team's code — letting each team's approval requirement apply only to their own part of the monorepo.
⚠ Common exam trap
It's easy for candidates to confuse 'automatically include code reviewers' (which just adds reviewers to all PRs) with the ability to conditionally enforce approval based on file paths, leading them to choose option B instead of the correct path filter feature.
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
✓
Path filters in branch policy
Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require a minimum number of reviewers
Why it's wrong here
This applies to the entire branch, not specific paths.
- ✗
Automatically include code reviewers
Why it's wrong here
This adds reviewers but does not enforce mandatory approval.
- ✓
Path filters in branch policy
Why this is correct
Path filters allow scoping policy to specific file paths.
- ✗
Use separate repositories for each team
Why it's wrong here
The requirement is to use a monorepo, not separate repos.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
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 →
Same concept, more angles
8 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You need to create a pipeline that triggers only when changes are made to files in the 'src/api' folder. Which trigger configuration should you use?
easy- A.trigger: branches: include: - 'main'
- B.trigger: paths: exclude: - 'src/api/*'
- C.trigger: tags: include: - 'v*'
- ✓ D.trigger: paths: include: - 'src/api/*'
Why D: The `trigger: paths: include: - 'src/api/*'` configuration tells Azure Pipelines to only trigger the pipeline when changes are detected in files matching that path pattern. This is the standard way to scope pipeline triggers to specific folders or file patterns in YAML pipelines, ensuring that unrelated changes elsewhere in the repository do not start the pipeline.
Variation 2. Refer to the exhibit. You have an Azure Pipelines YAML file for a .NET Core application. The pipeline is triggered on changes to the main branch, but only for files under src/. After a push to main that modifies a file in src/, the pipeline does not start. What is the most likely reason?
medium- A.The branch filter is missing the 'refs/heads/' prefix.
- B.The trigger configuration has a syntax error: 'include' should be 'includes'.
- C.The variable 'buildConfiguration' is not defined at the top level.
- ✓ D.The path filter 'src/*' does not match files in subdirectories of src/.
Why D: The path filter `src/*` uses a single asterisk, which only matches files directly within the `src/` directory, not files in subdirectories (e.g., `src/app/main.cs`). Azure Pipelines path filters require a double asterisk `src/**` to recursively match all files under `src/`. Since the modified file is in a subdirectory, the trigger condition is not met, and the pipeline does not start.
Variation 3. You are designing a build pipeline that must be triggered only when changes are made to specific folders in the repository. The pipeline should ignore documentation changes. Which trigger configuration should you use?
hard- A.Configure a scheduled trigger to run the pipeline daily.
- B.Configure a branch trigger with an include filter for the main branch.
- ✓ C.Configure a path trigger with include paths for source code and exclude paths for docs.
- D.Configure a tag trigger with a pattern that matches release tags.
Why C: Azure Pipelines path triggers allow you to specify include and exclude filters on file paths. By including only source code folders and excluding the docs folder, the pipeline will only run when relevant code changes are made, ignoring documentation updates.
Variation 4. Your team uses a YAML-based build pipeline in Azure Pipelines. You need to ensure that the pipeline runs automatically when a pull request is created against the main branch, but only if the changes include modifications to the 'src/' directory. Which trigger configuration should you use?
medium- A.trigger: - main; pr: none
- ✓ B.trigger: none; pr: branches: include: - main paths: include: - src/*
- C.trigger: none; pr: - main
- D.pr: - main; trigger: - main
Why B: It sets `trigger: none` to disable CI triggers on commits, and uses a PR trigger with `branches: include: - main` and `paths: include: - src/*` to ensure the pipeline only runs automatically when a pull request targets the main branch and the changes include modifications to the 'src/' directory. This configuration meets the requirement of conditional PR-triggered builds based on file paths.
Variation 5. You have an Azure Pipelines YAML file with the following trigger configuration: ```yaml trigger: branches: include: - main paths: include: - /src/* ``` The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?
medium- ✓ A.The path filter restricts the trigger to only changes in /src/.
- B.The trigger syntax is incorrect; 'branch' should be 'branches'.
- C.The script step is missing a display name.
- D.The pool vmImage is not specified correctly.
Why A: The most likely reason is that a path filter is configured in the trigger, restricting the pipeline to only trigger on changes under /src/. The other options are incorrect because they either refer to minor syntax issues or irrelevant details.
Variation 6. You have a multi-stage YAML pipeline that builds and deploys a Node.js application. You want to ensure that the build stage runs only when changes are made to the 'src' folder. Which trigger configuration should you use?
easy- A.Trigger with 'batch' set to true
- B.Trigger with 'branches' filter
- ✓ C.Trigger with 'paths' filter
- D.Disable CI trigger and use a scheduled trigger
Why C: Azure Pipelines supports path-based triggers that allow you to specify which file paths should trigger a pipeline run. By configuring a trigger with a 'paths' filter that includes only the 'src' folder, the build stage will only execute when changes are detected within that specific directory, ignoring changes elsewhere in the repository.
Variation 7. Your organization uses Azure Pipelines to build and deploy a .NET Core application to Azure App Service. The build pipeline takes 15 minutes. You want to implement continuous integration (CI) triggers but only for changes to the 'src' folder. The repository is in Azure Repos. How should you configure the trigger?
medium- ✓ A.Set trigger: paths: include: - 'src/*'
- B.Set trigger: paths: exclude: - 'src/*'
- C.Set trigger: branches: include: - main
- D.Set trigger: batch: true
Why A: Azure Pipelines path filters use glob patterns. The pattern '*' matches zero or more characters but does not match the slash '/', so 'src/*' only matches files directly in the 'src' folder, not files in subdirectories. To include all files under 'src' (including subfolders), you must use 'src/**'. The correct YAML would be: trigger: paths: include: - 'src/**'. Option A is not fully correct because it would miss changes in subfolders.
Variation 8. You are configuring a YAML pipeline that deploys to multiple environments. The pipeline should automatically trigger when changes are pushed to the main branch, but only if the build artifact changes. Which trigger configuration should you use?
medium- A.trigger: branches: include: - main
- ✓ B.trigger: paths: include: - src/*
- C.pr: branches: include: - main
- D.resources: containers: - container: myContainer
Why B: The requirement is to trigger on pushes to main only when source code changes. This requires both a branch filter and a path filter: `trigger: branches: include: main paths: include: src/*`. Option B only filters by path, so it triggers on all branches. Option A only filters by branch. No single option is correct, so this question is invalid.
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.