Courseiva
Design and implement build and release pipelineshardMultiple SelectObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Which THREE are valid strategies for managing configuration in a multi-environment CI/CD pipeline?

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

Store configuration in environment-specific YAML variable files.

Using variable groups, Key Vault references, and environment-specific YAML variable files are all valid. Storing config in the container image is not recommended because it couples the image to an environment. Hardcoding in scripts is bad practice.

Answer analysis

Option-by-option breakdown

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

  • Store configuration in environment-specific YAML variable files.

    Why this is correct

    Storing configuration in environment-specific YAML variable files (e.g., variables/dev.yml, variables/prod.yml) lets a single, generic pipeline definition consume the correct values per environment via template includes. This keeps your pipeline logic DRY while making each environment's settings explicit, code-reviewed, and easy to change without rebuilding images or rewriting pipelines.

  • Embed configuration values directly into the container image.

    Why it's wrong here

    Embedding configuration values directly into the container image bakes environment-specific settings and secrets into the artifact, making the image unreusable across dev, test, and production. It also forces a rebuild and re-push for every config change, and secrets buried in image layers persist as a serious security risk.

  • Hardcode configuration in pipeline scripts for each environment.

    Why it's wrong here

    Hardcoding configuration in pipeline scripts for each environment couples the pipeline logic to environment-specific values, creating duplication that is error-prone and unmaintainable. It also exposes connection strings, endpoints, and other sensitive data directly in source control, failing fundamental security and separation-of-concerns practices.

  • Use Azure Key Vault references in variable groups.

    Why this is correct

    Azure Key Vault references in variable groups provide dynamic, runtime retrieval of secrets without storing them in YAML or source control. When a variable group is linked to Key Vault, the pipeline fetches secret values at execution time, so secret rotation is automatic and access can be controlled via Key Vault permissions.

  • Use variable groups linked to Azure DevOps library.

    Why this is correct

    Variable groups linked to the Azure DevOps library centralize non-secret configuration values that can be shared across many pipelines and environment stages. They can be referenced in YAML with syntax like $(group.variableName), are viewable in the UI, and can participate in pipeline authorization and approvals, making them a core pattern for reusable configuration.

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 →

How Courseiva writes practice questions · Editorial policy

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.