How do you use Variable Groups and Key Vault integration to manage secrets in Azure DevOps?

Think of a hotel safe at the front desk. Instead of giving every guest a copy of the master key (hardcoded secrets), the hotel stores valuables in a central safe (Key Vault) and gives each guest a temporary access card (service connection) that works only during their stay (pipeline run). The guest never sees the actual combination — they just get their valuables when needed.

Variable Groups in Azure DevOps are collections of key-value pairs that can be shared across multiple pipelines. You create them under Pipelines > Library. Variables can be plain text (API URLs, environment names) or marked as secret (passwords, tokens). Secret variables are encrypted at rest and masked in pipeline logs — if a step accidentally echoes a secret value, Azure DevOps replaces it with ***.

Key Vault integration takes this further. Instead of storing secrets in Azure DevOps, you link a Variable Group to an Azure Key Vault. The Variable Group acts as a bridge — it lists which Key Vault secrets to fetch, and the pipeline accesses them as regular variables at runtime. The secrets never leave Key Vault until the pipeline needs them, and they are never stored in Azure DevOps. Changes to secrets in Key Vault are automatically reflected in the next pipeline run without updating the Variable Group.

At production scale, teams create Variable Groups per environment: payments-dev-vars, payments-staging-vars, payments-prod-vars. Each links to an environment-specific Key Vault. The pipeline YAML references the appropriate group using a variable template or conditional insertion. Permissions on Variable Groups control which pipelines can access which secrets — the production Variable Group is locked to only the production pipeline. Audit logs track which pipeline accessed which secrets.

The non-obvious gotcha is that Key Vault-linked Variable Groups only fetch secrets at the start of the pipeline run, not dynamically during execution. If a secret is rotated in Key Vault mid-pipeline, the pipeline uses the old value. Also, Key Vault integration requires an Azure service connection with Get and List permissions on the vault — if the service principal's access is too broad, it could read secrets from other applications' vaults. Always scope Key Vault access policies to specific secrets, not the entire vault.