Question 699 of 823
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.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, 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.
Last reviewed: Jun 20, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.