# Variable group

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/variable-group

## Quick definition

A variable group is a way to keep a set of settings or secrets in one place inside Azure DevOps. Instead of typing the same values into every pipeline, you create a variable group and link it to your pipelines. This makes your builds and releases easier to manage, especially when you have many pipelines that need the same information. Variable groups can also be linked to Azure Key Vault for secure secret management.

## Simple meaning

Think of a variable group like a shared locker in an office building. In a large company, different teams might need to use the same office supplies, like printer paper or post-it notes. Instead of each team buying their own supplies and storing them at their desks, the company provides a central locker where everyone can take what they need. The locker is always stocked with the same items, and any team with the key can access it.

In the world of Azure DevOps and IT automation, a variable group works in a similar way. When you are setting up automated pipelines to build, test, or deploy software, you often need to use the same pieces of information again and again. This might be a database connection string, an API key, or the name of a server. Instead of typing that information into every single pipeline definition, you create a variable group that holds all those values. Then you tell your pipelines to look at that group when they need a value.

This approach saves time and reduces errors. If you need to change a server address, you update it once in the variable group, and every pipeline that uses that group automatically gets the new value. This is much better than hunting through dozens of pipeline files to make the same change. Variable groups also help with security because you can mark certain values as secrets, and Azure DevOps will hide them in logs and outputs. This keeps sensitive information like passwords and tokens safe from accidental exposure.

## Technical definition

A variable group is an Azure Pipelines resource that provides a centralized, versioned store for key-value pairs used across multiple pipeline definitions. Each variable group is identified by a unique name and can contain both plaintext variables and secret variables. Secret variables are encrypted at rest using Azure DevOps managed keys and are never exposed in logs, task output, or REST API responses. Variable groups can be scoped to a project or shared at the organization level, and access is controlled through Azure DevOps security permissions, including read, use, and administer roles.

Internally, variable groups are stored as part of the Azure DevOps data plane, with each group having a unique identifier (UUID). When a pipeline references a variable group, the Azure Pipelines agent retrieves the group content at runtime, resolves any conflicts with pipeline-level or job-level variables according to a precedence order, and injects the final set of variables into the execution environment. The precedence order, from highest to lowest, is: macro syntax variables ($(var)), template parameters, pipeline variables, variable groups, and then library variable groups. This means that if the same variable name exists in both a pipeline definition and a variable group, the pipeline definition takes precedence.

Variable groups support linking to Azure Key Vault for secret management. When linked, the variable group does not store the actual secret values. Instead, each variable references a specific Key Vault secret. At pipeline runtime, the agent authenticates to Azure Key Vault using a service connection, fetches the current version of the secret, and injects it as a pipeline variable. This ensures that secrets are always up-to-date and that secret rotation in Key Vault is immediately reflected in pipelines without any manual updates to the variable group. The Key Vault-backed variable group also supports enabling the 'Allow access to all pipelines' option, but for production scenarios, it is recommended to restrict access using pipeline permissions and Azure RBAC.

In real IT implementations, variable groups are used for environment-specific configurations. For example, a development environment may have a variable group with a connection string pointing to a dev database, while a production environment has a separate variable group with the production database connection string. Pipelines can be designed to select the correct variable group based on the target environment, often through pipeline parameters or branch policies. Variable groups also support approval gates when combined with library resources, allowing teams to require manual approval before certain variables are used in a pipeline run. This is especially useful for controlling access to production secrets.

From a maintenance perspective, variable groups can be organized by function (e.g., database-vars, api-keys, notification-settings) and can include descriptions for each variable. Azure DevOps provides REST API endpoints for CRUD operations on variable groups, enabling automation of variable group creation and updates as part of infrastructure-as-code practices. The official Azure DevOps documentation recommends using variable groups over hard-coded variables whenever a value is shared across multiple pipelines or requires security protection.

## Real-life example

Imagine you run a small chain of coffee shops. Each shop has a recipe book with all the drink recipes, but the prices of ingredients like milk and coffee beans change every month. Instead of printing new recipe books for every shop each month, you send out a single price list via email. Each shop manager prints that one list and tapes it inside the recipe book. When the price of milk goes up, you update the list once, and every shop uses the new price immediately. This saves you from updating twelve different recipe books individually.

In Azure DevOps, variable groups act exactly like that shared price list. Your pipelines are like the different coffee shops, and the variable group is the single source of truth for values that change or that you want to keep consistent. For example, you might have a variable group named 'DatabaseCredentials' that holds the server address and the database name. You use that group in all your deployment pipelines. When the database is migrated to a new server, you update the server address in the variable group once. The next time any pipeline runs, it automatically picks up the new address.

Another everyday analogy is a family password manager. Instead of having each family member write down the Netflix password on a sticky note, everyone uses the same password manager app. When the password changes, one person updates it in the app, and everyone else gets the new password automatically. In the same way, variable groups centralize your configuration data so that changes propagate instantly and consistently across all your automation workflows.

## Why it matters

In practical IT work, especially in DevOps environments, consistency and security are top priorities. Variable groups directly address both. When you have multiple pipelines that need the same database connection string or API endpoint, it is risky to copy that value into each pipeline definition. A typo in one pipeline could cause a deployment failure. Worse, if a security key is exposed in a pipeline log, you would have to update every pipeline file individually. Variable groups eliminate these risks by providing a single, authoritative location for configuration data.

Variable groups also enforce separation of concerns. Developers can write pipeline templates that reference variable groups without knowing the actual values. A separate team, often operations or security, can manage the variable group content and set appropriate permissions. This aligns with the principle of least privilege: developers can run pipelines but cannot view or modify production secrets. In many organizations, variable groups are linked to Azure Key Vault, which provides additional audit logs and access control.

From a career standpoint, knowing how to use variable groups effectively is a skill that interviewers look for in DevOps roles. It demonstrates an understanding of configuration management, secret handling, and pipeline reusability. When you are building CI/CD pipelines in Azure DevOps, you will almost certainly need to use variable groups for anything beyond a trivial demo. Mastering them will make you more efficient and less error-prone.

## Why it matters in exams

Variable groups are not a primary objective for most entry-level IT certifications like CompTIA A+ or Network+. They are more relevant to intermediate and advanced DevOps-focused exams, such as the Microsoft Azure DevOps Solutions (AZ-400) certification. In the AZ-400 exam, variable groups appear under the domain 'Design and implement a strategy for managing sensitive information' and 'Manage security and compliance'. Candidates are expected to understand when to use variable groups versus pipeline variables, how to link variable groups to Azure Key Vault, and how to secure them with pipeline permissions.

For general IT certifications that include Azure DevOps, such as the Microsoft Azure Administrator (AZ-104) or Azure Developer (AZ-204), variable groups appear as supporting concepts. They are often mentioned in questions about configuring build and release pipelines, or in scenarios involving secure deployment of applications. While you may not get a direct question asking you to define a variable group, you might see a question that describes a situation where a team needs to share a set of configuration values across multiple pipelines. The correct answer will involve creating a variable group or using a library variable group.

Exam questions typically test your ability to choose the right tool for the job. For example, you might be asked: 'You have 15 pipelines that all need the same API key. You want to update the key once and have all pipelines use the new key. What should you do?' The correct answer is to create a variable group. Another common question pattern describes a developer who accidentally exposed a password in a build log. The solution involves moving that password to a variable group and marking it as a secret. Understanding these use cases will help you answer correctly.

For the AZ-400 exam specifically, you should also study variable group security, including pipeline permissions and the difference between 'Allow access to all pipelines' and explicit pipeline permissions. You should know how to use variable groups with YAML pipelines and classic release pipelines. The exam may also test your knowledge of variable group REST APIs and how to automate their management.

## How it appears in exam questions

In exam questions, variable groups are most often presented in scenario-based formats. You will be given a description of a company's CI/CD setup and asked to recommend a configuration change or troubleshoot a problem. The question usually includes details about multiple pipelines, different environments (dev, test, production), and a need to manage secrets or shared variables.

A typical question might read: 'Your company has 20 Azure Pipelines that each deploy a microservice. All microservices connect to the same Azure SQL Database. The database connection string is currently hard-coded in each pipeline. When the database is moved to a new server, an administrator must update each pipeline manually. Which solution would minimize administrative effort?' The correct answer would be to create a variable group containing the connection string and reference it in each pipeline. Distractors might include Azure App Configuration, Azure Key Vault references, or hard-coded variables. The key is that variable groups are the simplest, most direct solution for sharing variables across pipelines without infrastructure overhead.

Another common question type involves secret exposure. For example: 'A developer reports that a password was printed in plain text in a build log. The password is used in multiple pipelines. What should you do to prevent this in the future?' The correct approach is to create a variable group, add the password as a secret variable, remove the hard-coded password from all pipelines, and reference the variable group instead. Some questions will add nuance, such as requiring approval before the password is used. In that case, you would combine the variable group with an approval gate in a classic release pipeline.

Troubleshooting questions might describe a scenario where a pipeline fails because a variable is unexpectedly empty. The cause could be that the pipeline does not have permission to access the variable group, or that a pipeline variable with the same name is overriding the variable group value. You might need to check the variable group's security settings or review the variable precedence order. These questions test your understanding of how variable groups interact with other variable sources.

## Example scenario

Imagine you work for a company called TechWidgets Inc. that builds a mobile app. The app connects to a backend API that requires an API key for authentication. TechWidgets has three environments: development, staging, and production. Each environment has a different API key. The team uses Azure Pipelines to build and deploy the app. Currently, the API key is typed directly into each YAML pipeline file. This creates two problems: first, the API key is visible to anyone who can view the pipeline code, and second, updating the key means editing three different files.

You decide to solve this by creating a variable group called 'ApiKeys'. Inside that group, you create three variables: 'DevApiKey', 'StagingApiKey', and 'ProdApiKey'. You mark all three as secret variables so that Azure DevOps will mask them in logs. Then, in each pipeline, you add a reference to the 'ApiKeys' variable group. In the development pipeline, you set a pipeline variable called 'API_KEY' that equals '$(DevApiKey)'. Similarly, in the staging pipeline, 'API_KEY' equals '$(StagingApiKey)', and in production, it equals '$(ProdApiKey)'.

Later, when the production API key is rotated for security reasons, you go to the variable group, update the 'ProdApiKey' value, and save. The next time the production pipeline runs, it automatically picks up the new key. The development and staging pipelines are unaffected because they use different variables. The team no longer has to edit each pipeline file or worry about accidentally committing the key to source control. This scenario demonstrates the core value of variable groups: centralized, secure, and environment-specific configuration management.

## Common mistakes

- **Mistake:** Storing secrets as plain text variables instead of secret variables.
  - Why it is wrong: Plain text variables are visible in logs, REST API responses, and UI. This defeats the purpose of using a variable group for security and can lead to credential leaks.
  - Fix: Always use the secret variable type for any value that should not be exposed, such as passwords, API keys, or connection strings. In the variable group editor, click the lock icon to make a variable secret.
- **Mistake:** Assuming variable group values are available in all pipelines without explicit permission.
  - Why it is wrong: By default, new variable groups are not accessible to any pipeline. You must explicitly grant access either by enabling 'Allow access to all pipelines' or by adding specific pipelines in the security settings.
  - Fix: After creating a variable group, go to the Pipeline permissions tab and add the pipelines that need access. For production use, explicitly grant access to each required pipeline rather than using the 'all pipelines' option.
- **Mistake:** Overriding variable group values with pipeline variables and then wondering why the value is different.
  - Why it is wrong: Pipeline variables take precedence over variable group variables. If a pipeline variable has the same name as a variable group variable, the pipeline variable wins. This can cause confusion if you expect the variable group value to be used.
  - Fix: Use unique variable names in variable groups to avoid conflicts. If you need environment-specific overrides, use separate variable groups for each environment rather than relying on variable precedence.
- **Mistake:** Linking a variable group to Azure Key Vault but forgetting to grant the service connection appropriate GET permissions on the secrets.
  - Why it is wrong: The Azure DevOps service connection must have the Key Vault Secrets User role (or equivalent) to retrieve secret values. Without this, the pipeline will fail at runtime with an authorization error.
  - Fix: In the Azure portal, go to your Key Vault, select Access policies, and ensure the service principal used by Azure DevOps has at least GET and LIST permissions on secrets. Verify the service connection works by testing it in Azure DevOps.
- **Mistake:** Using variable groups for values that change between pipeline runs within the same environment.
  - Why it is wrong: Variable groups are designed for values that are relatively static. If a value changes frequently (like a build number or a temporary token), it is better to use pipeline variables or output variables from a previous job.
  - Fix: Reserve variable groups for configuration data that is shared across pipelines and changes infrequently. For dynamic values, use pipeline-level variables or Azure DevOps task output variables.

## Exam trap

{"trap":"The exam may present a scenario where a variable group is linked to Azure Key Vault, and ask what happens when a secret is rotated in Key Vault. A common distractor is that the variable group must be manually updated.","why_learners_choose_it":"Learners often think that since the variable group holds the reference to the Key Vault secret, they need to edit the variable group to point to the new secret version or manually update the secret value. This seems logical if you think of the variable group as a storage container.","how_to_avoid_it":"Understand that when a variable group is linked to Key Vault, it does not store the secret value. It stores a reference to the secret. At runtime, Azure DevOps fetches the current version of the secret from Key Vault. Therefore, rotating the secret in Key Vault automatically updates all pipelines using that variable group. No manual update to the variable group is required."}

## Commonly confused with

- **Variable group vs Pipeline variable:** A pipeline variable is defined directly in a pipeline definition (YAML or classic) and is scoped to that specific pipeline. Variable groups are shared across multiple pipelines. Use pipeline variables for values that are unique to a single pipeline, and variable groups for shared values. (Example: If you have a build number that only matters to one pipeline, use a pipeline variable. If you have a database connection string used by ten pipelines, use a variable group.)
- **Variable group vs Azure Key Vault:** Azure Key Vault is a cloud service for storing secrets, keys, and certificates. A variable group can be linked to Key Vault to reference its secrets, but they are different services. Key Vault is the secure storage backend; variable groups are the pipeline-level abstraction for consuming those secrets. (Example: Think of Key Vault as a high-security vault in a bank, and the variable group as a list of references to items in that vault. The variable group tells the pipeline 'get the secret from this vault item', but the actual secret lives in Key Vault.)
- **Variable group vs Library resource (approval gate):** A library resource in Azure DevOps can include variable groups, but also includes service connections and secure files. Approval gates can be associated with library resources, including variable groups, to require manual approval before certain variables are used. Confusion arises because the terms are used together in the UI. (Example: A variable group is a component within the library; the library is the container. You don't approve a variable group; you approve a library resource that contains the variable group. This distinction matters for exam questions about approval flows.)
- **Variable group vs Azure App Configuration:** Azure App Configuration is a service for managing application configuration settings and feature flags, separate from Azure DevOps pipelines. Variable groups are specific to Azure Pipelines. App Configuration is used by applications at runtime, while variable groups are used during build and release processes. (Example: Use variable groups for CI/CD pipeline settings like build agent selection or deployment targets. Use Azure App Configuration for runtime application settings like connection strings that your app reads when it starts.)

## Step-by-step breakdown

1. **Create the variable group** — In Azure DevOps, navigate to Pipelines > Library. Click '+ Variable group'. Assign a meaningful name, such as 'ProductionConfig', and optionally add a description. This creates a container that will hold your key-value pairs.
2. **Add variables to the group** — Click '+ Add variable' for each configuration value you need. Enter a variable name (e.g., 'DbConnectionString') and its value. For sensitive data, click the lock icon to mark it as a secret. Secrets are encrypted and masked in logs.
3. **Configure pipeline permissions** — By default, no pipelines can access the new variable group. In the variable group's 'Pipeline permissions' tab, click '+ Add pipeline' and select the pipelines that should use this group. Alternatively, enable 'Allow access to all pipelines' but this is less secure.
4. **Reference the variable group in a pipeline** — In a YAML pipeline, add the 'variables' block and reference the group using the syntax '- group: ProductionConfig'. In a classic release pipeline, add the variable group under the 'Variables' section of the pipeline. The pipeline will now have access to all variables in that group.
5. **Use the variables in tasks** — After the variable group is referenced, you can use its variables in any task, script, or template using the macro syntax $(VariableName). For example, $(DbConnectionString). The Azure Pipelines agent will resolve the values at runtime.
6. **Update and maintain** — To change a value, simply edit the variable group in the Library. Save the changes. All pipelines that reference that group will automatically use the updated values on their next run. For secret variables, you must re-run any pipelines that have already started, as they cached the previous value.
7. **Link to Azure Key Vault (optional)** — For enhanced security, you can link the variable group to Azure Key Vault. In the variable group, enable 'Link secrets from an Azure Key Vault as variables'. Select a service connection and a Key Vault. This means the variable group will not store secret values but will fetch them from Key Vault at runtime.

## Practical mini-lesson

Variable groups are a fundamental tool for any Azure DevOps practitioner who manages multiple pipelines. In a typical enterprise environment, you might have dozens or even hundreds of pipelines. Without variable groups, you would be forced to duplicate configuration data across all of them, leading to maintenance nightmares. The practical value of variable groups becomes evident the first time you need to update a shared value.

When working with variable groups in practice, you should always follow the principle of separation of concerns. The development team should not have access to production secrets. This means you should create separate variable groups for each environment. For example, create 'Dev-Variables', 'Staging-Variables', and 'Prod-Variables'. Each group contains only the variables relevant to that environment. Then, in the pipeline, you can conditionally select the correct variable group based on the target environment using branch policies or pipeline parameters. This approach also makes it easy to add a new environment without modifying existing pipelines.

Another important practice is to avoid putting too many variables into a single group. If you have twenty variables that are unrelated, consider splitting them into multiple groups with clear names. For instance, create a 'DatabaseConfig' group and an 'ApiConfig' group. This improves readability and makes it easier to grant or restrict permissions at a granular level. Always add descriptions to your variables so that other team members understand what each variable is for. This is especially helpful when someone else needs to troubleshoot a pipeline issue.

What can go wrong? The most common problem is that a pipeline cannot find a variable from a variable group. This usually happens because the pipeline does not have permission to access the group. Always verify the Pipeline permissions tab in the variable group settings. Another issue is variable name collisions. If a pipeline variable and a variable group variable share the same name, the pipeline variable wins. This can be surprising if you expect the group variable to be used. To avoid this, use a naming convention like prefixing group variables with the group name (e.g., 'DB_ConnectionString' instead of just 'ConnectionString').

Professionals also use variable groups in combination with template expressions. For example, you can define a variable group that holds the names of other variable groups, enabling dynamic selection. This is advanced but useful for multi-tenant deployments. Finally, always test your variable group configuration in a non-production pipeline first. A misconfigured secret variable can cause a pipeline to fail with a cryptic error. By testing, you can catch permission issues or syntax errors before they affect production deployments.

## Memory tip

Think 'Group your variables, share your pipelines', variable groups let you define a value once and reuse it in any pipeline.

## FAQ

**Can I use the same variable group in both YAML and classic pipelines?**

Yes, variable groups work with both YAML and classic release pipelines. You reference the group in the variables section of your pipeline definition.

**How do I update a secret variable after it has been created?**

You can edit a secret variable by navigating to the variable group in the Library, finding the variable, and clicking the edit icon. You will need to re-enter the value; the system does not display the existing secret for security reasons.

**What happens if I delete a variable group that is referenced by a pipeline?**

The pipeline will fail at runtime with an error indicating that the variable group cannot be found. You must either recreate the variable group with the same name or update the pipeline to remove the reference.

**Can I use variable groups to store binary data or large files?**

No, variable groups are designed for key-value pairs with string values. They are not suitable for binary data or large content. Use secure files or Azure Blob Storage for large artifacts.

**How are variable groups scoped? Can I share them across projects?**

Variable groups can be scoped to a single project or created at the organization level (via the Library in the project settings). To share across projects, you would need to create the group in each project individually or use the Azure DevOps REST API to automate the process.

**Is there a limit on the number of variables in a variable group?**

Azure DevOps imposes a limit of 500 variables per variable group. If you need more, you can create additional groups or consider using external configuration sources.

**Can I use conditional logic to select different variable groups based on the build branch?**

Yes, in YAML pipelines you can use expressions and conditions to reference different variable groups based on the branch, trigger type, or other criteria. For example, you can have a condition that selects a production group only for the main branch.

## Summary

Variable groups are a powerful feature of Azure Pipelines that allow you to store and share configuration values and secrets across multiple pipelines. They centralize management, reduce duplication, and enhance security by keeping sensitive information out of pipeline definitions. For IT professionals working in DevOps, mastering variable groups is essential for building maintainable and secure CI/CD pipelines.

In practice, variable groups help enforce separation of concerns, allowing operations teams to manage configuration while developers focus on code. They integrate with Azure Key Vault for enterprise-grade secret management. The most common mistakes involve permissions, variable precedence, and misuse of secret types. By understanding these pitfalls and following best practices, you can avoid pipeline failures and security incidents.

On exams like the Microsoft AZ-400, you will be tested on your ability to choose the right tool for sharing variables, secure secrets, and troubleshoot variable resolution. Remember the key point: variable groups are for shared, static configuration. Use them correctly, and you will make your pipelines more efficient and your deployments safer. The memory tip 'Group your variables, share your pipelines' captures the essence of this concept.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/variable-group