Design and implement build and release pipelines →hardMultiple Choice

Using a Paths Filter to Trigger Only on a Specific Monorepo Folder

Your team uses a monorepo in Azure Repos with multiple projects. You want to trigger a pipeline only when changes are made to a specific subfolder. Which configuration should you use?

Quick Answer

A 'paths' filter on the CI trigger is exactly what limits a pipeline to a specific monorepo subfolder — you list include or exclude path patterns, and Azure Pipelines only starts a run when a changed file actually falls inside those paths, so unrelated projects in the same repo stop triggering unnecessary builds.

⚠ Common exam trap

Candidates often confuse the checkout step's sparse checkout or path filtering with trigger-level path filtering, mistakenly believing that limiting what is downloaded also prevents the pipeline from being triggered by changes outside that path.

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

✓

Add a 'paths' filter to the CI trigger.

Azure Pipelines CI triggers support a 'paths' filter that allows you to specify include or exclude patterns for file changes. When a monorepo contains multiple projects in separate subfolders, adding a 'paths' filter to the CI trigger ensures the pipeline only runs when changes are detected within that specific subfolder, avoiding unnecessary builds for unrelated projects.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a branch filter in the CI trigger.
Why it's wrong here
A branch filter evaluates the branch that received the commit, not which files changed, so any commit to the tracked branch triggers the pipeline regardless of subfolder. It is tempting because branch filters are the standard trigger-scoping mechanism, but path filtering requires path include or exclude entries.
✓
Add a 'paths' filter to the CI trigger.
Why this is correct
A paths filter on the CI trigger restricts pipeline execution to commits touching specified subfolders, so changes elsewhere in the monorepo are ignored. This directly satisfies the requirement to trigger only for a specific subfolder without splitting the repository.
✗
Configure the checkout step to only include the subfolder.
Why it's wrong here
Checkout controls which repository content is fetched into the agent workspace; it does not influence trigger evaluation, so commits anywhere in the monorepo still start the pipeline. It is tempting because sparse checkout reduces clone size, but path-based triggering needs path filters in the trigger block.
✗
Use a 'file_match' condition on the job.
Why it's wrong here
Azure Pipelines has no 'file_match' condition; path filtering is configured via the trigger's paths include/exclude filters, which evaluate before the run starts. A condition runs after triggering, so it cannot prevent the pipeline from queueing. It is tempting because conditions do gate individual jobs, which suits skipping steps once a run already exists.

Go deeper

2 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. Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

hard

A.Use a single workflow that builds all projects on every push
B.Use submodules to separate projects
C.Use workflow templates and composite actions
✓ D.Use path filters in GitHub Actions workflows

Why D: GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Variation 2. Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

hard

A.Create a single pipeline that builds all projects on every commit
✓ B.Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents
C.Use a single pipeline with a condition that checks which files changed and runs only the corresponding job
D.Create separate pipelines for each project and trigger them manually

Why B: To build only changed projects in a monorepo, you need to detect which files changed and then determine the affected projects and their dependents. Path filters in the pipeline trigger can limit the pipeline to run only when specific paths change, but they don't handle dependencies. A custom script can analyze the dependency graph and build only the affected projects plus their dependents, minimizing build time. This approach is flexible and can be implemented in Azure Pipelines using scripts or tools like Nx or Lerna.

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.

Using a Paths Filter to Trigger Only on a Specific Monorepo Folder

Why each option matters

Option-by-option breakdown

Related to this question

2 more ways this is tested on AZ-400