← Back to Articles         
Pipeline Variables and Variable Groups

Pipeline Variables and Variable Groups

Published on 08 Oct 2026     9 min read Azure DevOps
Variables, Secrets

Azure DevOps – Pipeline Variables and Variable Groups

1. What are Pipeline Variables?

Pipeline Variables are key-value pairs used to store configuration values in Azure DevOps Pipelines.

Instead of hardcoding values directly into YAML, we define variables and reuse them throughout the pipeline.

Example

Suppose you are deploying an ASP.NET Core Web API application.

You need these values:

  • Application name: EmployeeAPI

  • Build configuration: Release

  • Environment: SIT

  • Deployment path: C:\Deploy\EmployeeAPI

Instead of repeating these values in multiple places, you can define them as variables.

variables:
  appName: 'EmployeeAPI'
  buildConfiguration: 'Release'
  environmentName: 'SIT'
  deployPath: 'C:\Deploy\EmployeeAPI'

You can access them using:

$(appName)
$(buildConfiguration)
$(environmentName)
$(deployPath)

Main purpose: Make pipelines reusable, maintainable, and easier to configure across different environments.

 

2. Why do we need Pipeline Variables?

Consider an ASP.NET Core application deployed to three environments.

Configuration

DEV

SIT

PROD

Environment

Development

SIT

Production

Build configuration

Debug

Release

Release

API URL

dev-api.example.com

sit-api.example.com

api.example.com

Database

Employee_Dev

Employee_SIT

Employee_Prod

Without variables, you may need to modify hardcoded values whenever you deploy to another environment.

With variables, the pipeline logic remains the same while configuration values change.

Advantages

  1. Reusability: Use the same YAML pipeline for multiple environments.

  2. Maintainability: Change a value in one place.

  3. Security: Store sensitive values as secret variables.

  4. Flexibility: Override values at the appropriate scope.

  5. Centralized configuration: Share common settings using Variable Groups.

 

3. How do Pipeline Variables work?

Developer pushes code
         |
         v
Azure DevOps Pipeline starts
         |
         v
Load Pipeline Variables
         |
         v
appName = EmployeeAPI
buildConfiguration = Release
         |
         v
Execute Build Tasks
         |
         v
dotnet build --configuration Release
         |
         v
Publish Build Artifact
         |
         v
Deploy Application

YAML Example – ASP.NET Core Build

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'
  projectPath: 'src/EmployeeAPI/EmployeeAPI.csproj'

steps:
- script: dotnet restore $(projectPath)
  displayName: 'Restore Packages'

- script: dotnet build $(projectPath) --configuration $(buildConfiguration)
  displayName: 'Build Application'

- script: dotnet publish $(projectPath) --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)
  displayName: 'Publish Application'

Here:

  • buildConfiguration is a custom variable.

  • projectPath is a custom variable.

  • Build.ArtifactStagingDirectory is a predefined Azure DevOps variable.

When the pipeline executes, Azure DevOps substitutes the variable values.

 

4. Types of Pipeline Variables

Azure DevOps supports several variable categories and scopes.

Type

Description

User-defined

Variables created by developers

Predefined

Built-in variables provided by Azure DevOps

Secret

Sensitive values such as passwords and tokens

Output

Values produced by one step/job and consumed later

Variable Group

Shared collection of variables

A. User-defined variables

variables:
  appName: 'EmployeeAPI'
  buildConfiguration: 'Release'

Usage:

- script: echo $(appName)

B. Predefined variables

Azure DevOps automatically provides variables such as:

Variable

Purpose

$(Build.BuildId)

Unique build ID

$(Build.BuildNumber)

Build number

$(Build.SourceBranchName)

Source branch name

$(Build.SourcesDirectory)

Source code directory

$(Build.ArtifactStagingDirectory)

Directory for preparing artifacts

Example:

steps:
- script: |
    echo $(Build.BuildId)
    echo $(Build.SourceBranchName)

C. Secret variables

Secret variables store sensitive values such as:

  • Database passwords

  • API keys

  • Access tokens

  • Connection strings containing credentials

Secret variables should be configured through the pipeline UI or a Variable Group, rather than hardcoded in YAML.

For example, a secret named dbPassword can be mapped to an environment variable:

steps:
- script: dotnet run
  env:
    DB_PASSWORD: $(dbPassword)

Azure DevOps masks registered secret values in logs where possible, but masking is not a complete security guarantee. Avoid printing secrets.

 

5. What are Variable Groups?

A Variable Group is a centralized collection of variables that can be shared across multiple Azure DevOps pipelines.

It is managed under:

Azure DevOps → Pipelines → Library → Variable groups

Example

Suppose your organization has three ASP.NET Core applications:

  • EmployeeAPI

  • PayrollAPI

  • AttendanceAPI

All three applications use the same SIT environment settings.

Instead of defining identical variables separately in three pipelines, create one Variable Group.

Variable Group: SIT-Configuration

Shared

Variable

Value

environmentName

SIT

apiBaseUrl

https://sit-api.example.com

databaseName

Employee_SIT

buildConfiguration

Release

dbPassword

Secret (masked)

All three pipelines can reference this group, subject to pipeline authorization.

How Variable Groups work

Azure DevOps Library
        |
        v
Variable Group: SIT-Configuration
        |
        +-------------------+
        |                   |
        v                   v
 EmployeeAPI Pipeline   PayrollAPI Pipeline
        |
        v
 AttendanceAPI Pipeline

All use shared SIT configuration

Important: Updating a shared variable can affect every pipeline that consumes it on subsequent runs.

 

6. How to create a Variable Group in Azure DevOps

Step 1 – Open Variable Groups

Navigate to:

Azure DevOps
    |
    +-- Project
          |
          +-- Pipelines
                |
                +-- Library
                      |
                      +-- Variable groups

Step 2 – Create a group

Click + Variable group.

Enter the name:

SIT-Configuration

Step 3 – Add variables

Name

Value

environmentName

SIT

apiBaseUrl

https://sit-api.example.com

buildConfiguration

Release

dbPassword

Enter password and select the lock icon

Click Save.

Step 4 – Use the Variable Group in YAML

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
- group: SIT-Configuration

steps:
- script: |
    echo "Environment: $(environmentName)"
    echo "API URL: $(apiBaseUrl)"
    echo "Configuration: $(buildConfiguration)"

The pipeline loads the variables from SIT-Configuration.

The group must be authorized for use by the pipeline. You can manage this through the group's pipeline permissions.

 

7. Using Variable Groups for DEV, SIT, UAT and Production

This is a common real-world interview scenario.

Create separate Variable Groups:

DEV-Configuration
SIT-Configuration
UAT-Configuration
PROD-Configuration

Each group contains environment-specific settings.

Variable

DEV

SIT

PROD

environmentName

DEV

SIT

PROD

apiBaseUrl

dev-api.example.com

sit-api.example.com

api.example.com

databaseName

Employee_DEV

Employee_SIT

Employee_PROD

Example – Multi-stage deployment

stages:

- stage: Deploy_SIT
  variables:
  - group: SIT-Configuration

  jobs:
  - job: SIT
    steps:
    - script: |
        echo "Deploying to $(environmentName)"
        echo "API URL: $(apiBaseUrl)"


- stage: Deploy_PROD
  variables:
  - group: PROD-Configuration

  jobs:
  - job: PROD
    steps:
    - script: |
        echo "Deploying to $(environmentName)"
        echo "API URL: $(apiBaseUrl)"

This example demonstrates variable selection; it does not actually deploy the application.

In a real pipeline, use deployment jobs, environment approvals, and deployment tasks. You can deploy the same build artifact to different environments while applying the appropriate configuration.

 

8. Pipeline Variables vs Variable Groups

Feature

Pipeline Variables

Variable Groups

Purpose

Store pipeline configuration

Share configuration across pipelines

Scope

Pipeline, stage, or job

Shared library, referenced by pipelines

Defined in

YAML or Pipeline UI

Pipelines Library

Reusability

Primarily within a pipeline

Across multiple pipelines

Secret support

Yes

Yes

Azure Key Vault integration

Not directly through ordinary variables

Supported

Best use

Build settings, paths

Shared environment configuration

Simple example:

Pipeline Variable:

variables:
  buildConfiguration: 'Release'

Variable Group:

variables:
- group: PROD-Configuration

Both are accessed using the same macro syntax:

$(variableName)
 

9. Variable Syntax – Important for Interviews

Azure Pipelines has three commonly used variable expression syntaxes.

Syntax

Evaluation

Common use

$(variableName)

Before a task executes

Normal variable usage

${{ variables.variableName }}

Template compilation

Templates and compile-time logic

$[variables.variableName]

Runtime expression evaluation

Conditions and calculated values

Example:

variables:
  appName: 'EmployeeAPI'
  isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]

steps:
- script: echo $(appName)

- script: echo ${{ variables.appName }}

- script: echo $(isMain)

Note that Azure Pipelines also supports environment variables inside scripts, such as $APPNAME in Bash or $env:APPNAME in PowerShell.

Variable scope and precedence

Variables can be defined at different levels.

Pipeline-level variable
         |
         v
Stage-level variable
         |
         v
Job-level variable

When the same variable name is defined at multiple YAML scopes, the more local definition takes precedence.

 

10. Variable Groups vs Azure Key Vault

Variable Groups can integrate with Azure Key Vault to retrieve secrets securely.

Azure Key Vault
   |
   | Stores secrets
   v
Key Vault-linked Variable Group
   |
   v
Azure DevOps Pipeline
   |
   v
Deploy ASP.NET Core Application

Example:

variables:
- group: Production-Secrets

Here, Production-Secrets is assumed to be a Variable Group linked to Azure Key Vault.

Azure DevOps retrieves the mapped secret values at runtime using the configured Azure service connection.

Why use Key Vault?

  • Centralized secret management

  • Better control over secret access

  • No need to hardcode passwords

  • Easier secret rotation

Key Vault-linked Variable Groups map secret names to Key Vault secrets; they do not automatically synchronize every type of Key Vault object.

 

11. Advantages and Disadvantages

Advantages

Disadvantages / Considerations

Reduces hardcoding

Incorrect values can break deployments

Improves reusability

Shared changes can impact multiple pipelines

Supports multiple environments

Variable naming must be consistent

Supports secrets

Secrets still require secure handling

Integrates with Azure Key Vault

Permissions and service connections require setup

 

12. Important Interview Questions and Answers

Q1. What is a Pipeline Variable?

A Pipeline Variable is a key-value pair used to store reusable configuration values in Azure DevOps Pipelines.

Q2. What is a Variable Group?

A Variable Group is a centralized collection of variables that can be shared across multiple pipelines.

Q3. What is the main difference between Pipeline Variables and Variable Groups?

Pipeline Variables are generally used for pipeline-specific configuration, whereas Variable Groups are used to centrally manage and share configuration across pipelines.

Q4. Can Variable Groups store passwords?

Yes. They support secret variables and can also integrate with Azure Key Vault.

Q5. How do you access a Variable Group in YAML?

variables:
- group: SIT-Configuration

Access a variable using:

$(environmentName)

Q6. How do you manage variables across DEV, SIT, UAT and PROD?

Create separate Variable Groups for each environment and reference the appropriate group in each deployment stage.

Q7. Can one Variable Group be used by multiple pipelines?

Yes, provided those pipelines are authorized to access it.

Q8. What is the difference between variables and parameters?

Variables are primarily used for runtime configuration and can be updated during execution. Parameters are evaluated during template parsing and are useful for controlling pipeline structure and selecting configuration before execution.

Q9. How do you update a variable during pipeline execution?

Use a logging command:

steps:
- bash: |
    echo "##vso[task.setvariable variable=appVersion]1.0.5"

- bash: |
    echo "Version: $(appVersion)"

The variable is available to subsequent steps in the same job. Sharing values across jobs or stages requires output-variable configuration.

 

13. Real-time Interview Scenario

Question: You have three ASP.NET Core Web API applications deployed to DEV, SIT, UAT and PROD. How would you manage their configuration in Azure DevOps?

Answer:

"I would use Pipeline Variables for application-specific build settings such as project path and build configuration.

For environment-specific settings, I would create separate Variable Groups for DEV, SIT, UAT and Production.

Each deployment stage would reference the appropriate Variable Group. I would store sensitive information in Azure Key Vault and access it through Key Vault-linked Variable Groups.

This allows us to reuse the same build artifact across environments without hardcoding configuration values. Production deployment would additionally require environment approval."

Key points to remember

  • Pipeline Variables: Store reusable configuration values.

  • Variable Groups: Share configuration across multiple pipelines.

  • Secret Variables: Protect sensitive values.

  • Azure Key Vault: Centrally manage secrets.

  • Environment-specific Groups: Keep DEV, SIT, UAT and PROD configurations separate.

  • YAML Reference: variables: - group: GroupName (written on separate YAML lines).

  • Variable Usage: $(variableName).

For an Azure DevOps interview, the most important concepts are Pipeline Variables vs Variable Groups, secret handling, environment-specific configuration, and Azure Key Vault integration.

← Back to Articles