AZ-400 Practice Question: Design and implement build and release pipelines
Network Topology
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?
⚠ Common exam trap
Many candidates confuse the single asterisk `*` with the recursive double asterisk `**`, assuming `src/*` matches all files under `src/` including subdirectories, which is incorrect in Azure Pipelines path filters.
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
✓
The path filter 'src/*' does not match files in subdirectories of src/.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The branch filter is missing the 'refs/heads/' prefix.
Why it's wrong here
Azure Pipelines branch filters do not require the 'refs/heads/' prefix; you can specify branch names directly such as 'main' or 'features/*'. The 'refs/heads/' prefix is optional and omitting it is valid syntax, so this is not a problem.
- ✗
The trigger configuration has a syntax error: 'include' should be 'includes'.
Why it's wrong here
In Azure Pipelines YAML, the trigger element uses a plural key 'include' for listing branches, paths, or file patterns to include. The singular 'includes' would be incorrect, so the configuration as written is syntactically valid.
- ✗
The variable 'buildConfiguration' is not defined at the top level.
Why it's wrong here
The variable 'buildConfiguration' is defined at the top level under the 'variables' key, making it available to compilation and all jobs. Its value 'Release' is set correctly, and the variable substitution in the buildConfiguration parameter is valid.
- ✓
The path filter 'src/*' does not match files in subdirectories of src/.
Why this is correct
Path filters in Azure Pipelines follow minimatch semantics, where a single asterisk (*) matches characters within a path segment but not directory separators. Consequently, 'src/*' only matches files directly inside 'src' and does not match files in subdirectories like 'src/WebApplication/Program.cs', so the trigger will not fire for changes in subdirectories.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
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.