AZ-400 Practice Question: Design and implement build and release pipelines
Exhibit
Refer to the exhibit.
```yaml
# azure-pipelines.yml
variables:
- name: environment
value: 'dev'
stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo "Building for $(environment)"
- stage: Deploy
dependsOn: Build
condition: succeeded()
variables:
environment: 'prod'
jobs:
- job: DeployJob
steps:
- script: echo "Deploying to $(environment)"
```You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?
⚠ Common exam trap
A common mix-up: candidates assume the variable `environment` is undefined or defaults to `dev` from a pipeline-level variable, but they overlook that the stage-level definition explicitly sets it to `prod`, which overrides any broader scope.
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
✓
Deploying to prod
The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.
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 Deploy stage will be skipped
Why it's wrong here
The Deploy stage will not be skipped because the default condition succeeded() evaluates to true when the Build stage completes successfully. Since the Build stage succeeded, the Deploy stage is allowed to run, so this option incorrectly predicts a skip.
- ✓
Deploying to prod
Why this is correct
The Deploy stage defines the variable 'environment' with the value 'prod' in its stage-level variables block. This stage-scoped variable overrides any same-named variable from the pipeline or global scope, so when the script executes 'echo Deploying to $(environment)', it outputs 'Deploying to prod'.
- ✗
Deploying to dev
Why it's wrong here
Although a variable named 'environment' might originally be set to 'dev' elsewhere, the Deploy stage explicitly overrides it to 'prod' within that stage's variable scope. Stage variables take precedence over pipeline-level variables for the duration of the stage, so the script cannot output 'Deploying to dev'.
- ✗
The script will fail because variable is not defined
Why it's wrong here
The script will not fail because the variable 'environment' is defined at the Deploy stage level in the variables section. Azure DevOps resolves $(environment) to the defined stage value, so the script has a valid variable reference and executes without an undefined-variable error.
Visual reference
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
Key term
Variables
A variable is a named storage location in a computer program that holds a value which can change during execution.
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 →
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.