Scoping Variable Groups Per Environment to Avoid Duplication
You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?
Quick Answer
Variable groups linked to environments are the way to avoid duplicating environment-specific values: define each variable once, scope different values to dev, test, and prod, and reference the same variable group name across every stage. Redefining variables per stage or using per-condition variable blocks both still require writing the same values out repeatedly.
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
✓
Use variable groups linked to environments
Variable groups linked to environments allow you to define variables once and have different values per environment without duplication. Option A is correct because variable groups can be scoped to specific environments, allowing you to reuse the same variable names with different values across environments. Option B is incorrect because using conditions in the 'variables' section still requires you to define each variable for each condition, leading to duplication. Option C is incorrect because defining variables in each stage duplicates the variable definitions across stages. Option D is incorrect because while Azure Key Vault is useful for secrets, it is not designed for all types of variables, and you still need to reference the secrets per environment, which does not avoid duplication of variable references.
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 variable groups linked to environments
Why this is correct
Variable groups can be scoped to environments.
- ✗
Use the 'variables' section in the pipeline YAML with conditions
Why it's wrong here
Still requires duplication per condition.
- ✗
Define variables in each stage of the YAML pipeline
Why it's wrong here
Duplicates variable definitions.
- ✗
Store all variables in Azure Key Vault and reference them in the pipeline
Why it's wrong here
Key Vault is for secrets, not all variables.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way 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. Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?
hard- ✓ A.Use variable groups scoped to environments to override variables per stage.
- ✓ B.Use environment-level approvals to gate production deployments.
- C.Use stage-level approvals to gate each stage.
- ✓ D.Use conditions on stages to filter based on branch.
- E.Use YAML templates to define each environment's deployment steps.
Why A: Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code. For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch. To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.
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.